[FFmpeg-devel] Tee improvement - discussion

Marton Balint cus at passwd.hu
Sun May 22 19:01:27 CEST 2016

On Wed, 18 May 2016, Jan Sebechlebsky wrote:


>>> I'm thinking of implementing this queue by wrapping up AVFifoBuffer 
>>> (similarily than AVThreadMessageQueue does but with the configurable 
>>> behaviour as described above).
>> Exactly what behaviour is missing from AVThreadMessageQueue? Isn't there a 
>> chance to extend that, or implement all additional logic on top of it?
> What is missing is basically just the discussed configurable behaviour how to 
> deal with overfilled queue. I originally thought that the queue would flush 
> old packets automatically (from the point of view of consumer / producer it 
> would be transparent). But if the consumer will be responsible for flushing 
> the packets in non-blocking mode I guess the AVThreadMessageQueue will do the 
> work. This really simplifies the whole task.
> I just wonder, is simply flushing the whole buffer good solution? Shouldn't 
> keyframe flag be considered (either flush until next keyframe(s)), or ignore 
> packet which arrived after flush until new keyframe arrives? If so this 
> wouldrequire some additional functionality to be added to 
> AVThreadMessageQueue (since it would be no longer related to general message 
> queue it should be probably implemented separately).

A consumer would flush the queue (every packet), then clear the overflow 
flag, and then - like you said - ignore (drop) all incoming packets until 
a keyframe arrives, and from that it would start actually processing 
packets. You don't need this functionality in the message queue, the 
consumer can do this as well.


More information about the ffmpeg-devel mailing list