On 07/03/2012 10:06 PM, Martin Storsjö wrote: > For reading from normal files on disk, the queue limits for > demuxed data work fine, but for reading data from realtime > streams, they mean we're not reading from the input stream > at all once the queue limit has been reached. For TCP streams, > this means that writing to the socket from the peer side blocks > (potentially leading to the peer dropping data), and for UDP > streams it means that our kernel might drop data. > > For some protocols/servers, the server initially sends a > large burst with data to fill client side buffers, but once > filled, we should keep reading to avoid dropping data. > > For all realtime streams, it IMO makes sense to just buffer > as much as we get (rather in buffers in avplay.c than in > OS level buffers). With this option set, the input thread > should always be blocking waiting for more input data, > never sleeping waiting for the decoder to consume data. > --- > For video+audio streams, avplay only stops buffering data > once there is 320 KB data buffered, but if there's only > a video stream but no audio, it stops buffering once there's > 5 frames buffered. >
Fine for me. -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
