[Bug 785986] New: hlsdemux: Variant switching issue with short live playlsts
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Aug 8 08:36:56 UTC 2017
https://bugzilla.gnome.org/show_bug.cgi?id=785986
Bug ID: 785986
Summary: hlsdemux: Variant switching issue with short live
playlsts
Classification: Platform
Product: GStreamer
Version: 1.12.2
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: davecraig at unbalancedaudio.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
This is the stream that I'm using to test:
http://hls.iptv.optimum.net/news12/nipadlive/index_new.m3u8?callsign=N12KN
It's a live stream with two alternate audio playlists alongside the main video
one and it has 4 different bitrates of video. The playlists only have 3
segments each.
The stream fails to start up cleanly about 1 in 4 tries. In those cases the
first video segment plays (lowest bitrate), then the video freezes for about a
segment duration whilst audio plays. Then the audio freezes whilst the video
plays the second segment to catch up. At that point the audio and video are
back in sync and it continues to play correctly.
What's happening is the first video segment is downloaded, and at the same time
all three available audio segments in both spanish and english are downloaded.
The downloads are fast so the code decides to switch to a higher bitrate. If
the variant switch decision happens after the last 2 audio segment downloads
have started (i.e. 4 segments already downloaded) then the adaptivedemux code
waits until they complete before switching. The pads haven't been removed and
re-added yet as that is waiting on the preroll on all pads being handled so
that the caps are available. The preroll on the audio has to wait for:
1. The playlist to be updated on the server with a new segment.
2. The playlist to have actually been downloaded - polled by the client.
Because the audio playlists don't initially contain any more segments, there's
a delay before the pads are exposed. The delay is long enough that the first
video segment has finished playing and so it stalls.
The example stream is a worst case in that it has only has 3 segments per
playlist. But the problem could still happen with longer playlists if the audio
segments download quickly relative to the video segments.
I'm not sure what the best approach to fix this is. Could pads be enabled as
soon as their stream is prerolled, and not wait for the others?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list