Opened 14 months ago
Last modified 13 months ago
#11626 new enhancement
More lenience on unrecognized options for better general-interop?
| Reported by: | gamer191 | Owned by: | |
|---|---|---|---|
| Priority: | minor | Component: | ffmpeg |
| Version: | unspecified | Keywords: | |
| Cc: | gamer191, MasterQuestionable | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | yes |
Description
This would prevent the “Unrecognized option” error showing up when an unrecognized option is passed to FFmpeg. The main usecase is so that programs and scripts which use FFmpeg can add new options whilst maintaining compatibility with older versions of FFmpeg
(Obviously this would only work for versions released after it gets implemented, hence it won’t be particularly useful until a few versions later)
Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.
Change History (2)
comment:1 by , 14 months ago
| Summary: | Feature request: -ignore-unrecognized-option → Feature request: -ignore_unrecognized_option |
|---|
comment:2 by , 13 months ago
| Analyzed by developer: | set |
|---|---|
| Cc: | added |
| Summary: | Feature request: -ignore_unrecognized_option → More lenience on unrecognized options for better general-interop? |
Note:
See TracTickets
for help on using tickets.
͏ Maybe better to make unrecognized options warnings non-critical instead?
͏ But 1 practical issue:
͏ How to determine the option parameter acceptance, for those unknown?
͏ E.g. https://trac.ffmpeg.org/ticket/11582#comment:1
͏ .
͏ The option may consume further parameters or not.
͏ There seems to be no reliable way to perfectly predict.
͏ Unwieldy handling tends to introduce still error:
͏ But with less straight-forward (maybe cryptic) messages instead.