mirror of https://github.com/FFmpeg/FFmpeg.git
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. Signed-off-by: Martin Storsjö <martin@martin.st>pull/59/head
parent
1c840fa227
commit
296d0da8bd
1 changed files with 5 additions and 2 deletions
Loading…
Reference in new issue