[Bug 759170] New: hlsdemux: doesn't commence writing fragments when inserted into already playing pipeline

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 759170
           Summary: hlsdemux: doesn't commence writing fragments when
                    inserted into already playing pipeline
    Classification: Platform
           Product: GStreamer
           Version: 1.6.0
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fraxinas at opendreambox.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

i've got an application that builds the following pipeline:

audiosrc ! aacparse  ! aqueue ! \             / ! hlsqueue ! hlssink 
                                 .tsmux ! .tee 
videosrc ! h264parse ! vqueue ! /             \ ! appqueue ! appsink

when i set the hlssink to PLAYING first, all works fine and fragments are
generated as expected.

however, when i have appsink at PLAYING first and add hlssink once the playing
time has already advanced, fragment generation will not commence.

i've done some debugging and i by adding a buffer probe at both hlsqueue's and
hlssink's sinkpads i found out the following, in the running case (hlssink goes
into PLAYING from the very beginning)

the first bufferlist passes through hlsqueue
probe_hls_stream: probing bufferlist 0x732181e8 with 117 elements on pad
hlsqueue:sink
probe_hls_stream: probing bufferlist 0x732181e8 with 117 elements on pad
hlssink:sink

and is seen by hlssink
gst_hls_sink_chain_list:<hlssink:sink> chaining each group in list as a merged
buffer

and it requests a new key_unit from upstream
gst_hls_sink_check_schedule_next_key_unit:buffer: 0x73203160, pts
0:00:00.000000000, dts 99:99:99.999999999, dur 99:99:99.999999999, size 188,
offset none, offset_end none, flags 0x4400 
schedule_next_key_unit:<hlssink> sending upstream force-key-unit, index 1 now
0:00:00.000000000 target 0:00:02.000000000

then something happens that i don't really understand - there's a single buffer
seen at the hlssink sinkpad that hadn't previously gone into the hlsqueue:
probe_hls_stream: probing buffer buffer: 0x73203160, pts 0:00:00.000000000, dts
99:99:99.999999999, dur 99:99:99.999999999, size 188, offset none, offset_end
none, flags 0x4400 on pad hlssink:sink

after that, gst_hls_sink_ghost_buffer_probe is called 117 times with
sink->waiting_fku=1

then then the next bufferlist passes through the hlsqueue, causing
gst_hls_sink_chain_list to be called every time until fragment duration is
reached, then it increases the index count and continues fine


in the FAIL case, when hlssink is inserted into a running pipeline,
it works the same way up to the first gst_hls_sink_ghost_buffer_probe call, and
then apparently goes blocking after that, i could only see the probe callbacks
on hlsqueue:sink, not on hlssink:sink and eventually the queue (max-size-time
is fragment duration * 2) runs full and also blocks.

i've put some more debug into gst_hls_sink_chain_list and found out, that
chaining up on the default gst_pad_chain () never returns, so this must be the
culprit.

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