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