On 8/5/2017 6:17 PM, Nicolas George wrote: > L'octidi 18 thermidor, an CCXXV, James Almer a écrit : >> Indeed, but that's something that should have been done once AVOptions >> gained the shorthand feature with the CLI, not several years down the >> line and hundreds of scripts and tutorials potentially considering it a >> fixed syntax. >> >> At this point, breaking current shorthand behavior is pretty disruptive, >> at least without some warnings and removal grace period. >> My suggestion would be to keep dummy options in a similar fashion we >> keep deprecated functions, so the shorthand notation does not start >> trying to fill values of unexpected new or moved options. Making them >> raise a warning about how it will stop working in the near future (No >> need for two years like with API, one or two releases should be enough) >> and maybe mention the new option that will be filled by the shorthand >> notation. > > That would be ideal, if we had unlimited manpower. Unfortunately, we do > not.
What do you mean? What i suggested would be done each time an option is removed or added anywhere but at the end, both of which afaik are uncommon cases. It's not something that requires a rewrite of the current codebase. > >> Is there for that matter a way to achieve this for the CLI only and not >> keeping the dummy options for library users? > > Not easily, I think. > > Regards, > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
