Re: [Hls-interest] Content Steering, Multiple Service Locations and Client Behaviour

[Roger Pantos <[e-mail]>]

More more thing, inline:

> On Oct 9, 2023, at 2:43 PM, Roger Pantos <rpantos=[e-mail]> wrote:
> 
> Hello Thomas. My responses inline:
> 
>> On Oct 8, 2023, at 7:26 AM, Thomas Stockhammer <[e-mail]> wrote:
>> 
>> Dear colleagues,
>>  
>> As DASH-IF Interop WG Chair, I was asked to provide a request to this group.
>>  
>> DASH-IF has developed a Content Steering specification (which went through two community reviews). One of the core aspects is the alignment with the solution provided for HLS. Here are some details on the spec.
>>  
>> Scope
>> Content distributors often use multiple Content Delivery Networks (CDNs) to distribute their content to the end-users. They may upload a copy of their catalogue to each CDN, or more commonly have all CDNs pull the content from a common origin. Alternate URLs are generated, one for each CDN, that point at identical content. DASH players may access alternate URLs in the event of delivery problems. Content steering describes a deterministic capability for a content distributor to switch the content source that a player uses either at start-up or midstream, by means of a remote steering service.
>> 
>> Disclaimer
>> This document is a candidate Technical Specification. DASH-IF is publishing this specification initially, but the document has been submitted to ETSI and ETSI is asked to publish this document under the Publicly Available Specifications (PAS) agreement. For details on the PAS process, please refer to ETSI PAS Process Guide: https://www.etsi.org/images/files/ETSI_PAS_Process_Guide.pdf. Note that the ETSI specification may be different, addressing editorial updates. In addition, in case of any identified issues or bugs, please file issues here: https://github.com/Dash-Industry-Forum/Content-Steering/issues.
>> 
>> Latest Version
>> ·         DASH-IF Candidate Technical Specification 001: Content Steering for DASH v1.0.0 <https://github.com/Dash-Industry-Forum/Dash-Industry-Forum.github.io/files/11722876/DASH-IF-CTS-001-1.0.0.pdf> (IPR Declarations <https://dashif.org/ipr-declarations/>)
>>  
>> We are in the final stage of publishing the document through ETSI, but in this context an issue arised, which can be tracked here: https://github.com/Dash-Industry-Forum/Content-Steering/issues/26.
>>  
>> Based on feedback from an operator (details in the issue), the following scenario is considered:
>> A manifest is offered with different service locations/pathway
>> The service locations/pathway have different content (for example one includes the HD version, the other one the SD version, or one includes the English version of the audio track and the other one the German)
>>  
>> Assuming the above, the client may operate in one of the two following ways:
>> The client selects the content based on its/the user’s preference, regardless of the information from the Content Steering Server.
>> The client is only permitted to select content from a pathway/service location that is prohibited by the Content Steering Server.
>>  
>> Currently, the specification above is towards option 1, and also our dash.js implementation is accordingly. The use case provided by the content provider is more towards the second, it intended to “enforce” switching clients towards the SD or HD content.
>>  
>> As the DASH solution is intended to closely align with HLS, we would like to seek answers to the following questions
>>  
>> Does the HLS content steering solution permit (by design or implicitly), that different content is offered on different pathways/service location?
> 
> Yes. The most conventional way to achieve this is to follow this example:
> 
> # All resolutions available on cdn-A
> #EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720,PATHWAY-ID="A"
> https://cdn-A/asset-HD/2M.m3u8 <https://cdn-a/asset-HD/2M.m3u8>
> #EXT-X-STREAM-INF:BANDWIDTH=7000000,RESOLUTION= 4096×2160,PATHWAY-ID="A"
> https://cdn-A/asset-UHD/7M.m3u8 <https://cdn-a/asset-UHD/7M.m3u8>
> 
> # Only HD resolutions available on cdn-B
> #EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720,PATHWAY-ID="B"
> https://cdn-B/asset-HD/2M.m3u8 <https://cdn-b/asset-HD/2M.m3u8>
> 
> Given the rules specified in https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis/#section-7 a client on pathway "A" may choose between the 4K and 720p variant stream, but a client on pathway "B" can only choose the 720p stream.
> 
> It might be reasonable to limit higher bit rates to certain pathways, as in this example, for reasons of per-CDN cost or performance. But I would consider it to be something of an abuse to use content steering to restrict the client to certain language choices (English or German). I could several cases where this could lead to playback failures or other undesirable experiences. If there's a stated use case for restricting certain languages to certain pathways, we should discuss its requirements further.

