[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