[HLS] Micro-freeze issue when refreshing live playlist
I am getting "micro-freezes" (meaning video stops for a fraction of a seconds and the resumes) at regular intervals, and those intervals coincide with the length of the playlist (given that the usual .m3u8 file contains 3 .ts segments totaling between 10 and 15 seconds of video). It happens with most of the HLS streams I've tested with (a list is available below).
I tried adding buffering between hlsdemux and tsdemux and managed to increase performance, but the micro-freeze issue is still present. I also tried several property values (connection-speed for hlsdemux, sizes and thresholds of the queues etc) with no improvement.
I wrote to the mailing list and got this response from Charles Turner, which I think is worth quoting here:
This is definitely a QoS bug, which isn't that unusual for elements in gst-plugins-bad. I had a quick peek at what might be going wrong and one hunch is that adaptivedemux isn't giving itself enough time, or is somehow stalling in updates_loop during the playlist updating logic. Maybe the target_duration wait times and/or the update timer cond bits need some adjustments.
Some of the workflows I've tried are the following:
gst-launch-1.0 playbin uri=$URL
gst-launch-1.0 souphttpsrc location="$URL" ! hlsdemux ! queue ! tsdemux name=demux \ demux. ! queue ! aacparse ! avdec_aac ! audioconvert ! autoaudiosink \ demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink
URL being one of the following:
- http://dwstream4-lh.akamaihd.net/i/dwstream4_live@131329/master.m3u8 (DW)
- https://5c21f7ec1999d.streamlock.net/8054/8054/playlist.m3u8 (TC, Ecuador)
- http://video.oct.dc.gov/out/u/DCN.m3u8 (DCN, provides various streams, use connection-speed to stick to one)
- http://unlimited2-us.dps.live/nettv/nettv.smil/playlist.m3u8 (NETTV, Argentina)
Streams that are not live, for example, the ones at bitmovin.com work ok (in the worst case you just have to set the appropriate bit rate).