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

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #15 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
I have the impression the last answer is slightly going off the rational
thinking.

I personally agree that for robustness hlssink should prevent from filling up
the disk. But you will likely be unhappy with what I think hlssink should do in
that situation.

hlssink role is to cut a streams into different files. The cut is done on
keyframe as this is the recommended method to produce an acceptable HLS stream.
At best, hlssink should be configurable to prevent producing file over a
certain threshold. Uppon that threshold (e.g. 10 frames passed the expected
time), it should simply error out. This will break the current stream, but it
will prevent any harm to the server itself.

Now, fixing that is probably trivial, unlike the encoder bug. An encoder should
always be relatively quick on replying to keyframe request. The delay will
depend on the amount of buffering between the encoder and the hlssink. This
threshold should be configurable.

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