aboutsummaryrefslogtreecommitdiffstats
path: root/libavformat/xmv.c
diff options
context:
space:
mode:
authorMartin Storsjö <martin@martin.st>2012-07-03 22:57:19 +0300
committerMartin Storsjö <martin@martin.st>2012-07-04 11:11:08 +0300
commit296d0da8bd3b5bc5220a3b062d387bf9fa4584c5 (patch)
tree0b75d25b09666b416e2ab8f47ec8856611bfc395 /libavformat/xmv.c
parent1c840fa227527c47f5e5b5954eab2b72d6b20632 (diff)
downloadffmpeg-296d0da8bd3b5bc5220a3b062d387bf9fa4584c5.tar.gz
avplay: Add an option for not limiting the input buffer size
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>
Diffstat (limited to 'libavformat/xmv.c')
0 files changed, 0 insertions, 0 deletions