On Thu, Feb 26, 2015 at 05:04:53PM +0100, Hendrik Leppkes wrote: > On Thu, Feb 26, 2015 at 4:54 PM, Clément Bœsch <u...@pkh.me> wrote: > > On Thu, Feb 26, 2015 at 01:53:13PM +0000, Derek Buitenhuis wrote: > >> On 2/26/2015 1:50 PM, Clément Bœsch wrote: > >> > If the option is set by default, you don't want to warn for no reason. > >> > >> It's not set by default. That patch never went in. > >> > > > > Ah, my bad. > > > >> I don't believe silently not writing it is a valid approach. Then > >> again I think setting a default movflag like that instead of > >> changing the option is also stupid. > > > > Well, breaking API on purpose when easily avoidable is kind of stupid too. > > > > You can also just deprecate the current flag and add yours. The point is > > to not make the option disappear because it will break callers. Changing > > the behaviour (enabling by default / making the old option void) is fine, > > breaking the API (removing the option) not so much. > > > > Its an AVOption, isn't the whole point of this system to have a system > that wouldn't break callers when an option is added or removed? > How would a caller break? Calling a set operation on a non-existing > option won't "break", just return an error code.
Yes, it will return an error and abort the operation. Be it done on the command line or via the API. So said differently it won't work anymore. -- Clément B.
pgpC5H_To78HW.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
