WebM support for new multipart VP9 string.

WebM support for new multipart VP9 string (behind flag)

The new string describes profile, level, bitdepth, color primaries,
eotf, matrix coefficients, full-range enable/disable, and chroma
subsampling.

Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

To enable parsing of the new vp9 string in webm, use the flag 
--enable-new-vp9-codec-string. 

Alternatively, to enable HDR AND new vp9 string in webm, use
--enable-hdr-output

To enable parsing (and demuxing) of vp9 in mp4, use the flag
--enable-vp9-in-mp4

BUG=687627
Review-Url: https://codereview.chromium.org/2723833002
Cr-Commit-Position: refs/heads/master@{#455548}
Committed: https://chromium.googlesource.com/chromium/src/+/9a285ed020220553b8c4f47883094ce8220d4086

[chcunningham, 2017-02-28 22:57:06]

The CQ bit was checked by chcunningham@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-28 22:57:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chcunningham, 2017-02-28 22:58:47]

Patchset #1 (id:1) has been deleted

[chcunningham, 2017-02-28 22:58:56]

The CQ bit was checked by chcunningham@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-28 22:59:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chcunningham, 2017-02-28 23:06:33]

chcunningham@chromium.org changed reviewers:
+ hubbe@chromium.org

[chcunningham, 2017-02-28 23:06:33]

Hey Hubbe

Here is the simple CL to add conditional isTypeSupported for the new 8 part
string. Some questions for you:

1. Take a look at RenderMediaClient - will this work for you to wire things up?

2. At the moment isTypeSupported makes no attempt to check whether any decoders
actually support the given profile. I'm working on adding a check for libvpx
[0]. Can you advise how to determine runtime support for HW acceleration?

3. I should probably put the 8-part string behind a flag. What flag are you
planning to use for the high-bit-depth mode?

[chcunningham, 2017-02-28 23:08:27]

> I'm working on adding a check for libvpx [0].

[0] https://chromium-review.googlesource.com/c/444255/

[chcunningham, 2017-02-28 23:17:36]

> I should probably put the 8-part string behind a flag. What flag are you
planning to use for the high-bit-depth mode?

Err... that was incomplete. We should probably be behind the same *finch
experiment*. Have you plumbed this for your CL

[hubbe, 2017-02-28 23:17:52]

LGTM

On 2017/02/28 23:06:33, chcunningham wrote:
> Hey Hubbe
> 
> Here is the simple CL to add conditional isTypeSupported for the new 8 part
> string. Some questions for you:
> 
> 1. Take a look at RenderMediaClient - will this work for you to wire things
up?
>

Yes, although the comments might need a little updating. However, I can fix that
when
I wire up the high bitdepth mode.
 
> 2. At the moment isTypeSupported makes no attempt to check whether any
decoders
> actually support the given profile. I'm working on adding a check for libvpx
> [0]. Can you advise how to determine runtime support for HW acceleration?
> 

Unfortunately, I have no clue. There is an API for it in gpu_video_decoder, but
currently it's backed by hard-coded lists, and I don't know how to actually
query it.

> 3. I should probably put the 8-part string behind a flag. What flag are you
> planning to use for the high-bit-depth mode?

Right now I'm using --enable-hdr-output, but that might change.

[commit-bot: I haz the power, 2017-02-28 23:24:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-28 23:24:42]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[hubbe, 2017-02-28 23:35:02]

On 2017/02/28 23:17:36, chcunningham wrote:
> > I should probably put the 8-part string behind a flag. What flag are you
> planning to use for the high-bit-depth mode?
> 
> Err... that was incomplete. We should probably be behind the same *finch
> experiment*. Have you plumbed this for your CL

I'm not currently planning to activate HDR with a finch experiment.
Right now, HDR is only useful for a small handful of enthusiasts, and
they will need to use a flag to activate it. That flag will probably
be "--enable-hdr", and show up in about:flags.

I would suggest that the vp9 string should be behind a separate feature
flag, and you would use a finch experiment to test and launch that
feature separately, but --enable-hdr will also enable it.

