Refine how 'br' encoded bitrate information is expected to be extracted from HLS playlists

[wilaw]

[Jordan] As the spec currently reads, an HLS player would not be able to supply a conforming encoded bitrate value for demuxed file-segmented playlists without EXT-X-BITRATE attributes.

In the case of demuxed HLS playlists, EXT-X-INF:BANDWIDTH applies to the aggregate bandwidth of video, audio, and subtitle renditions. EXT-X-BITRATE, an optional per-segment attribute within media playlists, is often not available.

[Will] – if the player only knows the aggregate bandwidth value , then I think there are 3 reasonable courses of action that we can discuss

1. It reports that aggregate bitrate value any time it requests a video, audio or subtitle object.
2. It reports that value for the video segments (since video is likely the largest contributor of bandwidth) and omits the ‘br’ parameter for audio and subtitles
3. It does not report any ‘br’ values as it cannot accurately allocate them. Additionally, we could indicate that any distributor intending to use CMCD@br info for monitoring demxued content SHOULD add the EXT-X-BITRATE values to its media playlists.

We could also consider requesting an update to HLS spec, to allow non-aggregated BANDWIDTH values to be communicated in multi-variant playlists. There is utility to this data beyond CMCD and it is available in other streaming formats.

[PCaponetti]

From 20240118 meeting:

• Option 1 or 2 is attractive. 2 is odd for audio-only fields
• Potentially use a new key for aggregated bitrate
• Add a new key for aggregated bitrate would make it clear, and seems to be the right way to go in the case where do not have the bitrate of each of the parts.

Have TODO's but adding two more fields for aggregated bitrate types. Will comment when completed.

[PCaponetti]

Glenn: why not just change the definition of bitrate to be this new one? Chris L: There is value in keeping these separate and to allow the more explicit bitrates if they are known. Rajeev: This value can come from the playlist or player estimate, should we declare which is preferred? Will: We can allow the player to send either. Not wanting to be prescriptive and this is a deep rabbit hole. Rajeev: Usually this information is better calculated in transcoding and sent in the manifest. Chris L: When we are talking about player implementation we want to make sure that any guidance we have is simple, clear, and completely in this document. David H: Why don't we put guidance in the document on how to get this value from Dash and HLS?

Don't hear enough consensus on this yet. Will leave the following modifications to bake for another 2 weeks:

Added "Aggregate encoded bitrate" (ab) with the language "The aggregate encoded bitrate of the complete media object including all object types. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value should be transmitted. This value MUST NOT be sent for objects which do not have an object type of ‘a’, ‘v’, ‘av’ or ‘o’. This value MUST NOT be sent if the encoded bitrate is known. "

Added "Top aggregated encoded bitrate" (tab) with the language "The highest aggregated bitrate rendition in the manifest or playlist that the client is allowed to play, given current codec, licensing and sizing constraints. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. The aggregate encoded bitrate is of the complete media object including all object types. This value MUST NOT be sent for objects which do not have an object type of ‘a’, ‘v’, ‘av’ or ‘c’. This value MUST NOT be sent if the top encoded bitrate is known."

Also updated br to say "The encoded bitrate of the audio or video object being requested. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value should be transmitted. This value MUST NOT be sent for objects which do not have an object type of ‘a’, ‘v’, av’ or ‘o’. This value MUST NOT be sent if only the aggregate encoded bitrate is known."

And tb to "The highest bitrate rendition in the manifest or playlist that the client is allowed to play, given current codec, licensing and sizing constraints.This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. This top bitrate MUST apply to the object type being requested. Requests for video objects MUST specify the top video bitrate and requests for audio objects MUST specify the top audio bitrate. This value MUST NOT be sent for objects which do not have an object type of ‘a’, ‘v’, ‘av’ or ‘c’."

[wilaw]

meeting 2/15

• Paul - why isn't peak value normaitve?
• Will, it was looser before to make player implementation easier. But I would support a MUST.
• Paul, added MUST to text.
• Will- is this sent on all objects?
• David - what value is there in sending multiple times?
• Will, what if we recommend that it is sent only once per CDN? Is that complex for players to do?
• Paul - redundant values might help in a SSABR solution?
• Sebastien - we should send every time, for stateless parsing.
• Nicolas - we should not suggest anything now, since everything is optional.
• David -, at Segments people said they weren't using CMCD because of amount of data. Paul - will open issue around that.
• No recommendation for now.
• Added MUST use peak value for br and tbr fields