On 09/07/15 19:17, Christian Robottom Reis wrote:
On Thu, Jul 09, 2015 at 09:42:17AM +0200, Luca Barbato wrote:
On 08/07/15 00:09, Christian Robottom Reis wrote:
I really think avconv should be pacing the data output to avoid
congestion, but perhaps I'm missing something obvious.
if your input is not real-time you can use -re to force such pacing.
Using -re when streaming a file doesn't seem to magically solve the
problem, though I'm not sure why. Perhaps the file framerate is already
too high, but at 24fps 1080p I'd assume 100BaseT would be enough.
In my actual use case where I'm doing an x11grab, however, I don't think
-re is appropriate.
I've seen examples with -framerate and others with -r -- what is the
difference?
one sets the capture framerate, the other takes whichever input
framerate and duplicates/drop frames to match the target framerate.
For the former, I'm assuming you mean udp_wmem on the sender and
udp_rmem on the receiver. Am I missing something else?
For the latter, I'm assuming you mean ?buffer_size in the UDP URL. One
thing I'm not clear on is whether that parameter should be supplied in
the avconv commandline, in the client commandline, or both.
Usually the receiver is the one mainly impacted.
I'm surprised a single frame is too large to be transmitted with the
default buffers -- is a 1080p frame that large?
You can use avprobe to see and yes, the defaults are quite tiny compared
and I'd prefer to keep the varnish approach to have the lower layer do
the work than adding buffer (and thread) bloat in the protocol code, but
since it is causing so many issues maybe I'll try to add a workaround on
the protocol code later.
lu
_______________________________________________
libav-tools mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-tools
