[Bug 785525] New: Variant bitrate switching can fail if a pad is un-linked

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=785525

            Bug ID: 785525
           Summary: Variant bitrate switching can fail if a pad is
                    un-linked
    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: ---

Created attachment 356513
  --> https://bugzilla.gnome.org/attachment.cgi?id=356513&action=edit
Potential patch

I've been testing against a local copy of
http://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8

This is a variant playlist with a couple of alternate AUDIO tracks.

The behaviour is that the stream starts off playing at the lowest bitrate which
gives us pads src_0 (video), src_1 (audio1) and src_2 (audio2). Immediately
after the first fragments are downloaded the code realises it should play one
of the higher bitrates and so gets ready to switch. In order to switch it has
to wait for any fragment downloads on the original pads to complete. Once they
complete, the code triggers a bitrate switch and creates a new set of pads and
continues playing.

However, in our application, we don't attach to src_2 as we're only interested
in the default audio pad. The code attempts to deal with this and describes the
pad as un-linked. The bug is that between _src_chain and
gst_adaptive_demux_stream_download_loop (inside gstadapativedemux.c) the code
doesn't handle the un-linked case fully and it fails to call
gst_adaptive_demux_has_next_period in the GST_FLOW_NOT_LINKED case. 
If src_2 finishes downloading first (or second), then this isn't an issue as
the other pads complete the set of streams in gst_adaptive_demux_combine_flows.
However, if src_2 is the last to finish downloading, the new pads aren't
created and playback grinds to a halt.

I've attached a patch which simply duplicates similar code used in the
GST_FLOW_EOS case above it. Although I believe it resolves this bug, I
immediately hit another issue which I'll file a bug for if this patch does look
sane.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.