Zero length packets in UDP stream cause EOF

[danman]

Summary of the bug:
ffmpeg treats UDP packet with zero length payload as EOF and exits.
Example output:
ffmpeg -i udp://@239.255.42.42:5004 out.mp4
ffmpeg version N-86395-g497a4b554c-static ​http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2017 the FFmpeg developers

built with gcc 5.4.1 (Debian 5.4.1-11) 20170519
configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-5 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libass --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg
libavutil 55. 63.100 / 55. 63.100
libavcodec 57. 96.101 / 57. 96.101
libavformat 57. 72.101 / 57. 72.101
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 91.100 / 6. 91.100
libswscale 4. 7.101 / 4. 7.101
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100

udp://@239.255.42.42:5004: could not find codec parameters

How to reproduce:

# tcpreplay -i lo -l 0 lkv.pcap
# route add 239.255.42.42 dev lo
% ffmpeg -i udp://@239.255.42.42:5004 out.mp4
ffmpeg version N-86395-g497a4b554c-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 5.4.1 (Debian 5.4.1-11) 20170519

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[danman]

I also created and submitted two patches which fix this by two different ways but they don't seem to be accepted any soon so I created this ticket to open discussion. Patches are attached.

[Carl Eugen Hoyos]

It's better to instead ping your patches on the development mailing list.

[danman]

I'm rather expecting a discussion about right solution here.

[Hendrik]

Patches (or alternatives to those patches) should be discussed on the mailing list, which all developers read.

[danman]

They should but I've got a feeling that they are ignored. So to keep this issue live, I've opened this ticket.

[Cigaes]

You can open a ticket to make sure that the bug will not be forgotten, but the discussion happens on the mailing list.

As already told there, the first patch you attached is unacceptable as 0-sized packets are valid and relevant in UDP, and the second patch does not distinguish packet-based protocols, that needs to be fixed.

[danman]

Replying to Cigaes:

As already told there, the first patch you attached is unacceptable as 0-sized packets are valid and relevant in UDP, and the second patch does not distinguish packet-based protocols, that needs to be fixed.

In which protocols are 0-sized packets relevant?

[Cigaes]

I hope you remember that this is a public API, so the answer to this question must be searched not just in the FFmpeg code base but in any application implemented using lavf, including unpublished ones. Since empty UDP packets still carry some information (source and destination address), the idea that some protocols use them is not ridiculous and must be taken into consideration.

That is enough to reject the change.

But if you want an actual example, you could do just like me and search the web: apparently, there are firewall hole-punching protocols that use empty packets for keep-alive.

[Balling]

OMG, another patch. Should I search all issues that are open and have a patch? I think we should apply both ​https://patchwork.ffmpeg.org/patch/5426/
and ​https://patchwork.ffmpeg.org/patch/5564/

[Carl Eugen Hoyos]

I suspect this was fixed in 858db4b01fa2b55ee55056c033054ca54ac9b0fd