[FFmpeg-user] RTSP+UDP stream fails after upgrade from version 3.4.8

Trenton Chang tchang97 at stanford.edu
Thu Aug 6 22:07:22 EEST 2020 


________________________________
From: ffmpeg-user <ffmpeg-user-bounces at ffmpeg.org> on behalf of zhilizhao <quinkblack at foxmail.com>
Sent: Thursday, August 6, 2020 6:00 AM
To: FFmpeg user questions <ffmpeg-user at ffmpeg.org>
Subject: Re: [FFmpeg-user] RTSP+UDP stream fails after upgrade from version 3.4.8



> On Aug 4, 2020, at 8:11 AM, Trenton Chang <tchang97 at stanford.edu> wrote:
>
> Hi 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
>
> Logs and descriptions
>
> The following files are all hosted at https://drive.google.com/drive/folders/1oQnh-kAL4x6Zm-kaRDP_9aZgLH9YG2ub?usp=sharing.
>
> ffmpeg-20200803-170914.log: Using ffmpeg version N-98617-g533d603, client-side command run with addition arguments -report -loglevel 99 -v 9 . This command hangs.
> ffmpeg-20200803-170915.log: Using ffmpeg version N-98617-g533d603, server-side command run with addition 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 addition 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 addition 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/
>
> Networking/systems is certainly not my area of expertise, so I'd appreciate any help here. Please let me know if there's other logs or information that you'd find helpful. Thank you in advance.

Here is a patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267437.html <http://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267437.html>

It should solved the hang issue. I’m worried it may cause spurious EOF
(missing a few packets at the end of the stream) which the following
patch tried to solve:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20171201210915.18571-1-tmatth@videolan.org/ <https://patchwork.ffmpeg.org/project/ffmpeg/patch/20171201210915.18571-1-tmatth@videolan.org/>

Can you file a bug on https://trac.ffmpeg.org <https://trac.ffmpeg.org/> ?

>
> Best,
>
>
> Trenton Chang
>
> M.S. Candidate in Computer Science
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".

Thanks so much for the help! That fix makes sense -- the client was sending a 200 OK in response to the teardown message, but still stayed in the loop. Seems like the patch you mentioned from 2017 came right after the 3.4.8 release, so that could be the cause. I'll file a bug as you mentioned.

Trenton

More information about the ffmpeg-user mailing list