On Sat, Nov 7, 2015 at 4:57 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Sat, Nov 07, 2015 at 10:49:42PM +0100, wm4 wrote: >> On Sat, 7 Nov 2015 20:00:50 +0000 >> Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: >> >> > On 11/7/2015 7:35 PM, Paul B Mahol wrote: >> > > AFAIK changing option from int to double will break programs which >> > > assume opttions is int. >> > >> > Not really sure how it could. The original range allowed was [2,16], >> > and using any of the av_opt_set functions should still work with that, >> > no? >> >> A program could use av_opt_find() and then compute the pointer to the >> option and set it manually. >> >> Is this valid API usage? Well, can you really tell? Or anyone? I've >> certainly seen at least one program do this with another option. > > its certainly valid API usage to scan the options and extract the > types. But IMO the types are not part of the ABI/API, an application > doing that should be able to handle cases where the type changed > AVOptions would be less usefull if types (and offsets) could not > change
This is what I felt - it is an internal struct, and there are explicit comments in the header saying that the struct's fields are meant to be manipulated via the options API unlike e.g libavcodec. The types were IMHO not part of the ABI/API since the struct was marked opaque. Anyway, this was my reasoning while submitting the patch. > And yes we probably should document this if all agree that this is > how it should work > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No great genius has ever existed without some touch of madness. -- Aristotle > > _______________________________________________ > 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
