Fall 2023 HLS-Interest Group Meeting

[technogeek00]

This issue summarizes interoperability issues between DASH and HLS that this group has identified for potential discussion in the 2023 HLS Interest Group meeting.

Update 2023/09/20 - Added Previous issue discussion links from interop group

CMAF Image-Based Subtitle Track Support

Eliminated this topic based on previous close out #38 (comment). Will not suggest for HLS Interest Meeting unless a use case comes forward.

Low Latency - Priority Signaling

Updated HLS Specification will carry text on the use of priorities with HTTP/3 and HTTP/2 which will make priorities a requirement to low-latency enablement.

Previous Discussion: Issue #34

Questions / Talking Points:

• Is this additional requirement acceptable from a community point of view?
• If so, is this something that the DASH community would adopt with similar value alignments or could there be potential mismatches?

Low Latency Preload Hint vs Partial Segment

Preload hints provide the ability to utilize chunk encoded transfer to stream full segments during production while part descriptions allow for individual partial segments to be described.

Previous Discussion: Issue #18

Questions / Talking Points

• Are there deployment experiences at this point that point to favoring one or the other?
• DASH is finalizing partial segment addressing, is their any addressing constraints / requirements necessary that would be restrictive back on HLS?

Low Latency - Latency Target Parameters

A deployment ecosystem may have target latency requirements that must be enforced in order to allow low latency playback. The ideal scenario is for the content provider to signal the latency targets as part of the content manifest/playlist and for players to only attempt low latency playback if the target can be met.

Previous Discussion: Issue #30

Questions / Talking Points

• Would it be possible to formalize the carriage of this information in HLS similar to its formalization in DASH?
• To accomplish this a formal producer reference time would also have to be signaled within HLS, previously this was purposefully underspecified, is this something that we would want to change?

Encrypted Presentations - CTR Signaling

Industry standard nomenclature has recommended "SAMPLE-AES-CTR" as the EXT-X-KEY METHOD value. We have formalized this within the DASH-HLS Interop specification.

Previous Discussion: Issue #19

Questions / Talking Points

• Would it worth making the value officially supported by the specification due to the continued existence of CTR only devices?

Encrypted Presentations - Improved Multi-Key Signaling

It is becoming more common for streaming deployments to utilize license challenges that contain multiple keys at the start of the session to avoid the overhead of multiple license round trips and/or potential stalls due to adaptation across key boundaries. Currently HLS provides EXT-X-SESSION-KEY signaling but explicitly does not align tags to specific variants meaning that the player will still not understand if it can adapt or not without downloading the Variant Playlist.

Previous Discussion: None Formal

Questions / Talking Points

• Can we introduce signaling on variant descriptors in the multi-variant that identify the associated keys to assist client adaptation logic?

Timed Event Data - Playlist Signaling of Embedded Event Streams

Certain deployment scenarios desire to utilize embedded event streams to provide segment aligned data and/or just-in-time messages to end clients. In most cases the content provider understands if an embedded event stream exists in the content and desires to signal the presence of the embedded stream within the manifest / playlist.

Previous Discussion: Issue #36

Questions / Talking Points

• Would it be possible to add embedded event stream signaling into the variant playlist?
• At the multi-variant level can a signal also be carried to avoid missing messages in non-playing variants? (Industry to confirm use case)

Timed Event Data - DASH-HLS Interop Event Binding

The carriage of manifest/playlist level event streams did not have exact equality when semantically converting between the DASH and HLS formats. To bridge this the DASH-HLS interoperability group created the HLS Event Data Binding (CTA-5005 Annex A) which attempts to commonly map event data to EXT-X-DATERANGE tags.

Previous Discussion: Issue #35

Questions / Talking Points

• Wanted to surface this for general industry reference
• Would there be any interest or desire in better formalizing data event streams within Playlists or is EXT-X-DATERANGE enough?

CMAF Tracks - Role Description

CMAF recommends the "urn:mpeg:dash:role:2011" scheme to be used for carrying track role description in the role box. Players commonly want access to this data without parsing the underlying initialization box and in HLS this signaling is supported by Media Characteristic Tags.

Previous Discussion: Issue #40

Questions / Talking Points

• There are gaps in representation ability for publicly known MCTs, should additional well-known public ones be established to capture the missing intents?
  • commentary
  • sign
  • metadata
  • emergency
  • karaoke
  • enhanced-audio-intelligibility => public.accessibility.enhances-speech-intelligibility (proposed previously but was it made official?)
• Alternatively would a MCT scheme specification that binds the full "urn:mpeg:dash:role:2011" values be worth exploring?

Live - Incremental Manifest/Playlist Updates

