After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746906 - hlssink: creates a single segment
hlssink: creates a single segment
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-03-27 19:00 UTC by Ben
Modified: 2016-01-17 15:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

hlssink: implement a default chain_list on the ghostpad (1.72 KB, patch)
2015-03-28 14:41 UTC, Thiago Sousa Santos
none Details | Review
gst.log (686.37 KB, application/x-gzip)
2015-05-11 14:21 UTC, Jan Schmidt

Description Ben 2015-03-27 19:00:21 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
Comment 1 Thiago Sousa Santos 2015-03-28 14:09:29 UTC
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.
Comment 2 Thiago Sousa Santos 2015-03-28 14:41:23 UTC
Created attachment 300518 [details] [review]
hlssink: implement a default chain_list on the ghostpad

Not a definitive solution, just a workaround
Comment 3 Ben 2015-03-29 19:24:16 UTC
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= 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:


Comment 4 Thiago Sousa Santos 2015-03-30 01:43:29 UTC
Are you letting the pipeline run until the end (EOS?) or are you aborting it? If you are, it seems like a separate issue.
Comment 5 Thiago Sousa Santos 2015-03-30 15:32:07 UTC
commit f00aec48fa601f967a9075dca86ead9d882c4f62
Author: Thiago Santos <>
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.
Comment 6 Kai Hendry 2015-05-04 05:51:50 UTC
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.
Comment 7 Tim-Philipp Müller 2015-05-04 10:51:15 UTC
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:
Comment 8 Jan Schmidt 2015-05-06 02:47:40 UTC
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.
Comment 9 Kai Hendry 2015-05-08 13:44:06 UTC
Hi Jan, I see the same behaviour:

Now what? =)
Comment 10 Jan Schmidt 2015-05-11 11:57:55 UTC
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
Comment 11 Thiago Sousa Santos 2015-05-11 14:07:02 UTC
I could look at a log, can you get one for me, please?
Comment 12 Jan Schmidt 2015-05-11 14:21:37 UTC
Created attachment 303219 [details]

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
Comment 13 Thiago Sousa Santos 2015-05-11 14:55:41 UTC
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.
Comment 14 Jan Schmidt 2015-05-11 16:55:29 UTC
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.
Comment 15 Chetan 2015-12-31 15:29:57 UTC
So, any updates on fixing the issue? I am facing the same situation.
Comment 16 Thiago Sousa Santos 2016-01-15 12:34:40 UTC
(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?
Comment 17 Chetan 2016-01-17 15:29:02 UTC
(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: