[libav-tools] libav UDP stream and packet loss in mixed 100/1000 network

Christian Robottom Reis kiko at async.com.br
Sat Jul 4 17:52:19 CEST 2015


Hello there,

    We've been working on a project to stream a screencast from an x86
machine with a gigabit NIC to half a dozen Raspberry Pi devices (with
fast ethernet NICs) connected to TV screens. Our plan is to send a
multicast UDP to omxplayer on the client side. However, we've stumbled
upon a problem: streaming using avconv from the gigabit host to the rpi
is resulting in dramatic (30%+) packet loss on the rpi side.

The setup to reproduce the issue is fairly simple. On the x86 side,
we stream something via UDP:

    avconv -re -i big_buck_bunny_1080p_h264.mov -f mpegts udp://pi:8765/

and on the rpi side we try and play that stream with omxplayer, which
renders the video with artifacts (green and grey pixelated video,
vertical stripes, etc) typically present when there is packet loss.

With tcpdump we can actually confirm that 30% of the packets being sent
never hit omxplayer. The question we've been unable to answer is where
are the packets being dropped -- neither ifconfig nor netstat -us can
match the actual number of lost packets, which we can tell by capturing
on both sender and receiver.

We had originally put the blame squarely on the rpi NIC, but today we
discovered that iperf -u does not trigger any significant loss, and we
were surprised by that -- not even when we specify an 80Mbps rate. I
thought the issue might have to do with UDP fragmentation, but adding a
?pkt_size=1316 option to the udp:// URL makes no real difference.

I had posted originally to the rpi stack exchange:

    http://raspberrypi.stackexchange.com/questions/33136/packet-loss-when-receiving-udp-stream

but now that I have been able to reproduce this against an x86 node with
fast ethernet I'm thinking it is a wider issue. My questions:

Could the issue have to do with how fast avconv is sending the packets,
since it is oblivious to the fact that the network on the client side is
10x slower?

If so, why does iperf fare better?

And if this is known, is there a workaround I can use?

Thanks!
-- 
Christian Robottom Reis | [+55 16] 3376 0125   | http://async.com.br/~kiko
CEO, Async Open Source  | [+55 16] 9 9112 6430 | http://launchpad.net/~kiko


More information about the libav-tools mailing list