[FFmpeg-user] What is expected ffmpeg behavior when output device is slow?

[Rich Andrews]

Hi everyone,

I think I've isolated the cause of the trouble I'm having, but thought to
bounce it off the list to keep me honest and maybe provide some searchable
insight for a future user.

First off, it it doesn't appear to be a problem with ffmpeg.  The problem
appears related to the output device.  What is the output device? rpi 3b+
w/ a decent SD Card which is not a great output device.

What I'm trying to do:  Copy an hevc stream set up via RTSP to a file.
a/vcodec copy.  One manner of invocation is:

ffmpeg -nostdin -loglevel verbose -hide_banner -y -rtsp_transport tcp -i
rtsp://192.168.5.168/hdmi -vcodec copy -acodec copy -f mp4 /tmp/test4.mp4

When the output device is fully utilized causing processes to spend time in
uninterruptible sleep, it appears ffmpeg frequently arrives at, "No more
output streams to write to, finishing".

No more output streams to write to, finishing.
   video:54157kB audio:617kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.103987%
Input file #0 (rtsp://192.168.5.168/hdmi):
  Input stream #0:0 (video): 1580 packets read (55456274 bytes);
  Input stream #0:1 (audio): 2467 packets read (631630 bytes);
  Total: 4047 packets (56087904 bytes) demuxed
Output file #0 (/tmp/test4.mp4):
  Output stream #0:0 (video): 1580 packets muxed (55456274 bytes);
  Output stream #0:1 (audio): 2467 packets muxed (631630 bytes);
  Total: 4047 packets (56087904 bytes) muxed

How this was made mostly reproducible:

Hit the output device with big dd's (e.g. dd if=/dev/zero of=testfile
bs=100k count=50k) until the "No more output streams to write to,
finishing" message occurs.  ffmpeg hardly needs any cpu time for the
operation it is performing and tolerates excessive load.

When the ouput device is full, similar output, but with more specific
information about the device full.

No more output streams to write to, finishing.
Error writing trailer of /tmp/test6.mp4: No space left on device
frame=  108 fps=0.0 q=-1.0 Lsize=    3328kB time=00:00:54.87 bitrate=
496.9kbits/s speed=  64x
video:3599kB audio:42kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
Input file #0 (rtsp://192.168.5.168/hdmi):
  Input stream #0:0 (video): 108 packets read (3684902 bytes);
  Input stream #0:1 (audio): 167 packets read (42801 bytes);
  Total: 275 packets (3727703 bytes) demuxed
Output file #0 (/tmp/test6.mp4):
  Output stream #0:0 (video): 108 packets muxed (3684902 bytes);
  Output stream #0:1 (audio): 167 packets muxed (42801 bytes);
  Total: 275 packets (3727703 bytes) muxed
[AVIOContext @ 0x33406b0] Statistics: 2 seeks, 18 writeouts
Conversion failed!

I'm still a bit puzzled that ffmpeg will occasionally exit with the same
message when there is no apparent output device contention.  But watching
iotop, for example, it is pretty apparent that SD Card I/O is great until
it is not great. Easy to imagine given the nature of the type of memory and
its controller.

My only question at this point is if there are any params that might make
ffmpeg more tolerant to not being able to write out to a device.  I
couldn't find much information on the thread_queue_size option and it
appears ffmpeg hardly uses any memory during the a/vcodec copy.

Thoughts?