bandwidth in DASH and HLS

[RufaelDev]

Looking at the spec CTA 5005 I see good recommendations on encoding bit-rate (peak and average) of the CMAF content but no information about the HLS bandwidth and related DASH bandwidth attribute and how to convert between the two. I re-read both definitions in DASH and HLS and tried to make up a recommendation for converting and interoperability. It is a bit tricky as the definitions are different and my recommendation is not yet complete.

In DASH two attributes are defined minBufferTime and bandwidth, minBufferTime is recommended to be set to the gopsize/segment duration. It is assumed that in an ideal network condition with capacity bandwidth after minbuffertime (e.g. waiting one segment duration), the media can be played continuously. Thinking about the limit of time to infinity the effect of the initial minbuffertime will cancel out, hence the actual bandwidth of the media segments must always be lower than the bandwidth attribute otherwise the definition from DASH may be violated. Thus, the actual encoded bit-rates in DASH must be lower then what is indicated by bandwidth atttribute in DASH in practice.

For HLS the bandwidth attribute is the peak segment bit-rate. Secondly, the average-bandwidth is optional and needs to be based on the actual average segment bit-rates, if the content encoding recommendation is used from 4.1.2 reducing the bandwidth attribute from DASH or the bandwidth attribute from HLS with 10 percent could be a rough estimate if there is no way to compute directly.

So roughly summarized

• DASH and HLS bandwidth attributes correspond to each other, but their slightly different definition stops them from being used interchangeably
• HLS bandwidth will cover the DASH definition for bandwidth attribute.
• I dont think the DASH bandwidth attribute can be used for the HLS bandwidth attribute, as the peak-bitrate definition from HLS does not take minbuffertime into account. In DASH a low bitrate segment would cancel out a higher bit-rate segment but this would not be the case in HLS, thus the DASH definition would not hold in HLS. Perhaps using DASH bandwidth times (1 + minbuffertime/avsegment duration) could be an approximation (upper bound) for the HLS bandwidth attribute as I could send minbuffertime/segment_duration nothing and then a burst after that of a single segment duration at the peak). But this seems not to be practical and also not very realistic in practice. A bit more thought and work on this one may be needed.
• HLS average-bandwidth must be calculated based on actual segments, if this is not possible and encoding constraint of 110 percent is kept, reducing HLS or DASH bandwidth by 10 percent can be a reasonable estimate.

This is just an initial attempt, having something for this in an updated version of the specification is useful especially for the conversion use case. The conversion from DASH to HLS of is not trivial for the bandwidth attribute due to the difference in definition. The other way around can work i think.

[RufaelDev]

looking at this again, a simple recommendation to add to all DASH constraints for interoperability in the different use cases could be:

@bandwidth attribute of a representation shall be set to the peak segment bit-rate of a segment in the representation or when segments are not available to the peak bit-rate of a segment in a representation encoded with similar settings

this way the DASH content can be converted to HLS and vice versa as the @bandwidth attribute in DASH would be interchangeable with the HLS bandwidth attribute.

[technogeek00]

• Encoding vs signaling constraints, have we captured in the spec completely
• spec bandwidth attributes are not equivalent, highlight differences and how constraints enable conversion in CBR case
• would be good to get opinions / functional behavior from encoding vendors / content distributors to expand beyond the basic use case of interoperability and discuss functionality such as VBR or content aware encoding.

[alexzambelli]

I fully agree with Rufael that the current DASH and HLS definitions of @bandwidth and BANDWIDTH, respectively, are not fully aligned for the reasons Rufael outlined above.

However, there is an additional spec misalignment that needs to be considered, and that is the fact that in DASH @bandwidth describes the bandwidth needed to seamlessly play a single media representation, whereas in in HLS BANDWIDTH describes the bandwidth needed to seamlessly play a variant - which is equal to the total bandwidth of video+audio+subtitle renditions defined by the variant. Further complicating this issue is that HLS does not provide any metadata in its master playlist that would allow one to accurately break down the cumulative BANDWIDTH into its media components by simply parsing the master playlist.

Last but not least, there is also the problem of DASH not having an attribute analogous to AVERAGE-BANDWIDTH of HLS. While this isn't necessarily problematic in the context of player operability (since players can rely on @bandwidth/BANDWIDTH to make ABR switching decisions), it can be problematic in context of reporting & analytics because a lot of QoE analytics solutions rely on AVERAGE-BANDWIDTH to represent played stream bitrate. In lieu of that attribute the instrumentation SDKs often rely on @bandwidth/BANDWIDTH, which means that if @bandwidth/BANDWIDTH values in manifests actually follow the spec definitions (i.e. peak segment bitrate) then any QoE analytics solution which assumes them to be representative of average stream bitrate will be completely off-target.

All that said... I don't know if there's a good way to solve all these problems without introducing new attributes to both DASH and HLS specs. Adding @averageBandwidth to DASH would be a good step towards interoperability, but likewise HLS could benefit from having bandwidth-related attributes defined per media playlist (rendition) instead of just cumulatively per playback variant. Furthermore, both specs could probably benefit from decoupling the concept of "playback bandwidth" from the concept of "encoded stream bitrate", because even though in some cases their values may be equivalent there are plenty of other cases where the answers to "how much bandwidth do I need to seamlessly play this over a network?" and "how much storage will this require?" could be very different - and conflating them can lead to unintended consequences.

[ZmGorynych]

1. There is average bandwidth signaling in DASH. It is done (a bit awkwardly) in the ExtendedBandwidth element.
2. SCTE 214-1 recently introduced peak segment bitrate attribute which mirrors the HLS definition.