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

[Martin Storsjö]

On Fri, 13 Aug 2010, Luca Barbato wrote:

> On 08/13/2010 12:39 PM, Martin Storsj? wrote:
> > 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).
> 
> - the URLContext is where I'd put the buffer so at least that part would
> be more uniform.
> 
> > 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.
> 
> still we would be with a situation like this:
> 
> loop:
>   select()
>     loop:
>       select()
>     loop:
>       select()
>   ...
> 
> That isn't exactly optimal. and the loop-select is common among most
>  of the network protos and could be factored away.

That's only present in RTSP afaik, and is there due to the layering of 
URLContexts. Sure it could be avoided, but I don't see it as a big issue, 
the layering gives us lots of other benefits in that case.

> > 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.
> 
> yup

Therefore, as far as I see it, the application should choose itself how 
much it wants to buffer, and with such a flag to ffplay (I can try to do 
it, but don't have time now) this shouldn't be an issue.

// Martin