Hi, While doing systematic testing of ffmpeg 8.1.1 I found a few cases where the exit code is 0 but the output is empty or unplayable, with no way for a caller to detect the failure.
The first is -t with a non-positive value: ffmpeg -i input.mp4 -t 0 -c copy -y out.mp4 -> exits 0, produces a ~500-byte file with duration=N/A The history here is a bit involved. In July 2008 Sabatini added an early exit in av_encode() when recording_time <= 0 (committed after Niedermayer's "ok"). In February 2010 Wolfram Gloger added the is_past_recording_time flag on input streams (r21687) to stop reading past the -t limit, and three days later removed Sabatini's early exit as "no longer necessary after r21687" (r21760). The problem is that r21687's mechanism only prevents further packet reads; it does not prevent the muxer from being opened in the first place. In the current code, of_streamcopy() in ffmpeg_mux.c checks dts >= of->recording_time + start_time which for recording_time=0 fires on the first packet, but by then the output container has already been opened and written, so the result is a broken file rather than nothing. The fix Sabatini had in 2008 was correct for this case and should be restored: reject recording_time <= 0 before the muxer is opened, with a clear error message. The second is -ss producing no output in stream copy mode, which happens in at least two ways: ffmpeg -i short.mp4 -ss 999 -c copy -y out.mp4 -> exits 0, "Output file is empty, nothing was encoded" to stderr ffmpeg -i short.mp4 -ss -5 -c copy -y out.mp4 -> exits 0, output file has duration=N/A (broken container) The first triggers when -ss exceeds the file duration; the second when a negative -ss value (documented as "seek from end") is used with stream copy, where the seek-from-end semantics are apparently not implemented and the result is a broken file rather than an error. In both cases the warning or silence does not affect the exit code, so automated callers have no way to detect the failure. My plan is to add a recording_time <= 0 check in of_open() with AVERROR(EINVAL), and to promote the "nothing was encoded" path to a non-zero exit. Before writing the patches I wanted to check whether either behavior was intentional, or whether there is something in the scheduler architecture I should be aware of. John Smith _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
