Opened 11 years ago
Closed 7 years ago
#3474 closed enhancement (invalid)
Smart output buffering (with no delay to start playback)
| Reported by: | burek | Owned by: | |
|---|---|---|---|
| Priority: | wish | Component: | ffserver |
| Version: | unspecified | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
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.
ffserver was removed from git master, closing bug as invalid