[chromium-reviews, 2017-02-28 23:37:03]

Actually let me correct that:

I don't think the vp9 string should use a finch experiment at all.
Instead, it should be checked in behind a flag, and once the spec is final,
that flag should just be flipped to on by default.

     /Hubbe

On Tue, Feb 28, 2017 at 3:35 PM, <hubbe@chromium.org> wrote:

> On 2017/02/28 23:17:36, chcunningham wrote:
> > > I should probably put the 8-part string behind a flag. What flag are
> you
> > planning to use for the high-bit-depth mode?
> >
> > Err... that was incomplete. We should probably be behind the same *finch
> > experiment*. Have you plumbed this for your CL
>
> I'm not currently planning to activate HDR with a finch experiment.
> Right now, HDR is only useful for a small handful of enthusiasts, and
> they will need to use a flag to activate it. That flag will probably
> be "--enable-hdr", and show up in about:flags.
>
> I would suggest that the vp9 string should be behind a separate feature
> flag, and you would use a finch experiment to test and launch that
> feature separately, but --enable-hdr will also enable it.
>
>
> https://codereview.chromium.org/2723833002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chcunningham, 2017-03-02 02:19:42]

chcunningham@chromium.org changed reviewers:
+ servolk@chromium.org

[chcunningham, 2017-03-02 02:19:43]

+servolk for cast/mediaclient

Take a look at render_media_client.cc and generally plumbing of eotf to
MediaClient. Any concerns?

Ignore the actual parsing in video_codecs.cc - not quite right yet, I'm looking
for a copy of the appropriate spec. Also, ignore the debugging logs.

Beyond that, I'm also still planning to gate with the runtime flag.

[servolk, 2017-03-02 18:56:31]

On 2017/03/02 02:19:43, chcunningham wrote:
> +servolk for cast/mediaclient
> 
> Take a look at render_media_client.cc and generally plumbing of eotf to
> MediaClient. Any concerns?
> 
> Ignore the actual parsing in video_codecs.cc - not quite right yet, I'm
looking
> for a copy of the appropriate spec. Also, ignore the debugging logs.
> 
> Beyond that, I'm also still planning to gate with the runtime flag.

Some nits, but my main concern is that the new VP9 codec id standardization
process is still in flux (the latest I could find is
https://docs.google.com/document/d/16kiRszCusuK-ph_3h2HKvPgk_zLuHiM1NUfdyIH8_...
and that's marked as draft with many unresolved comments). Or did I miss
something and there's later version where the values have been updated to match
ISO specs, etc?

[servolk, 2017-03-02 18:56:37]

https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
File chromecast/common/media/cast_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
chromecast/common/media/cast_media_client.cc:64: // TODO(servolk): make use of
eotf.
Nit: missing closing brace.
Also I think it might be better to add level to the VideoDecoderConfig and use
VideoDecoderConfig here, rather than copy pieces of VideoDecoderConfig into
parameters of this function.

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
File content/renderer/media/render_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:120: return
IsSdrTransferFunction(eotf) || IsHdrColorManagementEnabled();
VP9 profile 0 is SDR, profile 2 is HDR. I believe we want to always return true
for profile 0 and do this check only for profile 2.

https://codereview.chromium.org/2723833002/diff/40001/media/base/mime_util_in...
File media/base/mime_util_internal.h (right):

https://codereview.chromium.org/2723833002/diff/40001/media/base/mime_util_in...
media/base/mime_util_internal.h:118: // strings where EOTF is not described.
Yes, VP9 is the only codec that will have eotf in the codec id. H.264 / HEVC
don't have it and AFAIK are not planning to add eotf in the future.

https://codereview.chromium.org/2723833002/diff/40001/media/base/video_codecs.cc
File media/base/video_codecs.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/media/base/video_codecs...
media/base/video_codecs.cc:91: LOG(ERROR) << __func__ << " 0";
Nit: don't forget to remove this debug logging.

https://codereview.chromium.org/2723833002/diff/40001/media/base/video_codecs...
media/base/video_codecs.cc:160: case 0:
Are those values taken from
https://docs.google.com/document/d/16kiRszCusuK-ph_3h2HKvPgk_zLuHiM1NUfdyIH8_...
?
Looks like that's still in the draft stage, in particular there is this comment
thread
https://docs.google.com/a/google.com/document/d/16kiRszCusuK-ph_3h2HKvPgk_zLu...
which indicates these values are going to be changed to match ISO spec. Perhaps
we should wait until the VP9 codec id format is more standardized, before we add
this code?

[chcunningham, 2017-03-02 21:49:25]

On 2017/03/02 18:56:31, servolk wrote:
> Some nits, but my main concern is that the new VP9 codec id standardization
> process is still in flux.

Very true. Its expected to be finalized soon, so this is just me getting ready
for that. I will not land until we have the final document.

[chcunningham, 2017-03-02 23:13:09]

Thanks Sergey. Hubbe, can you take a look at the latest in
render_media_client.cc

https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
File chromecast/common/media/cast_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
chromecast/common/media/cast_media_client.cc:64: // TODO(servolk): make use of
eotf.
On 2017/03/02 18:56:36, servolk wrote:
> Nit: missing closing brace.]

I'm not seeing it. Do you mean the brace for the method on line 73?

> Also I think it might be better to add level to the VideoDecoderConfig and use
> VideoDecoderConfig here, rather than copy pieces of VideoDecoderConfig into
> parameters of this function.

Ack. Will go ahead and plumb that.

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
File content/renderer/media/render_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:120: return
IsSdrTransferFunction(eotf) || IsHdrColorManagementEnabled();
On 2017/03/02 18:56:36, servolk wrote:
> VP9 profile 0 is SDR, profile 2 is HDR. I believe we want to always return
true
> for profile 0 and do this check only for profile 2.

My understanding from hubbe is that profile 2 doesn't have to be HDR, it can
instead just be "wide gamut". This is what motivated the change from PS1 which
just checked profile. IIUC, eotf is the most direct check for "is HDR". Agree
that we could skip this check for earlier profiles, but this check should also
work (they won't use HDR eotf) and its probably simpler logic to go this route.

https://codereview.chromium.org/2723833002/diff/40001/media/base/mime_util_in...
File media/base/mime_util_internal.h (right):

https://codereview.chromium.org/2723833002/diff/40001/media/base/mime_util_in...
media/base/mime_util_internal.h:118: // strings where EOTF is not described.
On 2017/03/02 18:56:36, servolk wrote:
> Yes, VP9 is the only codec that will have eotf in the codec id. H.264 / HEVC
> don't have it and AFAIK are not planning to add eotf in the future.

Ack. This comment is actually stale. I'm planning to default eotf to BT709 when
its not supplied in the codec string (following what we already do for color
space in https://crrev.com/1221903003/). 

For HEVC I wonder if eotf is signalled in the mime via the "up to 6 constraint
bytes, bytes are dot-separated and hex-encoded." Or does HEVC imply a particular
(singular) EOTF would be used?

https://codereview.chromium.org/2723833002/diff/40001/media/base/video_codecs.cc
File media/base/video_codecs.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/media/base/video_codecs...
media/base/video_codecs.cc:91: LOG(ERROR) << __func__ << " 0";
On 2017/03/02 18:56:36, servolk wrote:
> Nit: don't forget to remove this debug logging.

Acknowledged.

https://codereview.chromium.org/2723833002/diff/40001/media/base/video_codecs...
media/base/video_codecs.cc:160: case 0:
On 2017/03/02 18:56:36, servolk wrote:
> Are those values taken from
>
https://docs.google.com/document/d/16kiRszCusuK-ph_3h2HKvPgk_zLuHiM1NUfdyIH8_...
> ?
> Looks like that's still in the draft stage, in particular there is this
comment
> thread
>
https://docs.google.com/a/google.com/document/d/16kiRszCusuK-ph_3h2HKvPgk_zLu...
> which indicates these values are going to be changed to match ISO spec.
Perhaps
> we should wait until the VP9 codec id format is more standardized, before we
add
> this code?

Right, these values are taken from a draft which is expected to be replaced by
values from ISO/IEC 23001-8:2016. I'll buy that spec and update accordingly.

[hubbe, 2017-03-02 23:37:11]

lgtm

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
File content/renderer/media/render_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:92: bool
IsHdrColorManagementEnabled() {
Remove this function for now.

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:97: bool
IsSdrTransferFunction(gfx::ColorSpace::TransferID eotf) {
Make this IsTransferFunctionSupported().

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:120: return
IsSdrTransferFunction(eotf) || IsHdrColorManagementEnabled();
On 2017/03/02 23:13:08, chcunningham wrote:
> On 2017/03/02 18:56:36, servolk wrote:
> > VP9 profile 0 is SDR, profile 2 is HDR. I believe we want to always return
> true
> > for profile 0 and do this check only for profile 2.
> 
> My understanding from hubbe is that profile 2 doesn't have to be HDR, it can
> instead just be "wide gamut". This is what motivated the change from PS1 which
> just checked profile. IIUC, eotf is the most direct check for "is HDR". Agree
> that we could skip this check for earlier profiles, but this check should also
> work (they won't use HDR eotf) and its probably simpler logic to go this
route. 

Profile 2 is just more bits per channel, and has nothing to do with HDR, or even
wide gamut.

Profile 2 is however a requirement for HDR.

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:120: return
IsSdrTransferFunction(eotf) || IsHdrColorManagementEnabled();
Just call IsTransferFunctionSupported() here.

[chcunningham, 2017-03-07 02:17:37]

The CQ bit was checked by chcunningham@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-07 02:18:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chcunningham, 2017-03-07 02:27:56]

Added tests and addressed comments. 


On 2017/03/02 21:49:25, chcunningham wrote:
> On 2017/03/02 18:56:31, servolk wrote:
> > Some nits, but my main concern is that the new VP9 codec id standardization
> > process is still in flux.
> 
> Very true. Its expected to be finalized soon, so this is just me getting ready
> for that. I will not land until we have the final document.

Actually, now that this is behind a flag, I think we should be good to land as
soon as everyone is happy with the code. Spec for the new string will be out
soon enough and I will update if there are any revisions. When things are
settled we can also remove the flag.

https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
File chromecast/common/media/cast_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
chromecast/common/media/cast_media_client.cc:64: // TODO(servolk): make use of
eotf.
On 2017/03/02 23:13:08, chcunningham wrote:
> On 2017/03/02 18:56:36, servolk wrote:
> > Nit: missing closing brace.]
> 
> I'm not seeing it. Do you mean the brace for the method on line 73?
> 
> > Also I think it might be better to add level to the VideoDecoderConfig and
use
> > VideoDecoderConfig here, rather than copy pieces of VideoDecoderConfig into
> > parameters of this function.
> 
> Ack. Will go ahead and plumb that. 

Done.

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
File content/renderer/media/render_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:92: bool
IsHdrColorManagementEnabled() {
On 2017/03/02 23:37:11, hubbe wrote:
> Remove this function for now.

Done.

https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
content/renderer/media/render_media_client.cc:97: bool
IsSdrTransferFunction(gfx::ColorSpace::TransferID eotf) {
On 2017/03/02 23:37:11, hubbe wrote:
> Make this IsTransferFunctionSupported().

Done.

[chcunningham, 2017-03-07 02:30:42]

Description was changed from

==========
WebM support for new 8-part VP9 string.

The new string describes profile, level, and other codec details.
Example:

  MediaSource.isTypeSupported(
    'video/webm;codecs="vp09.01.01.08.01.01.00.00"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For high bit depth profiles (>=2) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running in high-bit-depth-mode.

When 0 <= profile < 2 , canPlayType will return "maybe", as decoder
support is not yet queried. isTypeSupported will return true.
Checking decoder support will be added in a follow up CL.

BUG=687627
==========

to

==========
WebM support for new 8-part VP9 string.

The new string describes profile, level, and other codec details.
Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

BUG=687627
==========

[servolk, 2017-03-07 02:39:48]

On 2017/03/07 02:27:56, chcunningham wrote:
> Added tests and addressed comments. 
> 
> 
> On 2017/03/02 21:49:25, chcunningham wrote:
> > On 2017/03/02 18:56:31, servolk wrote:
> > > Some nits, but my main concern is that the new VP9 codec id
standardization
> > > process is still in flux.
> > 
> > Very true. Its expected to be finalized soon, so this is just me getting
ready
> > for that. I will not land until we have the final document.
> 
> Actually, now that this is behind a flag, I think we should be good to land as
> soon as everyone is happy with the code. Spec for the new string will be out
> soon enough and I will update if there are any revisions. When things are
> settled we can also remove the flag.
> 
>
https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
> File chromecast/common/media/cast_media_client.cc (right):
> 
>
https://codereview.chromium.org/2723833002/diff/40001/chromecast/common/media...
> chromecast/common/media/cast_media_client.cc:64: // TODO(servolk): make use of
> eotf.
> On 2017/03/02 23:13:08, chcunningham wrote:
> > On 2017/03/02 18:56:36, servolk wrote:
> > > Nit: missing closing brace.]
> > 
> > I'm not seeing it. Do you mean the brace for the method on line 73?
> > 
> > > Also I think it might be better to add level to the VideoDecoderConfig and
> use
> > > VideoDecoderConfig here, rather than copy pieces of VideoDecoderConfig
into
> > > parameters of this function.
> > 
> > Ack. Will go ahead and plumb that. 
> 
> Done.
> 
>
https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
> File content/renderer/media/render_media_client.cc (right):
> 
>
https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
> content/renderer/media/render_media_client.cc:92: bool
> IsHdrColorManagementEnabled() {
> On 2017/03/02 23:37:11, hubbe wrote:
> > Remove this function for now.
> 
> Done.
> 
>
https://codereview.chromium.org/2723833002/diff/40001/content/renderer/media/...
> content/renderer/media/render_media_client.cc:97: bool
> IsSdrTransferFunction(gfx::ColorSpace::TransferID eotf) {
> On 2017/03/02 23:37:11, hubbe wrote:
> > Make this IsTransferFunctionSupported().
> 
> Done.

Mostly lgtm, let's just add a test for new codec ids in
content/browser/media/media_canplaytype_browsertest.cc for complete end-to-end
testing?

[commit-bot: I haz the power, 2017-03-07 02:49:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-07 02:49:18]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[hubbe, 2017-03-07 19:22:16]

https://codereview.chromium.org/2723833002/diff/80001/content/renderer/media/...
File content/renderer/media/render_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/80001/content/renderer/media/...
content/renderer/media/render_media_client.cc:92: bool
IsHdrColorManagementEnabled() {
Remove?

[chcunningham, 2017-03-07 23:59:17]

Thanks guys!

> Mostly lgtm, let's just add a test for new codec ids in
> content/browser/media/media_canplaytype_browsertest.cc for complete end-to-end
> testing?

Done. I updated all of the mentions of vp09.xx.... to use the latest format and
modified the existing vp9-in-mp4 test to additionally test new-vp9-in-webm. 

I used the simplified version of the new format in content_browsertests, leaving
thorough parsing for the video_codecs_unittest

https://codereview.chromium.org/2723833002/diff/80001/content/renderer/media/...
File content/renderer/media/render_media_client.cc (right):

https://codereview.chromium.org/2723833002/diff/80001/content/renderer/media/...
content/renderer/media/render_media_client.cc:92: bool
IsHdrColorManagementEnabled() {
On 2017/03/07 19:22:16, hubbe wrote:
> Remove?

Done.

[chcunningham, 2017-03-07 23:59:28]

The CQ bit was checked by chcunningham@chromium.org

[chcunningham, 2017-03-07 23:59:28]

The patchset sent to the CQ was uploaded after l-g-t-m from hubbe@chromium.org,
servolk@chromium.org
Link to the patchset: https://codereview.chromium.org/2723833002/#ps100001
(title: "Feedback")

[chcunningham, 2017-03-07 23:59:46]

The CQ bit was unchecked by chcunningham@chromium.org

[chcunningham, 2017-03-08 00:02:25]

Description was changed from

==========
WebM support for new 8-part VP9 string.

The new string describes profile, level, and other codec details.
Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

BUG=687627
==========

to

==========
WebM support for new 8-part VP9 string (behind flag).

The new string describes profile, level, and other codec details.
Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

To enable parsing of the new vp9 string in webm, use the flag 
--enable-new-vp9-codec-string. 

Alternatively, to enable HDR AND new vp9 string in webm, use
--enable-hdr-output

To enable parsing (and demuxing) of vp9 in mp4, use the flag
--enable-vp9-in-mp4

BUG=687627
==========

[chcunningham, 2017-03-08 00:07:33]

Description was changed from

==========
WebM support for new 8-part VP9 string (behind flag).

The new string describes profile, level, and other codec details.
Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

To enable parsing of the new vp9 string in webm, use the flag 
--enable-new-vp9-codec-string. 

Alternatively, to enable HDR AND new vp9 string in webm, use
--enable-hdr-output

To enable parsing (and demuxing) of vp9 in mp4, use the flag
--enable-vp9-in-mp4

BUG=687627
==========

to

==========
WebM support for new multipart VP9 string (behind flag)

The new string describes profile, level, bitdepth, color primaries,
eotf, matrix coefficients, full-range enable/disable, and chroma
subsampling.

Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

To enable parsing of the new vp9 string in webm, use the flag 
--enable-new-vp9-codec-string. 

Alternatively, to enable HDR AND new vp9 string in webm, use
--enable-hdr-output

To enable parsing (and demuxing) of vp9 in mp4, use the flag
--enable-vp9-in-mp4

BUG=687627
==========

[chcunningham, 2017-03-08 00:08:22]

The CQ bit was checked by chcunningham@chromium.org

[commit-bot: I haz the power, 2017-03-08 00:09:10]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-08 00:21:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-08 00:21:21]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[chcunningham, 2017-03-08 00:28:45]

chcunningham@chromium.org changed reviewers:
+ halliwell@chromium.org, jam@chromium.org

[chcunningham, 2017-03-08 00:28:46]

+halliwell for chromecast
+jam for content

[halliwell, 2017-03-08 00:37:10]

On 2017/03/08 00:28:46, chcunningham wrote:
> +halliwell for chromecast
> +jam for content

chromecast/ lgtm

[chcunningham, 2017-03-08 00:39:15]

The CQ bit was checked by chcunningham@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-08 00:40:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-08 03:39:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-08 03:39:59]

Dry run: This issue passed the CQ dry run.

[chcunningham, 2017-03-08 18:00:01]

chcunningham@chromium.org changed reviewers:
+ avi@chromium.org
- jam@chromium.org

[chcunningham, 2017-03-08 18:00:02]

+avi@ for content (jam@ is OOO)

[Avi (use Gerrit), 2017-03-08 18:29:02]

content lgtm

[chcunningham, 2017-03-08 18:56:46]

The CQ bit was checked by chcunningham@chromium.org

[chcunningham, 2017-03-08 18:56:46]

The patchset sent to the CQ was uploaded after l-g-t-m from
servolk@chromium.org, halliwell@chromium.org, hubbe@chromium.org
Link to the patchset: https://codereview.chromium.org/2723833002/#ps120001
(title: "Rebase. Simplify test.")

[commit-bot: I haz the power, 2017-03-08 18:57:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-08 19:07:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-08 19:07:24]

Failed to apply patch for chromecast/common/media/cast_media_client.h:
While running git apply --index -p1;
  error: patch failed: chromecast/common/media/cast_media_client.h:30
  error: chromecast/common/media/cast_media_client.h: patch does not apply

Patch:       chromecast/common/media/cast_media_client.h
Index: chromecast/common/media/cast_media_client.h
diff --git a/chromecast/common/media/cast_media_client.h
b/chromecast/common/media/cast_media_client.h
index
e6fa9ab4a3b9855ef844396cfb715e860ffeeea3..15550a4e8bde9847000cb1a59f2d552c7f39b4d9
100644
--- a/chromecast/common/media/cast_media_client.h
+++ b/chromecast/common/media/cast_media_client.h
@@ -30,9 +30,7 @@ class CastMediaClient : public ::media::MediaClient {
       std::vector<std::unique_ptr<::media::KeySystemProperties>>*
           key_systems_properties) override;
   void RecordRapporURL(const std::string& metric, const GURL& url) override;
-  bool IsSupportedVideoConfig(::media::VideoCodec codec,
-                              ::media::VideoCodecProfile profile,
-                              int level) override;
+  bool IsSupportedVideoConfig(const ::media::VideoConfig& config) override;
 
  private:
   friend struct base::DefaultLazyInstanceTraits<CastMediaClient>;

[chcunningham, 2017-03-08 19:42:59]

The CQ bit was checked by chcunningham@chromium.org

[chcunningham, 2017-03-08 19:42:59]

The patchset sent to the CQ was uploaded after l-g-t-m from hubbe@chromium.org,
avi@chromium.org, servolk@chromium.org, halliwell@chromium.org
Link to the patchset: https://codereview.chromium.org/2723833002/#ps140001
(title: "Rebase")

[commit-bot: I haz the power, 2017-03-08 19:43:52]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-08 21:49:00]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1489002179444810,
"parent_rev": "95ff5bc751ba619a7c37155eec85c1adcadb01bc", "commit_rev":
"9a285ed020220553b8c4f47883094ce8220d4086"}

[commit-bot: I haz the power, 2017-03-08 21:50:45]

Description was changed from

==========
WebM support for new multipart VP9 string (behind flag)

The new string describes profile, level, bitdepth, color primaries,
eotf, matrix coefficients, full-range enable/disable, and chroma
subsampling.

Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

To enable parsing of the new vp9 string in webm, use the flag 
--enable-new-vp9-codec-string. 

Alternatively, to enable HDR AND new vp9 string in webm, use
--enable-hdr-output

To enable parsing (and demuxing) of vp9 in mp4, use the flag
--enable-vp9-in-mp4

BUG=687627
==========

to

==========
WebM support for new multipart VP9 string (behind flag)

The new string describes profile, level, bitdepth, color primaries,
eotf, matrix coefficients, full-range enable/disable, and chroma
subsampling.

Example:

  MediaSource.isTypeSupported(
    'video/webm; codecs="vp09.02.01.10.09.01.09.01.01"')

Ordering and required feilds are still under discussion, but this
reflects the latest proposal.

For HDR EOTFs (e.g. SMPTEST2084) canPlayType/isTypeSupported will
return ""/false until RenderMediaClient is made aware of whether
chrome is running with hdr output enabled.

To enable parsing of the new vp9 string in webm, use the flag 
--enable-new-vp9-codec-string. 

Alternatively, to enable HDR AND new vp9 string in webm, use
--enable-hdr-output

To enable parsing (and demuxing) of vp9 in mp4, use the flag
--enable-vp9-in-mp4

BUG=687627

Review-Url: https://codereview.chromium.org/2723833002
Cr-Commit-Position: refs/heads/master@{#455548}
Committed:
https://chromium.googlesource.com/chromium/src/+/9a285ed020220553b8c4f4788309...
==========

[commit-bot: I haz the power, 2017-03-08 21:50:47]

Committed patchset #7 (id:140001) as
https://chromium.googlesource.com/chromium/src/+/9a285ed020220553b8c4f4788309...