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

[Roger Pantos <[e-mail]>]

> On Oct 11, 2023, at 10:08 AM, Thomas Stockhammer <[e-mail]> wrote:
> 
> Roger,
>  
> I agree on your assessment. The broadcast-only case is very unlikely, typically you always have unicast fallback.
>  
> Having said all of this, I believe from what you explain below, it would be preferable/recommended that content on different CDNs
> Needs to be semantically identical 
> Can be different in quality 
> Semantically identical content across different CDNs needs to “switchable”.

Yes, I think so.

> Examples for suitable content:
> SD on CDN1, HD/SD on CDN2, HD -> SD switching possible, all with the same codec.
> Stereo audio on CDN1, stereo/5.1 on CDN2, stereo -> 5.1 switching possible, all with the same codec and same language.

I don’t know how compatible this one would be. Some clients may support switching, others may not. 

(Having said that, it’s a reasonable robustness feature to recover by switching if for example all 5.1 renditions 404 on you, even without Content Steering. You could ask clients to support it.)

> Examples for non-suitable content offering:
> SD/AVC on CDN1, HD/SD/HEVC on CDN2, switching not possible across codecs.

Most players actually can switch between HEVC and AVC (although not all do it seamlessly). But not many will switch between color spaces (SDR to PQ for example). So having SDR on CDN1 and SDR + HDR10 on CDN2 is a better example of non-suitable content.
> Stereo audio on CDN1 in English, stereo/German on CDN2

Correct, as previously indicated.

> There are questions around details on switchability, but this can be solved within the respective specs HLS/DASH.
>  
> If the above recommendation is not applied, then this may result in a playback failure in the client.

Yup.


Roger.

>  
> Thomas
>  
> From: Roger Pantos <[e-mail]> 
> Sent: Wednesday, October 11, 2023 5:06 PM
> To: Thomas Stockhammer <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Hls-interest] Content Steering, Multiple Service Locations and Client Behaviour
>  
>  
> 
> 
>> On Oct 11, 2023, at 12:46 AM, Thomas Stockhammer <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> Roger,
>>  
>> Thanks for the answers. This makes it clarifies the intention of content steering in HLS.
>>  
>> We will take this into consideration when finalizing the DASH Content Steering specification.
>>  
>> As you were asking about use cases for a client choice, let me explain the scenarios that have been discussed and are part of implementations in the 5G-MAG reference tools: https://www.5g-mag.com/reference-tools and also documented in 3GPP MBMS/5G Broadcast specifications below
>>  
>> This is a bit detailed, so I leave it to interested people to check and see 
>> if this use case applies for their operation 
>> if the use case can be generalized to other operations
>> if Content Steering would be the right choice for these operations
>> Thomas
>>  
>> Use Case
>> =======
>> Content is offered as regular DASH/HLS content on a CDN. The content may have different video experiences (HD/SD) and different language tracks (EN/DE). 
>> At the same time, one Representation/Rendition/CMAF Track for video (HD) and one for audio (EN) is sent over a broadcast system (MBMS, 5G Broadcast) to mobile devices/gateways. 
>> The broadcast system terminates in a local cache on the mobile or on a gateway cache. A regular DASH/HLS client is used.
>>  
>> The manifest offers the content on two pathways/service locations:
>> All content is offered on the CDN
>> The broadcast content is offered on a local cache
>> Different scenarios now exist: the UE may dynamically in coverage of the broadcast system and the unicast system, or it may out of coverage of one of those. This may change over time.
>> A policy of the service provider may be as follows:
>> Whenever you are in broadcast coverage and unicast coverage 
>> you must choose the video from broadcast unless your device does not support HD playback
>> you can choose the language from your preferred location based on your content preferences
>> Whenever you are only in broadcast coverage
>> You must choose the video and audio from broadcast
>> Whenever you are only in unicast coverage
>> You can choose as you like, but based on access quality, the video may only be SD.
>  
> The only way that this only-broadcast case can would work for the language choice with a standard player is if the application layer can detect the transition to a broadcast-only state and explicitly switches the language choice to the broadcast language. Otherwise playback failures will occur. (And even then, that would be a terrible UE that most users would consider to be broken.)
>  
> I would recommend that anybody deploying such a system including all language options as part of the broadcast. In most cases these would be live events and there won't be too many options.
>  
> Or, alternately, that your spec be revised to indicate that even in a "broadcast-only" environment, clients are allowed to load lower-bitrate renditions (such as audio) over unicast regardless.
> 
>>  
>> In MBMS (see 3GPP TS 26.347), currently two options are defined: 
>> The DASH/HLS client frequently connects to the local cache for manifest updates, and the logic in the cache rewrites the manifest to implement the policy.
>> The DASH/HLS client frequently connects to the local cache for manifest updates, the manifest is not updated, all content is offered, but SAND (ISO/IEC 23009-5) is used to provide recommendations or enforcements on which CDNs (local/network) are accessible.
>> Both 1 and 2 are workable, but have some issues. (1) rewriting manifests is possibly cumbersome, consistency issues, encryption may be used and so on. (2) SAND is not widely implemented in clients, but it basically has identical features as Content Steering, CMCD, and CMSD. It is also not defined for HLS.
>  
> Yes, you would need to do (1) for HLS.
> 
> 
>>  
>> It would be great if Content Steering could be used to address the above issues. In this case, a content steering server may be installed on the local cache/gateway to steer the HLS/DASH client accordingly, i.e. either to the CDN or the local cache, or both. To implement the different policy indicated above, a more flexible way of signaling would be needed.
>  
> I'm not convicted that allowing Content Steering to force-switch a user selection is a good or desirable outcome. I think there are better ways to skin that cat.
>  
>  
> Roger.
> 
> 
>>  
>> Comments and feedback on the broader applicability of the use case is welcome.
>>  
>>  
>> From: Roger Pantos <[e-mail] <mailto:[e-mail]>> 
>> Sent: Tuesday, October 10, 2023 12:03 AM
>> To: Thomas Stockhammer <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>
>> Subject: Re: [Hls-interest] Content Steering, Multiple Service Locations and Client Behaviour
>>  
>> More more thing, inline:
>> 
>> 
>> 
>>> On Oct 9, 2023, at 2:43 PM, Roger Pantos <rpantos=[e-mail] <mailto:rpantos=[e-mail]>> wrote:
>>>  
>>> Hello Thomas. My responses inline:
>>> 
>>> 
>>> 
>>>> On Oct 8, 2023, at 7:26 AM, Thomas Stockhammer <[e-mail] <mailto:[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 <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 <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 <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 <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 <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 <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 <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
>> 
>>  
>> -- 
>> Hls-interest mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/hls-interest