[FFmpeg-trac] #3474(ffserver:new): Smart output buffering (with no delay to start playback)
FFmpeg
trac at avcodec.org
Mon Mar 17 19:43:49 CET 2014
#3474: Smart output buffering (with no delay to start playback)
---------------------------------------+----------------------------------
Reporter: burek | Owner:
Type: enhancement | Status: new
Priority: wish | Component: ffserver
Version: unspecified | Keywords:
Blocked By: | Blocking:
Reproduced by developer: 0 | Analyzed by developer: 0
---------------------------------------+----------------------------------
If possible, it would be good to enhance the current output buffering of
ffserver so that the output buffer size is calculated in such a way, which
guarantees the buffer will always contain at least 1 key frame.
Further more, after a client connects to the ffserver and requests a
certain stream, it would be ideal for ffserver to skip sending any data in
the buffer prior to that 1 key frame and make sure that key frame is the
first thing that will be sent to the client, along with all the data that
comes after that key frame in the buffer.
This would make it possible to start the playback of the stream
immediately, regardless of the chosen GOP size.
Since the data (and the key frame) is usually in a compressed form, which
makes it difficult to accomplish this in an ideal way (probably the key
frame will be contained in a packet with some delta frames before and
after, compressed altogether), it might (probably) be viable to make
ffserver first mark all the packets in the buffer that contain a keyframe
(for a faster lookup later on) and then, after a client connects and
requests a stream, ffserver could do a fast look-up for a first packet
with a keyframe, decode it, discard all the delta frames prior the
keyframe and re-encode the data back to the packed form (thus creating a
new packet).
This would be done only once, when a new client connects to the ffserver,
so it shouldn't be that much of the overhead (to decompress the packet,
get rid of all the delta frames before the key frame and to re-compress
the key frame and the rest of delta frames back to a new packet).
I know this is probably a much more complicated task, but this would
really be an awesome feature that a lot of people is looking for
desperately, since the live TV re-encoding has become ultra popular and
all that can be done to lower the playback start time is to tamper with
GOP interval, which makes the entire stream encoding much more worse than
it should be.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/3474>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list