Micro-freeze playing (live) HLS streams

[Juan Ramírez]

Hi,

I'm having an issue playing live HLS streams that, at this point, I am
unable to solve alone.

I have defined several workflows for playing HLS streams that go like this
(starting with the simplest):

* gst-launch-1.0 playbin uri=$URL
* gst-launch-1.0 souphttpsrc location=$URL ! decodebin name=dec \
  dec. ! queue ! videoconvert ! autovideosink \
  dec. ! queue ! audioconvert ! autoaudiosink
* gst-launch-1.0 souphttpsrc location="$URL" ! hlsdemux ! tsdemux
name=demux \
  demux. ! queue ! aacparse ! avdec_aac ! audioconvert ! autoaudiosink \
  demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink

Of course I tried several other configurations (adding queues here and
there in order to try different buffering strategies) but showing them all
might be too distracting.

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 doesn't
happen with all the HLS streams I've tested, but it happens with a lot o
them.

I think (or at least thought) this is a buffering related issue, so I tried
to insert queues before and after the HLS demuxer but, at the moment, I
haven't been successful.

I did gain, tough, a great performance improvement by adding a queue after
HLS demux in some cases, but it wasn't enough to solve the micro-freeze
issue. I also tried to switch between the different types of queues
available (queue, queue2 and multiqueue) and customizing the properties at
my disposal (for example: max-size-{buffers,bytes,time},
{low,high}-watermark, playbin flags) but I only managed to increase the
startup time (which, base on the documentation, made sense).

I tested in three different environments with the same result which led me
to conclude this is not related to a particular setup.

Environment 1:
  * Hardware: HP Laptop with Core i7 CPU
  * OS: Manjaro Linux
  * Gstreamer version: 1.16.0 (installed with pacman)

Environment 2:
  * Hardware: Raspberry Pi 3 B+
  * OS: Raspbian Stretch
  * Gstreamer version: 1.16.0 (compiled without X support)

Environment 3:
  * Hardware: Raspberry Pi 3 B+
  * OS: Raspbian Buster
  * Gstreamer version: 1.14.0 (installed with apt-get)

The following is a list of just some of the streams I've been testing that
have the micro-freezing issue, in case you want to give them a try.

* http://video3.earthcam.com/fecnetwork/hdtimes10.flv/.m3u8
* http://video3.earthcam.com/fecnetwork/9974.flv/.m3u8
* (DW) http://dwstream4-lh.akamaihd.net/i/dwstream4_live@131329/master.m3u8
* (TC, Ecuador) https://5c21f7ec1999d.streamlock.net/8054/8054/playlist.m3u8
* (DCN) http://video.oct.dc.gov/out/u/DCN.m3u8 (provides various options,
use connection-speed to stick to one)
* (NETTV, Argentina)
http://unlimited2-us.dps.live/nettv/nettv.smil/playlist.m3u8

Interestingly enough, this channel from Argentina works ok:
http://200.115.193.177/live/26hd-720/.m3u8. Believe it or not, this was the
only one that played smoothly (I couldn't find any difference of magnitude
with the others).

Streams that are not live, for example, the ones at bitmovin.com
<https://bitmovin.com/mpeg-dash-hls-examples-sample-streams> work ok (in
the worst case you just have to set the appropriate bit rate).

It is worth noting that those HLS streams work ok if using livestreamer
<http://docs.livestreamer.io/> (with 1~2 seconds delay due to buffering).

Any help will be appreciated, and I'll be happy to provide additional
information in case is needed.

Thanks!

--
Juan
:wq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190723/8622bcf9/attachment.html>