Opened 17 months ago

Last modified 15 months ago

#6455 new defect

Zero length packets in UDP stream cause EOF

Reported by: danman Owned by:
Priority: normal Component: avformat
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (11)

Changed 17 months ago by danman

comment:1 Changed 17 months ago by 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.

comment:2 Changed 17 months ago by cehoyos

  • Priority changed from important to normal

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

comment:3 Changed 17 months ago by danman

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

comment:4 Changed 17 months ago by heleppkes

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

comment:5 Changed 17 months ago by danman

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

comment:6 follow-up: Changed 17 months ago by 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.

comment:7 in reply to: ↑ 6 Changed 15 months ago by 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?

comment:8 Changed 15 months ago by 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.

Note: See TracTickets for help on using tickets.