Consider making the bandwidth attribute in a manifest optional

[ericmatthys]

There are cases where there may not always be a useful value for the bandwidth attribute when converting user videos on-the-fly with DASH without multiple qualities. Shaka is asserting that bandwidth be defined, and non-zero.

https://github.com/google/shaka-player/blob/310e48f8cc2fe5ef4efac808716a93bfb9a2091d/lib/dash/dash_parser.js#L1061

When parsing the manifest, it is forcing bandwidth to either be a number greater than zero, or it will be undefined.

However, streams without a bandwidth attribute or bandwidth="0" in the manifest were otherwise working until a more recent change. a452c24 is the change that actually broke playback when bandwidth is missing or zero. It is expecting bandwidth to be a number, and if it is not, it results in an averageBandwidth of NaN and it will not choose codecs.

<?xml version="1.0" encoding="utf-8"?>
<MPD
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="urn:mpeg:dash:schema:mpd:2011"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd"
  profiles="urn:mpeg:dash:profile:isoff-live:2011"
  type="static"
  mediaPresentationDuration="PT1H51M57.6758S"
  maxSegmentDuration="PT10S"
  minBufferTime="PT10S">
  <Period start="PT0S" duration="PT1H51M57.6758S">
    <AdaptationSet segmentAlignment="true">
      <SegmentTemplate timescale="1" duration="5" initialization="dash/osl17x74saioaf9c4rkzfyw6/$RepresentationID$/initial.mp4" media="dash/osl17x74saioaf9c4rkzfyw6/$RepresentationID$/$Number$.m4s" startNumber="0">
      </SegmentTemplate>
      <Representation id="0" mimeType="video/mp4" codecs="avc1.42c00d" bandwidth="1000" width="1912" height="792">
      </Representation>
    </AdaptationSet>
    <AdaptationSet segmentAlignment="true">
      <SegmentTemplate timescale="1" duration="5" initialization="dash/osl17x74saioaf9c4rkzfyw6/$RepresentationID$/initial.mp4" media="dash/osl17x74saioaf9c4rkzfyw6/$RepresentationID$/$Number$.m4s" startNumber="0">
      </SegmentTemplate>
      <Representation id="1" mimeType="audio/mp4" codecs="mp4a.40.2" bandwidth="0" audioSamplingRate="48000">
        <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

I believe making bandwidth optional aligns with the ExoPlayer's expectations of the bandwidth attribute in the manifest, which appears to allow it to be optional.

https://github.com/google/ExoPlayer/blob/d979469659861f7fe1d39d153b90bdff1ab479cc/library/dash/src/main/java/com/google/android/exoplayer2/source/dash/manifest/DashManifestParser.java#L435

Otherwise, the manifest could have a fake bandwidth value of any number greater than zero and that should at least work around the issue.

[joeyparrish]

The use of the bandwidth attribute in Representation is mandatory in the DASH spec. So if the attribute is missing, the content is broken.

Further, the definition of the attribute in the spec is as follows (section 5.3.5.2, Table 7, "Semantics of Representation element"):

Consider a hypothetical constant bitrate channel of bandwidth with the value of this attribute in bits per second (bps). Then, if the Representation is continuously delivered at this bitrate, starting at any SAP that is indicated either by @startWithSAP or by any Segment Index box, a client can be assured of having enough data for continuous playout providing playout begins after @minBufferTime * @bandwidth bits have been received (i.e. at time @minBufferTime after the first bit is received).

If bandwidth is 0, this formula would state that playback can begin after 0 bits are received. This is clearly false, and therefore a bandwidth of 0 is clearly nonsensical.

That said, we can probably still play back in most cases. If the combination of audio and video bandwidth is always non-zero and accurate, adaptation should still work, even if one of the two numbers was zero. And if there is only one combination of audio + video, there are no adaptation choices to be made anyway.

So, in circumstances that either the sum of audio+video bandwidth is still accurate or that there is only one audio+video combination, we can make this work for you.

[joeyparrish]

The work-around has been cherry-picked for v2.1.6.