Discussion of Parity between DASH HLS in regards to passing user agent Information

[Yasser-Comcast]

Zach Suggested that I write this up so I am doing so.
We talk about parity between HLS and DASH and one aspect of this is what information gets presented to the user agent ( e.g. information that is presented to the viewer such that he could chose certain option for playback/selection of the content). Some of this information may need to come from out of band or passed through the manifest. Otherwise this information needs to be retrieved from examining the stream itself ( "dig into the stream") which may cause a delay.

Examples of this are selection of video closed captioning languages ( 1 of 4 possible selections languages). Other examples could be certain types of SEI messages that apply to the stream ( e.g. Frame packing, HDR signaling, and others).

It may just end up being aminor factor, but just wanted to see if people had any thoughts about this?

[technogeek00]

Precursor investigation task for manifest/playlist level signaling items that would fit interoperability spec.
This issue is a fairly broad item and should have individual issues broken out to stand-alone or other interop use cases (existing or new).

[technogeek00]

Topics for consideration

• Video embedded closed-caption languages
  • Surfacing of information prior to media download for selection by app / player
• SEI Message types
  • Frame packing
  • HDR signaling

[technogeek00]

Note: "user-agent" term usage potentially confusing, intent is to surface media stream information out of player prior to segment download, rename for clarity.

[technogeek00]

Main purpose is to callout there are use cases where information being passed to the user-agent / client application earlier than download of stream bytes would be useful and should surface this information consistently in the manifest formats. We've pulled some cases described above and will open further individual tickets about cases as appropriate.