[Bug 756181] hlssink: inconsistent segment duration since 1.5.2 onwards

[GStreamer (GNOME Bugzilla)]

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

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |t.i.m at zen.co.uk

--- Comment #2 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
This was probably fixed by this, which is not yet in 1.6.0:

commit 5bf7432f81a095f55f89aa65b4f9f27335e2b747
Author: Tim-Philipp Müller <tim at 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?

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