[FFmpeg-trac] #8840(ffmpeg:new): RTSP+UDP stream fails after upgrading from version 3.4.8
FFmpeg
trac at avcodec.org
Fri Aug 7 01:50:04 EEST 2020
#8840: RTSP+UDP stream fails after upgrading from version 3.4.8
----------------------------------+--------------------------------------
Reporter: tchang97 | Type: defect
Status: new | Priority: normal
Component: ffmpeg | Version: git-master
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
----------------------------------+--------------------------------------
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.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8840>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list