The update size of manifests and playlists is becoming increasingly important in live update workflows. The HLS specification introduced the concept of Playlist Delta Updates to accommodate this with some semantics to reduce the main update size.

Previous Discussion: Issue #31

Questions / Talking Points

• The DASH-HLS interoperability group is slated to start working on interop compliance between DASH MPD Patch and HLS Delta Updates so a general walkthrough of the HLS Delta Update mechanic would be appreciated
• The Delta Update mechanism appears to constrain the client response to a minimum segment description size, is there a reason for this instead of providing a true delta?

Content Steering

DASH-HLS Interop is generally interested in this topic and will bring notes on identified differences to assist in the other queued conversations.

Previous Discussion: Issue #33

[technogeek00]

Raw notes from 08/23 DASH-HLS Meeting:

CMAF Image Tracks
- What is the use case that is not covered?

Low Latency
- Priority signaling already in github
- Any incompatibility in chunk signaling?
- Need latest updates from MPEG on DASH side
- Latency target parameters (already in github)
- Producer time reference (already in github)
-

Encrypted Presentations
- Did "SAMPLE-AES-CTR" officially get recognized?
- Relation of EXT-X-SESSION-KEY tags to explicit variants

Timed Event Data
- Playlist level signaling of embedded event streams
- Highlight HLS Event Data Binding we did to enable better interop

Roles
- Any gaps in ability to do Role signaling via MCTs?

Content Steering
- Dash-Industry-Forum/Content-Steering#26

[technogeek00]

Per last meeting I've updated this issue description to include the topics we've identified and provided summaries / talking points for each.

[AUGxhub]

1. priorities with HTTP/3 and HTTP/2 which will make priorities a requirement to low-latency enablement.
   ->
   can using <BaseURL make different download path load balance , refer dvb dash spec ,

2. Low Latency Preload Hint vs Partial Segment
   -> just skip sidx and enable partial http response is fine(http code 206)

3.Low Latency - Latency Target Parameters
-> DASH 4th spec looks already have this ,how about check newer DASH spec ISO/IEC 23009-1
prft

4.Encrypted Presentations - CTR Signaling
-> refer CENC spec ISO/IEC 23001-7 , and mark as cenc which is AES-CTR , and cbcs for AES-CBC

5.Encrypted Presentations - Improved Multi-Key Signaling
-> can be using ContentProtection in MPD manifest , or pssh senc sgpd sbgp in media segment to signal change key

for DRM related topic , can refer ISO/IEC 23001-7 to figure out solutions .

6.Timed Event Data - Playlist Signaling of Embedded Event Streams
-> there are many tools can be using in DASH , refer ISO/IEC 23009-1 5.10.1 Event chapter will give you answer

7. Timed Event Data - DASH-HLS Interop Event Binding
   -> refer ANSI/scte-214 ANSI/scte-35

---

form above question(s)
It's better find DASH spec firstly , to check if there already exist attributers or mechanism to meet requirements .
Or , it's better check 3rd part DASH packager how to meet above function/requirements , like akaimai , CDN/Cloud company have keep solving the "Media Delivery for Different Devices" task, they may already have knowledge how to prefill the gap between streaming protocols :)

[technogeek00]

Thanks for the callouts @AUGxhub ! I'll capture those details in our aligned issues where missing. I should have provided links to each previous discussion topic so the history and conclusions leading to the CTA-5005 / CTA-5005-A implementations was easily searchable for everyone. For easy reference I've gone through an updated the issue description with the links, my apologies for the miss. Cheers!

[theRealRobG]

Hey @technogeek00 , do you think it's worth discussing whether there should be any guidance provided on a single player solution to HLS Interstitials?

As far as I can see, the leading proposal for SGAI in DASH is via use of XLink, which implies (at least to me) a single player/timeline management solution. Therefore, any player implementation that is looking to support both formats, ideally would have a consistent internal model for timeline reasoning after having dealt with parsing from each format. So it seems like a fit for the theme of HLS/DASH interoperability.

On the other hand, this topic would be more about a specific implementation of a HLS client (e.g. MSE), rather than directly HLS related. Also, I don't see anything specifically declaring "dual-player" as the official approach in Appendix D, so perhaps that sort of advice doesn't belong with the spec, and so I understand if the group meeting is not the right place for this discussion (still a discussion I'd like to have at some opportunity).

Also, +1 to improved multi-key signaling in HLS 👍

On the topic of HLS Delta updates, the nice thing about the "minimum segment description size" approach is that it is stateless, so really easy to implement even as a proxy layer that is easily cacheable even if for a short TTL (at least with the v1 approach). From what I can see with patch updates, it requires knowing the previous document that the client has received, and the most up to date document, such that a diff can be made. In any case, I agree that it would be good to learn more about the reasoning behind the choice of the HLS direction.