Improve consistency of bitrates in concatenated video streams for multiperiod DASH

[caridley]

Is your feature request related to a problem? Please describe.
This may fix unexpected buffering in multi-period DASH streams

Describe the solution you'd like
We see cases where some periods in a concatenated video streams have significantly higher bandwidth than that of the concatenated steam, which (in theory) can cause the ABR engine to select streams that consume more bandwidth than expected, causing unexpected buffering. We think the bandwidth of a concatenated stream should be set to the highest bandwidth found in any period in the stream, instead of the stream that was used to seed the concatenated stream.

Currently the Shaka 3.x period combiner compares resolution, framerate and bandwidth in that order when looking for the best matching video stream in a period. This can cause streams with radically different bandwidth to be combined into the same concatenated stream. We think only bandwidth should be used to compare video streams. Three general characteristics determine the quality of a video stream; resolution, framerate and quality of the compression. How these are optimized relative to one another may vary from period to period in a stream. We think bandwidth alone, which reflects the combined effects of resolution, framerate, and quality of compression decisions, is the best indicator of relative video quality and should be the sole value used to compare streams in isVideoStreamBetterMatch_(). Using bandwidth alone will also align better with the ABR goal of delivering the best video quality for the available bandwidth.

To summarize

• We propose that bandwidth of a concatenated stream be the highest bandwidth of any period in that stream.
• We propose that bandwidth alone be used to compare streams in isVideoStreamBetterMatch_()

Describe alternatives you've considered

Additional context

[caridley]

In some cases these characteristics of period flattening are causing higher bitrate variants to be composed of lower bitrate representations than some other lower bitrate variant. This prevents us from playing the best quality video when bandwidth is abundant.

This occurs with this manifest Manifest.txt

This file contains info from the flattened manifest InfoFromFlattenedManifest.txt
See comment between data for variants 5 and 6

[caridley]

Since some users may be relying on current behavior we should have a config field manifest.dash.prioritizeBitrate to determine if bandwidth is prioritized in isVideoStreamBetterMatch_()