I should note that if the desire is to limit content to CDNs serving a particular geography (for example to restrict German audio renditions to a European-focused CDN) then the recommended approach is to have every Pathway include URLs to that content on that CDN. That way users in other parts of the world still get access to the content, just from a less-optimal CDN. 

To continue the example further:

#EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720,PATHWAY-ID="A",AUDIO="cdn-A-audio"
https://cdn-A/asset-HD/2M.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=7000000,RESOLUTION= 4096×2160,PATHWAY-ID="A",AUDIO="cdn-A-audio"
https://cdn-A/asset-UHD/7M.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720,PATHWAY-ID="B",AUDIO="cdn-B-audio"
https://cdn-B/asset-HD/2M.m3u8

#EXT-X-MEDIA:TYPE=AUDIO, GROUP-ID="cdn-A-audio", LANGUAGE="eng", NAME="English", AUTOSELECT=YES, DEFAULT=YES,URI="https://cdn-A/asset/audio_eng.m3u8"
#EXT-X-MEDIA:TYPE=AUDIO, GROUP-ID="cdn-A-audio", LANGUAGE="de", NAME="Deutsch", AUTOSELECT=YES, DEFAULT=YES,URI="https://cdn-A/asset/audio_de.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO, GROUP-ID="cdn-B-audio", LANGUAGE="eng", NAME="English", AUTOSELECT=YES, DEFAULT=YES,URI="https://cdn-B/asset/audio_eng.m3u8"
#EXT-X-MEDIA:TYPE=AUDIO, GROUP-ID="cdn-B-audio", LANGUAGE="de", NAME="Deutsch", AUTOSELECT=YES, DEFAULT=YES,URI="https://cdn-A/asset/audio_de.m3u8"

Note that the "B" Pathway gets its 'de' audio rendition from cdn-A, so even if the client is switched to "B" any client that has selected German audio will continue to work.


Roger.

> 
>> If yes to 1, 
>> is the client in HLS content steering permitted to ignore the response from the steering server and favours its content selection?
>> Is the client required to always follow the content steering response, regardless of its content selection?
> 
> The spec does not give the client an option to ignore a response from the content steering server (except in the edge case where the server specifies no pathways that the client knows about, in which case it is allowed to remain on its current pathway). So I guess the answer here is (b).
> 
>> If both are suported, 2a and 2b, can the content provider signal to the client, which operation it shall follow.
> 
> n/a
> 
>> In case the option 2b is supported, would it mean that for example a change of a pathway in the content steering server response may force a switch of content for the client? Are there any restrictions?
>>  
> 
> A forced switch to a Pathway that included no playable content for the current client selections (including audio and subtitle languages, audio channel layout, and video range) would more like result in a fatal playback error rather than a change in selection. Currently the response is not specified, but if we were to specify it I would lean in that direction (i.e. that the required client response is to fail playback).
> 
> 
> Roger.
> 
>> Thanks for you suport on this matter.
>>  
>> Thomas (on behalf of the DASH-IF IOP WG).
>>  
>>  
>> —
>> Dr. Thomas Stockhammer || [e-mail] <mailto:[e-mail]>  || phone: [phone] || <image001.png> <https://wa.me/491725702667> <image002.png> <http://www.linkedin.com/in/stockhammer> <image003.png> <https://www.facebook.com/tstockhammer>  <image004.png> <https://github.com/haudiobe> <image005.png> <https://discord.com/channels/thomassto#6183><image006.png> <https://www.instagram.com/haudiobe/>
>>  
>> -- 
>> Hls-interest mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/hls-interest
> 
> -- 
> Hls-interest mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/hls-interest