Opened 8 years ago
Closed 5 years 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 , 8 years ago
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Priority: | important → normal |
---|
It's better to instead ping your patches on the development mailing list.
by , 8 years ago
Attachment: | 0001-udp-ignore-UDP-packets-without-payload.patch added |
---|
by , 8 years ago
Attachment: | libavformat-aviobuf-dont-treat-0-from-read_packet-as-EOF.patch added |
---|
comment:4 by , 8 years ago
Patches (or alternatives to those patches) should be discussed on the mailing list, which all developers read.
comment:5 by , 8 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.
follow-up: 7 comment:6 by , 8 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.
comment:7 by , 8 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 , 7 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 , 5 years ago
Status: | new → open |
---|
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 , 5 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
I suspect this was fixed in 858db4b01fa2b55ee55056c033054ca54ac9b0fd
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.