[Bug 785986] New: hlsdemux: Variant switching issue with short live playlsts

[GStreamer (GNOME Bugzilla)]

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.