[Bug 719785] hlssink: does not always adhere to the segment target duration

[GStreamer (GNOME Bugzilla)]

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

--- Comment #13 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to minfrin from comment #12)
> > Why isn't there a keyframe on the stream? Or the problem is that
> > the parser isn't recognizing and marking the keyframes as such?
> 
> As I said above, the stream in my case is broken, and you'll see that by the
> attachment I added. In this particular case, something has gone wrong with
> the encoder, and there a no keyframes.

This is the real bug. Which encoder is this? We should fix the encoder to
generate keyframes again.

> 
> Then this bug kicks in - the hlssink element stops slicing, because all the
> force-key-unit events are being delayed indefinitely. The segment currently
> being written to now grows without bounds, until the partition runs out of
> space, at that point the whole gstreamer pipeline shuts down.
> 
> Obviously we want keyframes at the HLS boundaries, but that is impossible to
> achieve when other elements in the pipeline keep delaying the force-key-unit
> events without being told to do so and moving those boundaries.
> 
> This bug also causes mayhem on live streams coming from unreliable sources
> like DVB. The stream runs for hours without a problem, then suddenly out of
> the blue keyframes stop arriving because of some kind of stream error, and
> thus bug gets triggered. Segment grows indefinitely, out of space, pipeline
> shuts down.

Generating segments without a keyframe at the beginning will break the playback
of your resulting stream, so we would be fixing the wrong bug. Or trading one
bug for another.

> 
> > What exactly is the pipeline that you're using?
> 
> The pipeline is a transcoding pipeline, converting h264 back into h264 after
> resizing.
> 
> It's the equivalent of "[src] ! [timing-element] ! decodebin ! encodebin !
> hlssink".
> 
> The timing element sends downstream force-key-unit events, which are
> intercepted by h264parse, which then delays the force-key-unit, ruining the
> timing. Because h264 is being transcoded to h264 in this case, h264parse
> appears twice in the pipeline, so it breaks whether the timing is controlled
> by the src, or whether controlled by the sink.

So if you have an encoder, it should definitely be generating keyframes every
once in a while. We need to track down why does that stop happening.

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