Base initial bandwidth estimate on first level's bitrate

[robwalch]

There seems to be a conflict between the player starting on the first level in the manifest, and the one that matched the default bandwidth estimate of 50000bps. I propose we override the default estimate to be at least the bitrate of the first level in the manifest. This would ideally create more consistent start behavior when an initial estimate is not set in the config, and hopefully reduce initial down switches or low quality starts as a result of a slow ramp up from the default 50000bps.

Some points to iron out:

• Should this starting estimate be increased even when performing a bandwidth test using the first chunk of the level with the lowest bitrate?
• Should the cap-level-controller be allowed to influence the firstLevel chosen (if the player dimensions are smaller than the first level in the manifest, a lower level would be chosen)?
• Should there be an upper limit to prevent issues on clients with limited resources who load streams where the first rendition has really high bitrates?

[danshando]

Really glad this is getting looked at! It's been a pain point for us at times.

I propose we override the default estimate to be at least the bitrate of the first level in the manifest.

This makes perfect sense to me and would resolve some pain points we've had in the past with respect to performance of specific manifest authoring specs used. ("We put this bitrate at the beginning, why does it always down switch for me?").

Should this the starting estimate be increased even before performing a bandwidth test using the first chunk of the level with the lowest bitrate?

I would say yes probably. I think this adjustment would be in the spirit of what you're trying to change.

Should the cap-level-controller be allowed to influence the firstLevel chosen (if the player dimensions are smaller than the first level in the manifest, a lower level would be chosen)?

Yes. I'm in big favor of this one.

Should there be an upper limit to prevent issues on clients with limited resources who load streams where the first rendition has really high bitrates?

I could go either way on this one. From a purely user-focused perspective I always tend to favor those with slower connections, but we have had situations where having a certain bitrate load first has been a very high priority. Maybe this limit could be on by default but has a setting to turn off if desired.

I guess one of the big questions with this is how much power to give to the ordering of the variant list in the manifest...right?

[robwalch]

Bringing this back for 1.5.0. The current default behavior in the level-controller is to use firstLevel (first supported variant in the multivariant playlist). That however can force startup on a less then ideal video or audio configuration (codec, dynamic-range, or audio channels). This change will allow for consistent behavior with past releases when there are no alternative variants with enhanced features while supporting the playback goals for 1.5.