Skip to content

[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

With URL being one of the following:

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).