[FFmpeg-devel] [RFC] unix socket protocol and our proto situation

[Martin Storsjö]

On Fri, 13 Aug 2010, Luca Barbato wrote:

> I'm pondering which would be a good solution:
> 
> - do nothing and expect downstream apps cope with it somehow.
> - implement a generic fill thread within proto and change the interface
> so it could use a proper polling system.
> - something else glaring simpler that I hadn't thought.

I'm not too fond of introducing _yet_ another buffering layer. Currently, 
things are buffered in the kernel, sometimes a little in the URLContext 
(for some protocols), in ByteIOContext, and at last the demuxed packets 
within the end-user application (e.g. ffplay).

To solve this in ffplay, I'd rather have a flag specifying that there 
should be no max limit for the packet queues, so that the application 
always sits blocking and waiting for more packets on the demuxer/proto 
level. If the packet queues within ffplay grow very large, we could 
discard earlier packets and "jump ahead" if we can't keep up.

Currently the problem manifests itself when reading realtime data, and 
av_find_stream_info() reads in quite a bit of data before returning the 
control to the app. After this, there's already quite a bit of data ready, 
so it may take a while before ffplay calls av_read_frame() enough to 
actually read more data from the underlying layer, and we will have missed 
packets.

// Martin