ffmpeg should honour most of sysexits.h

[Lars Bahner]

So this bug is simple to explain. At our business ffmpeg runs a transcoe job and writes to a networked filesystem. This generally works great.
In this instance the network glitshed and the NAS was unavailable, but ffmpeg still exited with error code 0.

This is a bug. I understand that ffmpeg should not exit in many situations due to errors, seeing as one of the jobs so well is fix bad input data, which generates loads of error situations.

So using -xerror is not an option here.

stdout from run attached, together with cmdline. The error that should have caused an exit, however is here:

frame= 2998 fps= 20 q=27.0 size= 2816kB time=00:02:00.46 bitrate= 191.5kbits/s speed=0.785x
[mp4 @ 0x76b3340] Starting second pass: moving the moov atom to the beginning of the file
[mp4 @ 0x76b3340] Unable to re-open /data/felles.ds.nrk.no/produksjon/potion/archive/OnDemand/Prod/92/9223d2ab-0a62-4a59-a3d2-ab0a62ea593e/2020021419551375/RAYLEE-MGP-W-130220-SL_20200214195333_4_469513_141.mp4 output file for the second pass (faststart)
Error writing trailer of /data/felles.ds.nrk.no/produksjon/potion/archive/OnDemand/Prod/92/9223d2ab-0a62-4a59-a3d2-ab0a62ea593e/2020021419551375/RAYLEE-MGP-W-130220-SL_20200214195333_4_469513_141.mp4: No such file or directory
frame= 3018 fps= 18 q=-1.0 Lsize= 2934kB time=00:02:00.72 bitrate= 199.1kbits/s speed=0.726x

As it turns out around 600 files in out movie archive generated this year are corrupt, without us knowing.

[Lars Bahner]

stdout

[Lars Bahner]

cmdline

[Lars Bahner]

sysexits.h for lazy perusal :-)

[Carl Eugen Hoyos]

For future tickets, please test current FFmpeg git head, not an six-months old version.