Closed wilaw closed 8 months ago
From 20240118 meeting:
Have TODO's but adding two more fields for aggregated bitrate types. Will comment when completed.
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’."
meeting 2/15
[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
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.