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

[Luca Barbato]

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.

> 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

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero