[Bug 740867] New: dashdemux not flushing stream on pipeline stop for live content

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=740867
  GStreamer | gst-plugins-bad | 1.4.3

           Summary: dashdemux not flushing stream on pipeline stop for
                    live content
    Classification: Platform
           Product: GStreamer
           Version: 1.4.3
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: samuelh at rd.bbc.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=291732)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=291732)
Condensed log of dashdemux comparing a working case to a failure case.

When running a live DASH stream, dashdemux isn't properly ending its session
leading to a hang in GStreamer as it waits.

I've narrowed the actual cause of the hang down to the call to gst_task_join at
around line 1046 in gstdashdemux.c, this never returns as whatever thread it's
running never returns as it's trying to continuously download segments.
Instead, each thread seems to be waiting in gst_dash_demux_download_wait, and
then tries to go off and get more segments.

I've attached a file containing two excerpts of the logs taken from a working
on-demand stream and a failing live stream, showing the differences in what
happens after the stream is stopped. An MPD which recreates the flaw is
available here http://rdmedia.bbc.co.uk/dash/testmpds/multiperiod/bbb.php

I can't quite figure out why it's broken so I'm posting here just in case
anyone else has any ideas. As far as I can see there's no while loops for it to
get stuck in and it should reach the end of gst_dash_demux_stream_download_loop
at which point it will get picked up by the gst_task_join that's waiting but it
never gets there.

It's also worth noting that when dashdemux says that it's fetching the next
fragment, the upstream http src never actually gets anything (but crucially the
httpsrc is still instantiated as it never receives the READY_TO_NULL event to
shutdown).

Best Regards,
Sam

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.