HLS source with multiple variants is not optimally handled
|Reported by:||sinkers||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Currently when ffmpeg parses an HLS source it it performs a scan of all the available variants resulting in a very slow startup time. It also does not adapt to changes in network conditions to switch between the variants.
Both of these cases are some of purposes of the HLS protocol.
For startup the common convention with in formatting HLS master playlists is to make the first variant in the list the one that should be played first. So the reader should attempt to start playing this variant first without parsing all the variant playlists.
The reader should then maintain a buffer to detect how fast it is reading segments in the variant playlist and if the buffer is not filling fast enough to maintain playback for the current bitrate it should switch to a lower bitrate, if the low buffer continues then the reader should switch to a lower rate until it is as the lowest bitrate. If the buffer is full for a specified period then the reader should attempt to read the next higher bitrate and so on until the top rate is reached.
Note that the reader should also look at the bitrates recorded in the BANDWIDTH= field of the playlist as opposed to processing the segments as it should be assumed that the media honours the specification so as to reduce processing overhead and make for a faster experience.
A reasonable sample of a master playlist with multiple bitrate variants is available here: https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
If someone starts on this I am happy to provide more detail.
Change History (13)
comment:1 Changed 4 years ago by cehoyos
- Component changed from FFmpeg to avformat
- Priority changed from normal to wish
- Version changed from unspecified to git-master