Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-plugins-ugly gst-plugins-ugly
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 23
    • Issues 23
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamer
  • gst-plugins-uglygst-plugins-ugly
  • Issues
  • #27
Closed
Open
Created Jul 24, 2019 by Juan Ramírez@jramirez.uy

[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:

  • http://video3.earthcam.com/fecnetwork/hdtimes10.flv/.m3u8
  • http://video3.earthcam.com/fecnetwork/9974.flv/.m3u8
  • 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).

Assignee
Assign to
Time tracking