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 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 (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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Charlie Turner-2]

Hi Juan,

On Tue, 2019-07-23 at 15:22 -0300, Juan Ramírez wrote:
> 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.

This is definitely a QoS bug, which isn't that unusual for elements in gst-plugins-bad. Please file this as a GitLab issue[1]. 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.

It will require some digging in the bug report regardless.

Thanks for the report,
  Charlie.

[1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Juan Ramírez]

Hi Charles,

Thanks for your response.

I filled a bug report to Gitlab [1]. I will continue to work on this
issue and update the bug report should any new information arise. Of
course I'm available in case anything else is needed.

Thanks again.

[1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1030


On Wed, Jul 24, 2019 at 5:36 AM Charles Turner <[hidden email]> wrote:

>
> Hi Juan,
>
> On Tue, 2019-07-23 at 15:22 -0300, Juan Ramírez wrote:
> > 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.
>
> This is definitely a QoS bug, which isn't that unusual for elements in gst-plugins-bad. Please file this as a GitLab issue[1]. 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.
>
> It will require some digging in the bug report regardless.
>
> Thanks for the report,
>   Charlie.
>
> [1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
Juan
:wq
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel