I don't know how it works internally, but this is what seems to happen.

1. Get index M3U8.
2. Download and play first segment from lowest BANDWIDTH M3U8.
3. Measure actual bandwidth during step 2.
4. Pick potentially different BANDWIDTH M3U8 and next segment based on 2.
5. Loop 3-4.

The problem is that the first few seconds (usually 10) of a video are always at lowest quality. This is particularly bad (but not only) for short videos.

I can understand this logic for EVENT M3U8s, although it may possibly still be improved, but this shouldn't happen for VOD M3U8s.

Minor correction.

4. Pick potentially different BANDWIDTH M3U8 and next segment based on 3.

What OS are you working with? Android? If so this is an Android OS level bug.

Yes, Android. (Does ChromeOS support HLS?)

As per comment# 4 changing the OS to Android for further inputs.
Thank You.

No, only Android supports HLS. Though on other platforms you can use HLS -> MSE JavaScript code to play the content.

dale, do you mean this is by design?
pdknsk@gmail.com, can you provide a repro url?

I mean this is an Android issue and not something we can fix in Chrome.

Could this be considered a bug in itself, that Chrome depends on
Android for this, or can't it be helped? The problem is of course that
it's much easier to update Chrome than Android, and the latter doesn't
happen often anyway due to the usually poor update-policy on non-Nexus
devices.

We don't recommend HLS usage in Chrome, there are a variety of HLS -> MSE translators that can resolve this in JavaScript instead of having to rely on the Android framework. We have no plans to support HLS more than to the extent supported by the Android platform.

Ah, I didn't know that. And neither do most websites it appears, as I get served HLS regularly. (Opportunity for evangelism, I think.)

By most I mean many.