Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#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/
  • 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/

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 Trenton Chang, 4 years ago

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

comment:2 by Carl Eugen Hoyos, 4 years ago

Component: ffmpegundetermined
Keywords: rtsp regression added

comment:3 by Andriy Gelman, 4 years ago

You can fix the problem by adding "-rtpflags send_bye" to the server side options.

comment:4 by Carl Eugen Hoyos, 3 years ago

Component: undeterminedavformat
Resolution: fixed
Status: newclosed

comment:5 by Carl Eugen Hoyos, 3 years ago

Priority: normalimportant
Note: See TracTickets for help on using tickets.