#8840 closed defect (fixed)
RTSP+UDP stream fails after upgrading from version 3.4.8
Reported by: | Trenton Chang | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avformat |
Version: | git-master | Keywords: | rtsp regression |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
i all,
I was hoping to get some help on my streaming setup. I am currently working on some video-related experiments involving streaming H.264-encoded video using UDP.
My setup:
OS: Ubuntu 18.04.4 LTS (reproduced on Ubuntu 20.04 LTS as well)
Ffmpeg version: N-98617-g533d603 (reproduced with 4.3 as well)
Configuration settings:
--prefix=/home/trenton-windows/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/trenton-windows/ffmpeg_build/include --extra-ldflags=-L/home/trenton-windows/ffmpeg_build/lib --extra-libs='-lpthread -lm' --bindir=/home/trenton-windows/bin --enable-gpl --enable-gnutls --enable-libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-debug=3 --disable-optimizations --disable-stripping libavutil 56. 57.100 / 56. 57.100 libavcodec 58. 99.100 / 58. 99.100 libavformat 58. 49.100 / 58. 49.100 libavdevice 58. 11.101 / 58. 11.101 libavfilter 7. 87.100 / 7. 87.100 libswscale 5. 8.100 / 5. 8.100 libswresample 3. 8.100 / 3. 8.100 libpostproc 55. 8.100 / 55. 8.100
Problem Description:
On the same machine, I run the following two commands:
Client side:
ffmpeg -y -rtsp_flags listen -timeout 10 -i rtsp://localhost:12345/live.sdp -c copy test.mp4
Server side:
ffmpeg -re -i TVs_Best_Kisses_Top_50_\(52_to_41\)_kiss_h_nm_np2_le_goo_1.avi -vcodec libx264 -strict 2 -f rtsp -rtsp_transport udp rtsp://localhost:12345/live.sdp
This works without a hitch on ffmpeg 3.4.8-0ubuntu0.2
(installed via apt-get), and I can open test.mp4
in a media player to view a streamed copy of the input video file. However, I have since upgraded to the most recent version because I need to use the -stream_loop
functionality, which was buggy in older versions of ffmpeg. When I run the same commands as above in the updated version, however, the client side hangs indefinitely. However, it works when I switch protocol to TCP (using -rtsp_transport tcp
). This happens regardless of the input file that I use. When I Ctrl-C the client, I see a file called test.mp4
, but it's unplayable, which I can tell because ffprobe
outputs the following:
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x562e3d718e80] moov atom not found test.mp4: Invalid data found when processing input
I've attached log files following the bug report guidelines at ffmpeg.org for both the commands above, as well as some auxiliary logs.
Logs and descriptions
ffmpeg-20200803-170914.log
: Using ffmpeg version N-98617-g533d603, client-side command run with additional arguments -report -loglevel 99 -v 9
. This command hangs.
ffmpeg-20200803-170915.log
: Using ffmpeg version N-98617-g533d603, server-side command run with additional arguments -report -loglevel 99 -v 9
. This works without a problem.
ffmpeg-20200803-172801.log
: Using ffmpeg version 3.4.8-0ubuntu0.2, client-side command run with additional arguments -report -loglevel 99 -v 9
. This works without a problem.
ffmpeg-20200803-172802.log
: Using ffmpeg version 3.4.8-0ubuntu0.2, server-side command run with additional arguments -report -loglevel 99 -v 9
. This works without a problem.
gdb.txt
: ffmpeg_g log for the client; with SIGINT at the point where it hangs (seems like it waits for a packet forever).
TVs_Best_Kisses_Top_50_(52_to_41)_kiss_h_nm_np2_le_goo_1
: Input video file for the commands in these logs, for completeness. The problem I'm describing happens regardless of which video file I try to stream.
What I've tried (all of these have failed):
- Messed with the client buffer size, by appending buffer_size and fifo_size arguments to the client-side input URL like so:
rtsp://localhost:12345/live.sdp?buffer_size=10000000?fifo_size=100000
- In response to warnings about PTS/DTS issues on the client-side, I added the options
-fflags +genpts+igndts
to the client-side command. I also tried just-fflags +genpts
. - Tried adding
-vsync 0
to the server side command as an output option. - Removed
-vcodec libx264 -strict 2
on the server side. - Removed the
-re
real-time streaming option on the server side. - Changed port no. from 12345.
- Tried streaming raw UDP w/o RTSP (still hangs, same issue).
- Client-side command:
ffmpeg -y -i udp://localhost:12345/ -c copy test.mp4
- Server-side command:
ffmpeg -y -re -i TVs_Best_Kisses_Top_50_\(52_to_41\)_kiss_h_nm_np2_le_goo_1.avi -vcodec libx264 -strict 2 -f mpegts udp://localhost:12345/
- Client-side command:
- Tried using RTP protocol, results in error
[rtp @ 0x561525b9e680] Unable to receive RTP payload type 96 without an SDP file describing it
- Client-side command:
ffmpeg -i rtp://localhost:12345 -c copy test.mp4
- Server-side command:
ffmpeg -y -re -i TVs_Best_Kisses_Top_50_\(52_to_41\)_kiss_h_nm_np2_le_goo_1.avi -vcodec libx264 -strict 2 -f rtp rtp://localhost:12345/
- Client-side command:
I previously reported this on the ffmpeg-users email list, and I believe zhilizhao submitted the following patch a few hours ago: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267437.html, which breaks out of udp_read_packet
in libavformat/rtsp.c
when RTSP is in a teardown state to avoid an infinite loop.
It seems that my issue might originate from this patch: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20171201210915.18571-1-tmatth@videolan.org/ -- which was intended to solve spurious EOFs in RTSP.
Change History (5)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
Component: | ffmpeg → undetermined |
---|---|
Keywords: | rtsp regression added |
comment:3 by , 4 years ago
You can fix the problem by adding "-rtpflags send_bye" to the server side options.
comment:4 by , 4 years ago
Component: | undetermined → avformat |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed by Martin in 0b1d8468c4dca00e361186cce05a9683326593c3
comment:5 by , 4 years ago
Priority: | normal → important |
---|
The files are over the size limit, so I have provided a link to a Google Drive folder with the logs I mentioned.
https://drive.google.com/drive/u/1/folders/1oQnh-kAL4x6Zm-kaRDP_9aZgLH9YG2ub