Re: [Hls-interest] Survey: signaling HLS client capability

["Law, Will" <[e-mail]>]

Hi Roger



Architecturally, I see concerns in having servers making decisions for clients. The reasons for this are two-fold:

1. There is a clear and strong movement towards client privacy. This includes the deprecation and freezing of User-Agent and other client identifiers, which is well under way. If not already, it will become increasingly harder for servers to make any sort of reliable inference about a client's capabilities based purely upon the request.

2. Servers should respond unambiguously to client requests. A brittle system is one in which 3 clients ask for the same asset (a main playlist for example), but each is returned a different version of that asset based upon which codecs that server thinks the client supports. We now have three bit-different assets with the same file name, which causes cache consistency problems. QA becomes difficult, because you get a different answer depending upon who is asking. A deterministic system, in which each request has a single possible response, is far easier to debug and eventually far more robust when it comes to scaling up complex systems.



Two schools of thought then as to how clients can handle diversity of content & features:

  1.  Clients should ask explicitly for what they want in a way that is consistent and the response cacheable . You have already established a convention of reserved _HLS_ query args  on which the newer features of HLS are quite dependent. It would make sense to extend this to allow players to add additional filters as they request content. Examples of filters:
     *   _HLS_codec=hevc, avc
     *   _HLS_bitrate=500000-4000000
     *   _HLS_lang=fr
     *   _HLS_admode=interstitial
  2.  Another approach is that the main playlist is a menu of all content available, and that the client is capable of extracting the pieces from it that it wants. Real-time feature-based detection, rather than brittle device categorization, is the sustainable way forward. We already require smart clients to play back HLS. Those same clients are aware of which features (low latency, steering, interstitial support) they support as well as are capable of discovering the capabilities (codec, HDCP, HDR etc) of the host device. This approach gives the same main playlist to all clients, simplifying distribution.



One problem with approach [1] is that you would want to use it when the client requests the main playlist, however it doesn’t know if the origin supports such filtering. It could therefore request AVC as the only codec, but receive a static playlist back from an origin that did not support filtering. There could be a playlist attribute added to indicate that the origin acknowledges the requests and has implemented the filters. If the client does not see such an acknowledgement echoed back, then it would know that it can’t trust the origin and would have to implement some decisions of its own. One could then argue that if it can make those decisions on its own, then why entertain the complexity of the filters? If a client is modern enough to add these filters to its requests, then couldn’t it simply apply them itself?



The problem with approach [2] is legacy clients. If every feature implemented is backwards compatible, then perhaps you are OK and the client gets a degraded but still functional experience. Eventually Apple will want to introduce a breaking change for efficiency (next-gen interstitial ads for example) and at that point playlists would need to be hard-coded to specific client sets, which is exactly the situation we are in today if you examine most large content distribution solutions.



Neither approach is without issues. Overall, I think an implementation of [1] is a practical means of introducing new features to modern clients, as only modern clients will know how to ask for them. In parallel, I’d also like to see Apple moving the industry in the direction of making the players smarter. Player behavior specifications, updateable player logic (decoupled from device updates) , player conformance tests, and test suites would make for more manageable content & feature diversity in the decades ahead.



Cheers

Will





On 5/20/21, 9:00 AM, "Roger Pantos" <rpantos=[e-mail]> wrote:



    With the increasing number of optional features in HLS (such as low latency, content steering, interstitial support, different codecs, etc.), there is a desire in some quarters to present different streams to different devices, beyond the regular variant stream selection performed on the client.



    We're considering some kind of signal of client capability, such as a query parameter on the Master Playlist URL, to support this kind of server decision. But before we go too far I'd like to understand if it would actually be of practical benefit, and what universe of use cases it makes sense to support. So:



    - Do you think you would use this kind of thing? For what?



    - If you are already doing something along these lines, perhaps driven by the User-Agent string or something else, what requirement is driving that?



    (Alternately, if you think that this would only make things worse, let us know why!)



    Feel free to respond here, or to send your response privately to [e-mail].





    thanks,



    Roger Pantos

    Apple Inc.

    --

    Hls-interest mailing list

    [e-mail]

    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!H1Hsba7y664WmwG3l-OQEw9A4O9jRoyGL0i2Y2-YPW42-Pz-zXuCdZq_qwwY$