[FFmpeg-devel] [RFC] unix socket protocol and our proto situation
Fri Aug 13 13:49:27 CEST 2010
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:
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
More information about the ffmpeg-devel