search

cta-wave / Media-Capability-APIs

Collects CTA WAVE's comment on W3C Media Capability APIs
1 stars 0 forks source link

VideoConfiguration.hdrMetadata #4

Open haudiobe opened 4 years ago

haudiobe commented 4 years ago

https://w3c.github.io/media-capabilities/#videoconfiguration

If present, the hdrMetadataType member represents that the video track includes the specified HDR metadata type, which the UA needs to be capable of interpreting for tone mapping the HDR content to a color volume and luminance of the output device. Valid inputs are defined by HdrMetadataType

https://w3c.github.io/media-capabilities/#hdrmetadatatype

A couple of problems: 1) typically such data is in SEI values that can be ignored. What does it mean "interpretation"? 2) multiple metadata values may be present? How to specify this? Multiple calls? 3) The spec references are inaccurate, no receiver behaviour is defined? Metadata carriage may be quite different so quite unclear.

rdoherty0 commented 4 years ago

This field is insufficient to capture the versions of Hdr Dynamic Metadata currently in wide use in all major OTT services today, as nearly all streamed content in use do not fall into one of the specified enumerations.

Further, it is known that streams can carry more then one form of HDR Dynamic Metdaata at the same time, so an enumeration is not the correct form for this field.

Given these difficulties, this field may be more useful as a simple boolean that indicates the simple presence or absence of DM. This was the approach taken in the API's audio section for "spatialRendering" -- simply a simple indicator.

paul-hearty commented 4 years ago

Well, could it be fixed to enable carriage of more than one form of Dynamic Metadata? Also, how do we deal with ST.2086 being optional for the Base HDR10?

dehaanw commented 4 years ago

Booleans to indicate support for each of ST 2086, ST 2094-10, ST 2094-40 and SL-HDR could do the job. I don’t see a need for indication of variants within those major kinds of HDR Dynamic Metadata.

paul-hearty commented 4 years ago

Please explain what you mean by variants.

Get Outlook for Androidhttps://aka.ms/ghei36

From: Wiebe de Haan notifications@github.com Sent: Friday, May 8, 2020 1:41:51 AM To: cta-wave/Media-Capability-APIs Media-Capability-APIs@noreply.github.com Cc: paul-hearty phearty22@gmail.com; Comment comment@noreply.github.com Subject: Re: [cta-wave/Media-Capability-APIs] VideoConfiguration.hdrMetadata (#4)

Booleans to indicate support for each of ST 2086, ST 2094-10, ST 2094-40 and SL-HDR could do the job. I don’t see a need for indication of variants within those major kinds of HDR Dynamic Metadata.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/cta-wave/Media-Capability-APIs/issues/4#issuecomment-625709461, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APP2Z2C55FZA7C7EOVMKOJLRQPAU7ANCNFSM4M2US6JA.

dehaanw commented 4 years ago

Please explain what you mean by variants. Variants could be things like profiles or modes that may be defined for the HDR Dynamic Metadata formats mentioned.

rdoherty0 commented 4 years ago

One example of a variant would be SCTE Dynamic Metadata App #1, which references but then extends 2094-10. Another would be the various forms of SL-HDR (1/2/3). Clients are not interoperable, though there may be subsetting implementations. And it also does not allow for non-standard versions of Dynamic Metadata, even though they are in extensive use.

Overall, the specifics of the enumeration (2094-10/40) are not useful in this API as they do not represent the current state of content distribution nor future expansions without a lot of attention.

Overall, the field would be more useful if it simply signaled the presence/non-presence of DynamicMetadata support, and allow other mechanisms to negotiate the specifics. As an example, in this same API the Audio value is simply a boolean spatialRendering indicating the presence of spatial audio, rather than trying to enumerate all current and anticipated versions.

ST.2086 is another problem altogether, as the fields for 2086 are always present in the content, but they may or may not be set to rational values. Since the API represent device capabilities, the field should indicate whether the device can use and interpret valid 2086 data if it is present. This is orthogonal to the other dynamic metadata versions. This may be better served by a separate filed, "staticMetadata" that is also a boolean to indicate that the device can/can't make use of valid values.

paul-hearty commented 4 years ago

Thanks, Richard. That helps.

Paul

Paul J. Hearty PhD

Technology Advisors

Mobile: 858-774-9293

Email: mailto:phearty22@gmail.com phearty22@gmail.com

From: rdoherty0 notifications@github.com Sent: Friday, May 8, 2020 10:02 AM To: cta-wave/Media-Capability-APIs Media-Capability-APIs@noreply.github.com Cc: paul-hearty phearty22@gmail.com; Comment comment@noreply.github.com Subject: Re: [cta-wave/Media-Capability-APIs] VideoConfiguration.hdrMetadata (#4)

One example of a variant would be SCTE Dynamic Metadata App #1 https://github.com/cta-wave/Media-Capability-APIs/issues/1 , which references but then extends 2094-10. Another would be the various forms of SL-HDR (1/2/3). Clients are not interoperable, though there may be subsetting implementations. And it also does not allow for non-standard versions of Dynamic Metadata, even though they are in extensive use.

Overall, the specifics of the enumeration (2094-10/40) are not useful in this API as they do not represent the current state of content distribution nor future expansions without a lot of attention.

Overall, the field would be more useful if it simply signaled the presence/non-presence of DynamicMetadata support, and allow other mechanisms to negotiate the specifics. As an example, in this same API the Audio value is simply a boolean spatialRendering indicating the presence of spatial audio, rather than trying to enumerate all current and anticipated versions.

ST.2086 is another problem altogether, as the fields for 2086 are always present in the content, but they may or may not be set to rational values. Since the API represent device capabilities, the field should indicate whether the device can use and interpret valid 2086 data if it is present. This is orthogonal to the other dynamic metadata versions. This may be better served by a separate filed, "staticMetadata" that is also a boolean to indicate that the device can/can't make use of valid values.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cta-wave/Media-Capability-APIs/issues/4#issuecomment-625915991 , or unsubscribe https://github.com/notifications/unsubscribe-auth/APP2Z2CVWM3NPNBSJJXHA3TRQQ3HTANCNFSM4M2US6JA . https://github.com/notifications/beacon/APP2Z2D3DSLVTP5ISDQ42PLRQQ3HTA5CNFSM4M2US6JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEVHLQVY.gif

haudiobe commented 4 years ago

Please bear in mind that we are asking for CAPABILITIES. Are you supporting this and that capability? A list probably is incorrect as well. You probably need to run multiple loops, without DM present and then adding one after the other and then you know the capabilities. Based on the capabilities, you can then choose which one you wanna play.

haudiobe commented 4 years ago

Proposed resolution: 1) use for now as defined in latest document 2) add hlg to metadata and inform W3C 3) leave other aspects to the definition of dynamic metadata - not our business for now.

dehaanw commented 4 years ago

Why is hlg needed as a hdrMetadataType? There are 2 ways to signal hlg in the content, but hlg is a single capability and has nothing to do with metadata (it's just a flag). I assume all hlg supporting implementations can handle both ways of signaling.

rdoherty0 commented 4 years ago

HLG as an hdrMetadataType is NOT correct.
HLG is orthogonal to metadata -- HLG is an EOTF. Note that at least one of the existing HDR Metadata types (possibly all of them) can be applied to content encoded in HLG.

dehaanw commented 4 years ago

Richard is right. In fact, to cover all HDR Metadata types, SL-HDR should be added to the W3C spec:

haudiobe commented 4 years ago

DPCTF Call: no open issues for spec, but W3C may be asked for additional metadata types.