GNOME Bugzilla – Bug 746906
hlssink: creates a single segment
Last modified: 2016-01-17 15:29:02 UTC
Only the first segment segment00000.ts is created and its size increases without limit. gst-launch-1.0 videotestsrc is-live=true ! x264enc ! mpegtsmux ! hlssink
It seems to be related to the fact that hlssink uses buffer probe while mpegtsmux is now pushing buffer lists. In 1.4 it also was failing but I suspect it was for a different reason.
Created attachment 300518 [details] [review] hlssink: implement a default chain_list on the ghostpad Not a definitive solution, just a workaround
With the patch I'm getting segments but the last segment is missing from playlist.m3u8. When I manually include the last segment it plays fine. Not sure if this is related or a separate issue. This creates 4 segments. gst-launch-1.0 -v uridecodebin uri=http://mirror.cessen.com/blender.org/peach/trailer/trailer_iphone.m4v name=decbin ! video/x-raw ! x264enc ! mpegtsmux name=muxer ! hlssink target-duration=10 decbin. ! audioconvert ! audio/x-raw ! voaacenc ! aacparse ! muxer. The generated playlist.m3u8. segment00003.ts is missing: #EXTM3U #EXT-X-VERSION:3 #EXT-X-ALLOW-CACHE:NO #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-TARGETDURATION:10 #EXTINF:10.079999923706055, segment00000.ts #EXTINF:10.079999923706055, segment00001.ts #EXTINF:10.079999923706055, segment00002.ts
Are you letting the pipeline run until the end (EOS?) or are you aborting it? If you are, it seems like a separate issue.
commit f00aec48fa601f967a9075dca86ead9d882c4f62 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Sat Mar 28 11:40:14 2015 -0300 hlssink: implement a chain_list to request key unit for segments upstream might send buffer lists instead of buffers and hlssink's probe won't get called and a new segment won't be created when needed. This patch fixes it by adding a chain_list function to the sink pad that will just pass through the whole bufferlist if no segment needs to be requested at the moment or convert the list into buffers to check the proper timestamp to request the next key-unit that will start the segment. https://bugzilla.gnome.org/show_bug.cgi?id=746906
I've noticed this issue on gstreamer 1.4.5-1. [root@pihsg hls]# raspivid -t 0 -w 640 -h 480 -fps 15 -vf -b 1000000 -o - | gst-launch-1.0 fdsrc ! hlssink target-duration=10 max-files=5 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ^Cmmal: Aborting program handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 1:23:54.401452590 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... IIUC raspivid provides h264encoded input, so there is no need for h264enc or omxh264enc. Which resulted erroneously in -rw-r--r-- 1 root root 424M May 4 13:37 segment00000.ts Hopefully 1.5.1 will be packaged soon in Arch.
Kai, that's not going to work very well. Maybe try this instead, which should do the same as raspivid but as a proper GStreamer element: https://github.com/thaytan/gst-rpicamsrc/
I replied on my blog, but I guess I should install a notifications plugin or something... You need to provide muxed input to hlssink. Try this: gst-launch-1.0 rpicamsrc bitrate=1000000 vflip=true ! video/x-h264,width=640,height=480,framerate=15/1 ! h264parse ! mpegtsmux name=muxer ! hlssink target-duration=10 max-files=5 When I tested though, it didn't work well... It creates a first segment, then puts everything into the 2nd segment without moving to a 3rd for some reason. Let me know.
Hi Jan, I see the same behaviour: https://github.com/thaytan/gst-rpicamsrc/pull/27#issuecomment-100237232 Now what? =)
Hopefully someone that understands how hlssink works can make a better guess about what rpicamsrc might do differently that would break switching to a 3rd fragment, or suggest which debug output might be useful for diagnosis
I could look at a log, can you get one for me, please?
Created attachment 303219 [details] gst.log Output from GST_DEBUG=*hls*:6,*mux*:6,*rpicam*:6 gst-launch-1.0 rpicamsrc bitrate=1000000 vflip=true keyframe-interval=15 num-buffers=1000 ! video/x-h264,width=640,height=480,framerate=15/1 ! h264parse ! mpegtsmux name=muxer ! hlssink target-duration=5 max-files=5 2> gst.log
I'm guessing it is related to this: 0:00:06.826250847 25182 0xb78a00 INFO mpegtsmux mpegtsmux.c:994:check_pending_key_unit_event: now 0:00:05.668658672 wanted 0:00:05.000000000 (gst-launch-1.0:25182): GStreamer-CRITICAL **: gst_event_get_structure: assertion 'GST_IS_EVENT (event)' failed (gst-launch-1.0:25182): GStreamer-CRITICAL **: gst_event_get_seqnum: assertion 'GST_IS_EVENT (event)' failed (gst-launch-1.0:25182): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object->refcount > 0' failed 0:00:06.827234899 25182 0xb78a00 INFO mpegtsmux mpegtsmux.c:1145:mpegtsmux_collected_buffer:<muxer> pushing downstream force-key-unit event -1 0:00:05.668658672 count 0 0:00:06.827540915 25182 0xb78a00 INFO hlssink gsthlssink.c:456:gst_hls_sink_ghost_event_probe:<hlssink0> setting index 0 0:00:06.917672666 25182 0xb78a00 INFO hlssink gsthlssink.c:274:gst_hls_sink_handle_message:<hlssink0> COUNT 0 As the access on the event parameters fails because there is some refcounting issue apparently it ends up always using COUNT=0 which will prevent hlssink to create the correct segment file names. I couldn't find anything obviously wrong with mpegtsmux event handling or in h264parse or rpicamsrc but I also noticed that the line numbers are not matching perfectly with the source, perhaps this has already been fixed usptream? Also replacing rpicamsrc with videotestsrc works here on the desktop.
I think rpicamsrc is supposed to hold onto the key_unit event and keep it alive until after it sends the next keyframe. That's what other elements that handle it seem to do. I suspect that means someone isn't holding a ref when they should though.
So, any updates on fixing the issue? I am facing the same situation.
(In reply to Chetan from comment #15) > So, any updates on fixing the issue? I am facing the same situation. What version are you using?
(In reply to Thiago Sousa Santos from comment #16) > (In reply to Chetan from comment #15) > > So, any updates on fixing the issue? I am facing the same situation. > > What version are you using? the bug is now fixed by Jan Schmidth. please find more details at: https://github.com/thaytan/gst-rpicamsrc/issues/43