Gabriele Greco wrote:
max_picture_buffer = 1024*100
probesize = 192
max_index_size = 1024*50
I've tried them, just after the call to av_open_input_stream().
m_fctx->max_picture_buffer = 1024*100;
m_fctx->probesize = 192;
m_fctx->max_index_size = 1024*50;
the with subsequents tries I've trimmed down to:
m_fctx->max_picture_buffer = 1024*50;
m_fctx->probesize = 0;
m_fctx->max_index_size = 0;
without any change in the latency... (still in the order of 4/500msec)
I can objectively find the latency of the video cause I have a "private"
mpeg1 system stream that give me a timestamp with msec precision that I can
compare with the DTS value in the last played frame, I decode the private
header myself before feeding the buffer to the library.
I've tried also to use the pipe: protocol handler instead of my own circular
buffer "protocol", without any change :(
Just to add my fuel to the fire - I'm subjectively observing similar
latency on windows when going the opposite direction using VFW
("vfwcap") to capture from a webcam display onscreen. The usual "wave at
yourself" takes easily 1 - 2sec to propagate from camera to my code.
From my code (the moment I finish decoding the frame) to the completion
of the drawing operation (using Qt), is less than 3-9ms.
I'll also try the suggestion context tweaks above, but I'll probably
have similar results to Gabriele.
Anyone have any pointers on how to really tighten down and trim out as
MUCH latency as possible out of this library?
Thanks!
-josiah
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
