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?