Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2809013002:
EME contentType checks DolbyVision (Closed)
|
Created:
3 years, 8 months ago by yucliu1 Modified:
3 years, 8 months ago CC:
chromium-reviews, alokp+watch_chromium.org, lcwu+watch_chromium.org, eme-reviews_chromium.org, halliwell+watch_chromium.org, feature-media-reviews_chromium.org Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
DescriptionEME contentType checks DolbyVision
Add new enum to EmeCodec:
EME_CODEC_MP4_DV_AVC
EME_CODEC_MP4_DV_HEVC
BUG=710167
TEST=requestMediaKeySystemAccess with dv codec on cast
Review-Url: https://codereview.chromium.org/2809013002
Cr-Commit-Position: refs/heads/master@{#467431}
Committed: https://chromium.googlesource.com/chromium/src/+/f5ff9e38f2a20950f26f7afe79b175328ce5700d
Patch Set 1 #
Total comments: 4
Patch Set 2 : DV + HEVC #Patch Set 3 : More guard #
Total comments: 7
Patch Set 4 : Typo #
Messages
Total messages: 32 (7 generated)
Description was changed from ========== EME contentType checks DolbyVision Add new enum to EmeCodec: EME_CODEC_MP4_DV_AVC EME_CODEC_MP4_DV_HEVC BUG=710167 TEST=requestMediaKeySystemAccess with dv codec on cast ========== to ========== EME contentType checks DolbyVision Add new enum to EmeCodec: EME_CODEC_MP4_DV_AVC EME_CODEC_MP4_DV_HEVC BUG=710167 TEST=requestMediaKeySystemAccess with dv codec on cast ==========
yucliu@chromium.org changed reviewers: + chcunningham@chromium.org, ddorwin@chromium.org, erickung@chromium.org, halliwell@chromium.org
On 2017/04/10 21:03:00, yucliu1 wrote: Ping on this~
https://codereview.chromium.org/2809013002/diff/1/media/base/eme_constants.h File media/base/eme_constants.h (right): https://codereview.chromium.org/2809013002/diff/1/media/base/eme_constants.h#... media/base/eme_constants.h:50: EME_CODEC_MP4_DV_HEVC EME_CODEC_MP4_DV_HEVC should be inside #if BUILDFLAG(ENABLE_HEVC_DEMUXING) as well https://codereview.chromium.org/2809013002/diff/1/media/base/key_systems.cc File media/base/key_systems.cc (right): https://codereview.chromium.org/2809013002/diff/1/media/base/key_systems.cc#n... media/base/key_systems.cc:73: {"dvhe", EME_CDOEC_MP4_DV_HEVC}, // DolbyVision HEVC dvh1 and dvhe should also be protected inside ENABLE_HEVC_DEMUXING
https://codereview.chromium.org/2809013002/diff/1/media/base/eme_constants.h File media/base/eme_constants.h (right): https://codereview.chromium.org/2809013002/diff/1/media/base/eme_constants.h#... media/base/eme_constants.h:50: EME_CODEC_MP4_DV_HEVC On 2017/04/11 16:57:34, erickung1 wrote: > EME_CODEC_MP4_DV_HEVC should be inside #if BUILDFLAG(ENABLE_HEVC_DEMUXING) as > well Done. https://codereview.chromium.org/2809013002/diff/1/media/base/key_systems.cc File media/base/key_systems.cc (right): https://codereview.chromium.org/2809013002/diff/1/media/base/key_systems.cc#n... media/base/key_systems.cc:73: {"dvhe", EME_CDOEC_MP4_DV_HEVC}, // DolbyVision HEVC On 2017/04/11 16:57:34, erickung1 wrote: > dvh1 and dvhe should also be protected inside ENABLE_HEVC_DEMUXING Done.
Add HEVC guard for cast and Android
Sorry for the delay - forgot to set my alias for vacation week. https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... File chromecast/renderer/media/key_systems_cast.cc (right): https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... chromecast/renderer/media/key_systems_cast.cc:53: codecs |= ::media::EME_CODEC_MP4_DV_AVC; Its not easy for me to verify playready supports these. Have you checked it? https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... chromecast/renderer/media/key_systems_cast.cc:121: codecs |= ::media::EME_CODEC_MP4_DV_AVC; Ditto here. I'm not sure how to verify Widevine actually has this support. How can I verify? https://codereview.chromium.org/2809013002/diff/40001/components/cdm/browser/... File components/cdm/browser/cdm_message_filter_android.cc (right): https://codereview.chromium.org/2809013002/diff/40001/components/cdm/browser/... components/cdm/browser/cdm_message_filter_android.cc:44: #if BUILDFLAG(ENABLE_DOLBY_VISION_DEMUXING) I don't think this is sufficient to actually check demuxing capabilities of a given key system. Below, we will simply pass the same "video/mp4" to MediaDrmBridge::IsKeySystemSupportedWithType for all of [MP4_HEVC, DV_AVC, DV_HEVC]. But the reality is demuxers need special logic to actually parse HEVC that they do not need for parsing a vanilla "video/mp4; codecs='avc'". For example, see our special HEVC demuxing logic in https://cs.chromium.org/chromium/src/media/formats/mp4/box_definitions.cc?l=753 If I read it correctly, this problem extends to the existing code that checks for MP4_HEVC even without dolby vision. It seems like this may be a limitation of the underlying android API: https://developer.android.com/reference/android/media/MediaDrm.html#isCryptoS..., java.lang.String) Please reach out to MediaDrm folks to get a sense for whether (and for what versions) HEVC demuxing is supported on given key systems. We may need plumb an additional signal that this is "video/mp4" *for hevc* and do some API version checking to give the correct answer.
yucliu@chromium.org changed reviewers: + xhwang@chromium.org
https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... File chromecast/renderer/media/key_systems_cast.cc (right): https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... chromecast/renderer/media/key_systems_cast.cc:53: codecs |= ::media::EME_CODEC_MP4_DV_AVC; On 2017/04/17 16:14:24, chcunningham wrote: > Its not easy for me to verify playready supports these. Have you checked it? I'll verify this soon. Chromecast Ultra supports DV. https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... chromecast/renderer/media/key_systems_cast.cc:121: codecs |= ::media::EME_CODEC_MP4_DV_AVC; On 2017/04/17 16:14:24, chcunningham wrote: > Ditto here. I'm not sure how to verify Widevine actually has this support. How > can I verify? I have tried some DV codecs with Widevine on Chromecast Ultra, it works as expected, I can double check that. https://codereview.chromium.org/2809013002/diff/40001/components/cdm/browser/... File components/cdm/browser/cdm_message_filter_android.cc (right): https://codereview.chromium.org/2809013002/diff/40001/components/cdm/browser/... components/cdm/browser/cdm_message_filter_android.cc:44: #if BUILDFLAG(ENABLE_DOLBY_VISION_DEMUXING) On 2017/04/17 16:14:24, chcunningham wrote: > I don't think this is sufficient to actually check demuxing capabilities of a > given key system. Below, we will simply pass the same "video/mp4" to > MediaDrmBridge::IsKeySystemSupportedWithType for all of [MP4_HEVC, DV_AVC, > DV_HEVC]. But the reality is demuxers need special logic to actually parse HEVC > that they do not need for parsing a vanilla "video/mp4; codecs='avc'". For > example, see our special HEVC demuxing logic in > https://cs.chromium.org/chromium/src/media/formats/mp4/box_definitions.cc?l=753 I b > > If I read it correctly, this problem extends to the existing code that checks > for MP4_HEVC even without dolby vision. > > It seems like this may be a limitation of the underlying android API: > https://developer.android.com/reference/android/media/MediaDrm.html#isCryptoS..., > java.lang.String) > > Please reach out to MediaDrm folks to get a sense for whether (and for what > versions) HEVC demuxing is supported on given key systems. We may need plumb an > additional signal that this is "video/mp4" *for hevc* and do some API version > checking to give the correct answer. I think the 'special logic' (profile, level, etc) should be handled by MimeUtil checks before entering here, also 'CanDecode' performs some check on whether the platform supports decoding the vanilla type. +xhwang to confirm this.
https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... File chromecast/renderer/media/key_systems_cast.cc (right): https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... chromecast/renderer/media/key_systems_cast.cc:53: codecs |= ::media::EME_CODEC_MP4_DV_AVC; On 2017/04/18 00:13:02, yucliu1 wrote: > On 2017/04/17 16:14:24, chcunningham wrote: > > Its not easy for me to verify playready supports these. Have you checked it? > > I'll verify this soon. Chromecast Ultra supports DV. I can verify the reqestMediaKeySystemAccess returns pending promise for Playready + DV. Since cast doesn't distinguish between secure vs non secure codecs, playback also works. However, although type check passes both MediaSource.isTypeSupported and requestMediaKeySystemAccess, DV content may not be able to play on the screen if TV doesn't support DV. Is this the expected behavior? (We have additional API to check whether the content can be played on screen)
On 2017/04/19 04:34:26, yucliu1 wrote: > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > File chromecast/renderer/media/key_systems_cast.cc (right): > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > chromecast/renderer/media/key_systems_cast.cc:53: codecs |= > ::media::EME_CODEC_MP4_DV_AVC; > On 2017/04/18 00:13:02, yucliu1 wrote: > > On 2017/04/17 16:14:24, chcunningham wrote: > > > Its not easy for me to verify playready supports these. Have you checked it? > > > > I'll verify this soon. Chromecast Ultra supports DV. > > I can verify the reqestMediaKeySystemAccess returns pending promise for > Playready + DV. Since cast doesn't distinguish between secure vs non secure > codecs, playback also works. > > However, although type check passes both MediaSource.isTypeSupported and > requestMediaKeySystemAccess, DV content may not be able to play on the screen if > TV doesn't support DV. What will the user see if you send decoded DV content (lets say, via cast ultra) to a TV that doesn't support DV? > Is this the expected behavior? Not sure yet... > (We have additional API to check whether the content can be played on screen) This suggests we can programatically detect whether the screen can support. How feasible is it to add that detection logic to chromium?
On 2017/04/19 18:46:56, chcunningham wrote: > On 2017/04/19 04:34:26, yucliu1 wrote: > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > File chromecast/renderer/media/key_systems_cast.cc (right): > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > chromecast/renderer/media/key_systems_cast.cc:53: codecs |= > > ::media::EME_CODEC_MP4_DV_AVC; > > On 2017/04/18 00:13:02, yucliu1 wrote: > > > On 2017/04/17 16:14:24, chcunningham wrote: > > > > Its not easy for me to verify playready supports these. Have you checked > it? > > > > > > I'll verify this soon. Chromecast Ultra supports DV. > > > > I can verify the reqestMediaKeySystemAccess returns pending promise for > > Playready + DV. Since cast doesn't distinguish between secure vs non secure > > codecs, playback also works. > > > > However, although type check passes both MediaSource.isTypeSupported and > > requestMediaKeySystemAccess, DV content may not be able to play on the screen > if > > TV doesn't support DV. > > What will the user see if you send decoded DV content (lets say, via cast ultra) > to a TV that doesn't support DV? We don't expect app to push data if DV isn't supported. App can query support via the API mentioned below. Not sure what will happen if app ignore the check and push DV to us. Eric, can you comment here? > > > Is this the expected behavior? > > Not sure yet... > > > (We have additional API to check whether the content can be played on screen) > > This suggests we can programatically detect whether the screen can support. How > feasible is it to add that detection logic to chromium? +servolk
yucliu@chromium.org changed reviewers: + servolk@chromium.org
Sergey, can you answer the question in Chris' comment?
On 2017/04/19 18:52:02, yucliu1 wrote: > On 2017/04/19 18:46:56, chcunningham wrote: > > On 2017/04/19 04:34:26, yucliu1 wrote: > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > File chromecast/renderer/media/key_systems_cast.cc (right): > > > > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > chromecast/renderer/media/key_systems_cast.cc:53: codecs |= > > > ::media::EME_CODEC_MP4_DV_AVC; > > > On 2017/04/18 00:13:02, yucliu1 wrote: > > > > On 2017/04/17 16:14:24, chcunningham wrote: > > > > > Its not easy for me to verify playready supports these. Have you checked > > it? > > > > > > > > I'll verify this soon. Chromecast Ultra supports DV. > > > > > > I can verify the reqestMediaKeySystemAccess returns pending promise for > > > Playready + DV. Since cast doesn't distinguish between secure vs non secure > > > codecs, playback also works. > > > > > > However, although type check passes both MediaSource.isTypeSupported and > > > requestMediaKeySystemAccess, DV content may not be able to play on the > screen > > if > > > TV doesn't support DV. > > > > What will the user see if you send decoded DV content (lets say, via cast > ultra) > > to a TV that doesn't support DV? > > We don't expect app to push data if DV isn't supported. App can query support > via the API mentioned below. Not sure what will happen if app ignore the check > and push DV to us. Eric, can you comment here? > > > > > > Is this the expected behavior? > > > > Not sure yet... > > > > > (We have additional API to check whether the content can be played on > screen) > > > > This suggests we can programatically detect whether the screen can support. > How > > feasible is it to add that detection logic to chromium? > > +servolk On Chromecast we are using HDMI EDID information to detect whether TV can play DolbyVision content. I don't know if chromium exposes HDMI EDID information somewhere though internal APIs. But anyway, Chromium doesn't support DolbyVision, so there's probably no point in moving that logic to Chromium code. We should be fine with just a regular codec check via MediaClient and the Chromecast's MediaClient will ensure that all the necessary conditions are met for DolbyVision playback (i.e. both the media decoder supports DV and the screen supports DV).
On 2017/04/19 19:04:32, servolk wrote: > On 2017/04/19 18:52:02, yucliu1 wrote: > > On 2017/04/19 18:46:56, chcunningham wrote: > > > On 2017/04/19 04:34:26, yucliu1 wrote: > > > > > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > > File chromecast/renderer/media/key_systems_cast.cc (right): > > > > > > > > > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > > chromecast/renderer/media/key_systems_cast.cc:53: codecs |= > > > > ::media::EME_CODEC_MP4_DV_AVC; > > > > On 2017/04/18 00:13:02, yucliu1 wrote: > > > > > On 2017/04/17 16:14:24, chcunningham wrote: > > > > > > Its not easy for me to verify playready supports these. Have you > checked > > > it? > > > > > > > > > > I'll verify this soon. Chromecast Ultra supports DV. > > > > > > > > I can verify the reqestMediaKeySystemAccess returns pending promise for > > > > Playready + DV. Since cast doesn't distinguish between secure vs non > secure > > > > codecs, playback also works. > > > > > > > > However, although type check passes both MediaSource.isTypeSupported and > > > > requestMediaKeySystemAccess, DV content may not be able to play on the > > screen > > > if > > > > TV doesn't support DV. > > > > > > What will the user see if you send decoded DV content (lets say, via cast > > ultra) > > > to a TV that doesn't support DV? > > > > We don't expect app to push data if DV isn't supported. App can query support > > via the API mentioned below. Not sure what will happen if app ignore the check > > and push DV to us. Eric, can you comment here? > > > > > > > > > Is this the expected behavior? > > > > > > Not sure yet... > > > > > > > (We have additional API to check whether the content can be played on > > screen) > > > > > > This suggests we can programatically detect whether the screen can support. > > How > > > feasible is it to add that detection logic to chromium? > > > > +servolk > > On Chromecast we are using HDMI EDID information to detect whether TV can play > DolbyVision content. I don't know if chromium exposes HDMI EDID information > somewhere though internal APIs. But anyway, Chromium doesn't support > DolbyVision, so there's probably no point in moving that logic to Chromium code. > We should be fine with just a regular codec check via MediaClient and the > Chromecast's MediaClient will ensure that all the necessary conditions are met > for DolbyVision playback (i.e. both the media decoder supports DV and the screen > supports DV). In theory, we should check in the EME path as well, because on Android there is a distinction between secure and non-secure decode capabilities. The EME API is the only way to check for secure output capability. However, in practice ... we don't support DV on ATV (and doing so is likely quite a way off) ... so I think this is fine for now. Could put a TODO if we want for the future.
On 2017/04/19 21:27:38, halliwell wrote: > On 2017/04/19 19:04:32, servolk wrote: > > On 2017/04/19 18:52:02, yucliu1 wrote: > > > On 2017/04/19 18:46:56, chcunningham wrote: > > > > On 2017/04/19 04:34:26, yucliu1 wrote: > > > > > > > > > > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > > > File chromecast/renderer/media/key_systems_cast.cc (right): > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > > > chromecast/renderer/media/key_systems_cast.cc:53: codecs |= > > > > > ::media::EME_CODEC_MP4_DV_AVC; > > > > > On 2017/04/18 00:13:02, yucliu1 wrote: > > > > > > On 2017/04/17 16:14:24, chcunningham wrote: > > > > > > > Its not easy for me to verify playready supports these. Have you > > checked > > > > it? > > > > > > > > > > > > I'll verify this soon. Chromecast Ultra supports DV. > > > > > > > > > > I can verify the reqestMediaKeySystemAccess returns pending promise for > > > > > Playready + DV. Since cast doesn't distinguish between secure vs non > > secure > > > > > codecs, playback also works. > > > > > > > > > > However, although type check passes both MediaSource.isTypeSupported and > > > > > requestMediaKeySystemAccess, DV content may not be able to play on the > > > screen > > > > if > > > > > TV doesn't support DV. > > > > > > > > What will the user see if you send decoded DV content (lets say, via cast > > > ultra) > > > > to a TV that doesn't support DV? > > > > > > We don't expect app to push data if DV isn't supported. App can query > support > > > via the API mentioned below. Not sure what will happen if app ignore the > check > > > and push DV to us. Eric, can you comment here? > > > > > > > > > > > > Is this the expected behavior? > > > > > > > > Not sure yet... > > > > > > > > > (We have additional API to check whether the content can be played on > > > screen) > > > > > > > > This suggests we can programatically detect whether the screen can > support. > > > How > > > > feasible is it to add that detection logic to chromium? > > > > > > +servolk > > > > On Chromecast we are using HDMI EDID information to detect whether TV can play > > DolbyVision content. I don't know if chromium exposes HDMI EDID information > > somewhere though internal APIs. But anyway, Chromium doesn't support > > DolbyVision, so there's probably no point in moving that logic to Chromium > code. > > We should be fine with just a regular codec check via MediaClient and the > > Chromecast's MediaClient will ensure that all the necessary conditions are met > > for DolbyVision playback (i.e. both the media decoder supports DV and the > screen > > supports DV). > > In theory, we should check in the EME path as well, because on Android there is > a distinction between secure and non-secure decode capabilities. The EME API is > the only way to check for secure output capability. > > However, in practice ... we don't support DV on ATV (and doing so is likely > quite a way off) ... so I think this is fine for now. Could put a TODO if we > want for the future. I saw changes in cdm_message_filter_android.cc, as well as the discussion on secure and non-secure decoder on Android. But here we are saying "we don't support DV on ATV", so do we really need the changes on Android?
On 2017/04/25 16:57:22, xhwang_slow wrote: > On 2017/04/19 21:27:38, halliwell wrote: > > On 2017/04/19 19:04:32, servolk wrote: > > > On 2017/04/19 18:52:02, yucliu1 wrote: > > > > On 2017/04/19 18:46:56, chcunningham wrote: > > > > > On 2017/04/19 04:34:26, yucliu1 wrote: > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > > > > File chromecast/renderer/media/key_systems_cast.cc (right): > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2809013002/diff/40001/chromecast/renderer/med... > > > > > > chromecast/renderer/media/key_systems_cast.cc:53: codecs |= > > > > > > ::media::EME_CODEC_MP4_DV_AVC; > > > > > > On 2017/04/18 00:13:02, yucliu1 wrote: > > > > > > > On 2017/04/17 16:14:24, chcunningham wrote: > > > > > > > > Its not easy for me to verify playready supports these. Have you > > > checked > > > > > it? > > > > > > > > > > > > > > I'll verify this soon. Chromecast Ultra supports DV. > > > > > > > > > > > > I can verify the reqestMediaKeySystemAccess returns pending promise > for > > > > > > Playready + DV. Since cast doesn't distinguish between secure vs non > > > secure > > > > > > codecs, playback also works. > > > > > > > > > > > > However, although type check passes both MediaSource.isTypeSupported > and > > > > > > requestMediaKeySystemAccess, DV content may not be able to play on the > > > > screen > > > > > if > > > > > > TV doesn't support DV. > > > > > > > > > > What will the user see if you send decoded DV content (lets say, via > cast > > > > ultra) > > > > > to a TV that doesn't support DV? > > > > > > > > We don't expect app to push data if DV isn't supported. App can query > > support > > > > via the API mentioned below. Not sure what will happen if app ignore the > > check > > > > and push DV to us. Eric, can you comment here? > > > > > > > > > > > > > > > Is this the expected behavior? > > > > > > > > > > Not sure yet... > > > > > > > > > > > (We have additional API to check whether the content can be played on > > > > screen) > > > > > > > > > > This suggests we can programatically detect whether the screen can > > support. > > > > How > > > > > feasible is it to add that detection logic to chromium? > > > > > > > > +servolk > > > > > > On Chromecast we are using HDMI EDID information to detect whether TV can > play > > > DolbyVision content. I don't know if chromium exposes HDMI EDID information > > > somewhere though internal APIs. But anyway, Chromium doesn't support > > > DolbyVision, so there's probably no point in moving that logic to Chromium > > code. > > > We should be fine with just a regular codec check via MediaClient and the > > > Chromecast's MediaClient will ensure that all the necessary conditions are > met > > > for DolbyVision playback (i.e. both the media decoder supports DV and the > > screen > > > supports DV). > > > > In theory, we should check in the EME path as well, because on Android there > is > > a distinction between secure and non-secure decode capabilities. The EME API > is > > the only way to check for secure output capability. > > > > However, in practice ... we don't support DV on ATV (and doing so is likely > > quite a way off) ... so I think this is fine for now. Could put a TODO if we > > want for the future. > > I saw changes in cdm_message_filter_android.cc, as well as the discussion on > secure and non-secure decoder on Android. But here we are saying "we don't > support DV on ATV", so do we really need the changes on Android? Sorry, I should have been clearer. * We do support DV demuxing on ATV, so we can play dual-layer DV streams. * But we only display the base layer. So there is no need to check that the display is DV-compatible. So we need the changes on Android, but what I mean is there is no need to check the display capability.
Thanks for the clarification. The change lg, what kind of test coverage do we have for the key system support on Cast?
On 2017/04/25 20:22:38, xhwang_slow wrote: > Thanks for the clarification. The change lg, what kind of test coverage do we > have for the key system support on Cast? We have an internal unit test to test requestMediaKeySystemAccess with contentType.
Thanks. Is it possible to upstream those tests? LGTM
On 2017/04/25 21:21:12, xhwang_slow wrote: > Thanks. Is it possible to upstream those tests? > > LGTM Yes, I can investigate how to split the test and upstream that part.
ping on this~
On 2017/04/26 16:01:07, yucliu1 wrote: > ping on this~ lgtm
lgtm - sorry for the delay
lgtm. thanks
The CQ bit was checked by yucliu@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 60001, "attempt_start_ts": 1493230345337600,
"parent_rev": "28a190c328089bf845181da368f16013108381b5", "commit_rev":
"f5ff9e38f2a20950f26f7afe79b175328ce5700d"}
Message was sent while issue was closed.
Description was changed from ========== EME contentType checks DolbyVision Add new enum to EmeCodec: EME_CODEC_MP4_DV_AVC EME_CODEC_MP4_DV_HEVC BUG=710167 TEST=requestMediaKeySystemAccess with dv codec on cast ========== to ========== EME contentType checks DolbyVision Add new enum to EmeCodec: EME_CODEC_MP4_DV_AVC EME_CODEC_MP4_DV_HEVC BUG=710167 TEST=requestMediaKeySystemAccess with dv codec on cast Review-Url: https://codereview.chromium.org/2809013002 Cr-Commit-Position: refs/heads/master@{#467431} Committed: https://chromium.googlesource.com/chromium/src/+/f5ff9e38f2a20950f26f7afe79b1... ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001) as https://chromium.googlesource.com/chromium/src/+/f5ff9e38f2a20950f26f7afe79b1... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
