GNOME Bugzilla – Bug 759170
hlssink: doesn't commence writing fragments when inserted into already playing pipeline
Last modified: 2015-12-21 09:06:38 UTC
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.
Do you have a gdb backtrace or perhaps could share a short version of your application that reproduces the issue?
Created attachment 317348 [details] minimal testcase for this issue i made a minimal testcase for this scenario please compile with gcc -Wall -g `pkg-config gstreamer-1.0 --cflags --libs` hlsblock_testcase.c -o hlsblock_testcase usage: ./hlsblock_testcase n] n=0: hlssink goes PLAYING first n>0: fakesink goes PLAYING first, hlssink after n ms even with parameter 0 apparently there is a problem with my audiotestsrc ! capsfilter ! avenc_aac ! queue ! mpegtsmux ! tee ! queue ! hlsmux pipeline though it only generates 16384 bytes worth of segment ts and then stops this problem may be related to my original issue though or actually have the same reason
For your simplification you used audio only ,it is still unsupported: https://bugzilla.gnome.org/show_bug.cgi?id=710203 I'll change it to video and take a look.
It seems to work here when used with video. I had to fix one issue in your code that is: setting the elements to playing before linking them to tee otherwise you risk getting a flushing return. Does applying this fix to your original application make it work? Or is it something else that is not reproducible with this test application?
thiago, that exactly was my problem apparently :) i changed it like you suggested and it magically works. thank you very much.