Opened 4 years ago

Closed 21 months ago

#6455 closed defect (fixed)

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.

Attachments (3)

Change History (13)

by danman, 4 years ago

Attachment: lkv.pcap added

comment:1 by danman, 4 years ago

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 by Carl Eugen Hoyos, 4 years ago

Priority: importantnormal

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

comment:3 by danman, 4 years ago

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

comment:4 by Hendrik, 4 years ago

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

comment:5 by danman, 4 years ago

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 by Nicolas George, 4 years ago

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.

in reply to:  6 comment:7 by danman, 4 years ago

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 by Nicolas George, 4 years ago

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.

comment:9 by Balling, 21 months ago

Status: newopen

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/

comment:10 by Carl Eugen Hoyos, 21 months ago

Resolution: fixed
Status: openclosed

I suspect this was fixed in 858db4b01fa2b55ee55056c033054ca54ac9b0fd

Note: See TracTickets for help on using tickets.