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.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
