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 756181 - hlssink: inconsistent segment duration since 1.5.2 onwards
hlssink: inconsistent segment duration since 1.5.2 onwards
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.6.0
Other Linux
: Normal critical
: 1.6.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-10-07 12:28 UTC by Julian Bouzas
Modified: 2015-10-25 09:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Julian Bouzas 2015-10-07 12:28:54 UTC
hlssink generates segments with different durations since version 1.5.2 (version 1.5.1 works fine). I downloaded and build on x86_64 gst-plugins-bad source versions 1.5.1, 1.5.2 and 1.6.0 and run the following pipeline:

gst-launch-1.0 videotestsrc is-live=1 ! x264enc speed-preset=1 ! mpegtsmux ! hlssink target-duration=1

On version 1.5.2, I noticed that the segment duration starting from the second segment is 0.23 seconds:

segment00000.ts -> 01.00 seconds
segment00001.ts -> 00.23 seconds
segment00002.ts -> 00.23 seconds
...

This also happens on version 1.6.0. However, it works fine on version 1.5.1, the segment duration for all segments is always 1 second.

I am not really sure if it is an hlssink issue, I have checked the changes between both versions (1.5.1 and 1.5.2) and I can see there is a big change in mpegtsmux that has to do with timestamps (commit e000a6f0a4984fbe81190df6cd439c70dafde3d6)
Comment 1 Thiago Sousa Santos 2015-10-19 18:38:22 UTC
I'm using git master and it seems to work correctly for me, anything special on your setup?
Comment 2 Tim-Philipp Müller 2015-10-19 18:49:12 UTC
This was probably fixed by this, which is not yet in 1.6.0:

commit 5bf7432f81a095f55f89aa65b4f9f27335e2b747
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Wed Sep 30 00:36:14 2015 +0100

    mpegtsmux: fix downstream key unit events handling with hlssink
    
    The buffer timestamps in the collect function will already be
    running time, don't try to convert them again to running time,
    this would yield CLOCK_TIME_NONE now that the segment is shifted
    to account for negative dts.
    
    This fixes x264enc ! mpegtsmux ! hlssink, which was broken
    because mpegtsmux would send a downstream key unit event with
    running time NONE and then hlssink would immediately send
    another one upstream and it would just be a flood of force
    keyframe events in both directions after the first one. This
    would then break hlssink because it uses multifilesink in
    next-file=key-unit-event mode, and starting a new file after
    every few kB does not work well for HLS.

http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst/mpegtsmux?id=5bf7432f81a095f55f89aa65b4f9f27335e2b747

Could you try if that patch fixes it for you?
Comment 3 Julian Bouzas 2015-10-19 21:12:07 UTC
Hi Tim,

That patch fixes the issue, now the segments are generated correctly. Thank you very much for your help, I appreciate it a lot as we were stuck with 1.5.1.
Comment 4 Tim-Philipp Müller 2015-10-19 22:08:10 UTC
Thanks for testing and confirming it fixes it.
Comment 5 Tim-Philipp Müller 2015-10-25 09:33:47 UTC
Forgot to mark this as FIXED.