Feat: Error instead of warn at seeking timecode mismatch
|Reported by:||wader8||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Summary of the feature:
Provide an option, to enable breaking with error, instead of just a warning, when the seeking timecodes are mismatched, eg, -to value being smaller than -ss. (the "ignoring -to" is a warning) - The resulting error should stop the current session from executing any further operations, a standard error that batch files can operate with (windows in my case)
The use of seeking is also used to get rid of the rest as one of the primary reason behind the use of the program, so there is no need for ffmpeg to continue it's encoding/decoding/recoding operations as when the "ignoring -to" warning happens it does not stop the output operation, which in such a case would be preferred.
Furthermore in such a particular case, with many entries used in a batch file, to automate the process, it hinders the very purpose of automation as it requires constant monitoring, otherwise the mismatched entry will unnecessairly recode the input in-whole instead of skipping and moving to the next entry specified in a batch file.
In the worst case scenario, with large inputs and low disk space and with other concurrent space-consuming tasks, a single mismatch may cause a total disruption of all other computer applications if the input is large enough that it would fill up the disk space is was not supposed to.
Timecode mismatch is not a bug - reason:
Human Error - mistmatched timecodes are a result of typos, not unusual in this case.
Option 1a: -seekerror
Break with error/stop when -ss -to timecodes are mismatched.
Option 1b: -seekwarn
Default being error stop, enable (existing) warning only with this command.
How to reproduce:
% ffmpeg -i input ... -ss 02:45:18 -to 01:45:36 ... output ffmpeg version N/A built on ... N/A
Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.