FFMPEG uses incorrect MACs when

[Igor Skobkarev]

Summary of the bug:
FFMPEG uses incorrect MAC when the destination multicast address contains .255:

How to reproduce:

./ffmpeg  -re -i "udp://10.250.225.161:5010?fifo_size=1000000&overrun_nonfatal=1" -vcodec copy -acodec copy -f mpegts "udp://239.7.255.1:5004"

TCPDUMP shows that a gateway VRRP MAC (00:00:5e:00:01:01 ) is used instead of Multicast MAC (should be 01:00:5e:07:ff:01 ):

[root@encoder VLC]# tcpdump -i eth0 -vvv -c 1 -e host 239.7.255.1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:43:53.034842 00:1c:c4:6b:93:c0 (oui Unknown) > 00:00:5e:00:01:01 (oui Unknown), ethertype IPv4 (0x0800), length 1514: (tos 0x0, ttl 16, id 0, offset 0, flags [DF], proto UDP (17), length 1500)


ffmpeg version N-45542-gc2c56d5-   http://johnvansickle.com/ffmpeg/    Copyright (c) 2000-2014 the FFmpeg developers
  built on Aug 26 2014 02:30:39 with gcc 4.8 (Debian 4.8.3-9)
  configuration: --enable-gpl --enable-version3 --disable-shared --disable-debug --enable-runtime-cpudetect --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --disable-ffserver --enable-libass --enable-gnutls --cc=gcc-4.8
  libavutil      54.  7.100 / 54.  7.100
  libavcodec     56.  0.101 / 56.  0.101
  libavformat    56.  3.100 / 56.  3.100
  libavdevice    56.  0.100 / 56.  0.100
  libavfilter     5.  0.103 /  5.  0.103
  libswscale      3.  0.100 /  3.  0.100
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  0.100 / 53.  0.100
Hyper fast Audio and Video encoder

[Igor Skobkarev]

Correction:

FMMPEG uses the gateway MAC instead of the Multicast MAC when

• the server has multiple interfaces
• the stream is forced through one of the interfaces using a static route:

[root@encoder /]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.250.225.160 * 255.255.255.224 U 0 0 0 eth0
239.7.254.0 10.250.225.190 255.255.255.0 UG 0 0 0 eth0
239.7.255.0 10.250.225.190 255.255.255.0 UG 0 0 0 eth0
10.42.13.0 * 255.255.255.0 U 0 0 0 eth1
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
10.250.224.0 10.250.225.190 255.255.254.0 UG 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth1
default 10.42.13.254 0.0.0.0 UG 0 0 0 eth1

[Igor Skobkarev]

workaround:

use route via the device not the gateway. I guess the ticket can be closed if that "as-designed" behavior

[root@encoder manpages]# ip route
10.250.225.160/27 dev eth0 proto kernel scope link src 10.250.225.161
239.7.254.0/24 dev eth0 scope link
10.42.13.0/24 dev eth1 proto kernel scope link src 10.42.13.223
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
10.250.224.0/23 via 10.250.225.190 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
default via 10.42.13.254 dev eth1 proto static

[Marton Balint]

I guess this works as it should then.