[libav-tools] libav UDP stream and packet loss in mixed 100/1000 network
lu_zero at gentoo.org
Sun Jul 12 12:39:44 CEST 2015
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
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.
More information about the libav-tools