[FFmpeg-user] Seeking guidance on debugging rtsp copy to file
Rich Andrews
stuart.r.andrews at gmail.com
Thu Jan 9 18:26:26 EET 2020
ffmpeg is being run as a python subprocess with careful attention to its
given FD's. That part appears likely to be working especially as other
usages of ffmpeg to do non-network things such as transcoding work quite
well using the same subprocess design. It is not believed ffmpeg is
deadlocking on STDIN, STDOUT or STDERR I/O.
The ffmpeg being used is ffmpeg version 4.1.3-1+rpt1 Copyright (c)
2000-2019 the FFmpeg developers built with gcc 8 (Raspbian 8.3.0-6+rpi1)
(full banner below).
ffmpeg is spawned as ffmpeg -nostdin -hide_banner -loglevel verbose -y
-rtsp_transport tcp -i rtsp://192.168.1.168/1 -vcodec copy -acodec copy -f
mp4 {output_url} It is receiving an RTSP substream from an HVEC HDMI
encoder.
What happens is that over time, sometimes within minutes, sometimes after
an hour, ffmpeg ceases writing to {output_url} without outputting
information. STDERR appears as
frame=51659 fps= 20 q=-1.0 size= 519424kB time=00:43:53.63
bitrate=1615.7kbits/s speed= 1x
frame=51669 fps= 19 q=-1.0 size= 519680kB time=00:43:54.09
bitrate=1616.2kbits/s speed=0.988x
At this point, the ffmpeg subprocess will just sit there and not respond to
signaling from the parent (sigint, currently testing sigterm and sigkill)
the parent process will also block on the ffmpeg subprocess exit at this
time, meaning that the parent also does not exit. There is much work to
be done on this point as this is known to be a common source of issues.
ffmpeg when ceasing to write to {output_url} appears to take signals from
an unrelated shell (poor notes on this front, but certainly sigterm works
and IIRC sigint) and exits as would be expected.
When in this condition, I've inspected the ffmpeg subprocess. Its FDs
appear as:
pi at raspberrypi:/tmp $ sudo ls -l /proc/31855/fd
total 0
lr-x------ 1 root root 64 Jan 8 21:18 0 -> /dev/null
l-wx------ 1 root root 64 Jan 8 21:18 1 ->
/tmp/ffmpeg_rtsp_91eac707-3ac3-4080-a5a9-8d9768eaea10.stdout
l-wx------ 1 root root 64 Jan 8 21:18 2 ->
/tmp/ffmpeg_rtsp_91eac707-3ac3-4080-a5a9-8d9768eaea10.stderr
lrwx------ 1 root root 64 Jan 8 21:18 3 -> 'socket:[4128650]'
lrwx------ 1 root root 64 Jan 8 21:18 4 -> 'socket:[4147521]'
l-wx------ 1 root root 64 Jan 8 21:18 5 ->
/tmp/91eac707-3ac3-4080-a5a9-8d9768eaea10.rtsp
lrwx------ 1 root root 64 Jan 8 21:18 6 -> 'socket:[4143741]'
strace shows
pi at raspberrypi:/tmp $ sudo strace -p 31855
strace: Process 31855 attached
poll([{fd=4, events=POLLIN}], 1, 100) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 100) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 100) = 0 (Timeout)
So it appears to me that ffmpeg is probably working properly and that the
RTSP stream maybe goes away on the network. The RTSP server seems to not
go away (remains on LAN, ICMP pings to it are not interrupted).
My next steps are:
1) Replicate this via a shell invocation of ffmpeg vs. as a subprocess
2) Kill remote RTSP server or otherwise perturb WLAN and characterize
ffmpeg exit behavior wrt the socket (difficult as this gear is all remote)
3) Try and catch this condition with -loglevel debug
So my questions could probably have been more brief, "What other debugging
techniques can be applied to introspecting the state of ffmpeg?". I'm
guessing it has something to do with the RTSP stream, RTSP signaling and
the WLAN. But maybe more experienced eyes will see something here and
help provide some guidance as to what I can do from ffmpeg's point of view.
Thanks!
ffmpeg version 4.1.3-1+rpt1 Copyright (c) 2000-2019 the FFmpeg
developers built with gcc 8 (Raspbian 8.3.0-6+rpi1)
configuration: --prefix=/usr --extra-version=1+rpt1 --toolchain=hardened
--libdir=/usr/lib/arm-linux-gnueabihf
--incdir=/usr/include/arm-linux-gnueabihf --arch=arm --enable-gpl
--disable-stripping --enable-avresample --disable-filter=resample
--enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libcodec2 --enable-libflite
--enable-libfontconfig --enable-libfreetype --enable-libfribidi
--enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame
--enable-libmysofa --enable-libopenjpeg --enable-libopenmpt
--enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband
--enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex
--enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp
--enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq
--enable-libzvbi --enable-lv2 --enable-omx --enable-omx-rpi --enable-mmal
--enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r
--enable-libx264 --arch=armhf --enable-shared
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Hyper fast Audio and Video encoder
More information about the ffmpeg-user
mailing list