[FFmpeg-devel] [PATCH] swresample: allow double precision beta value for the Kaiser window
gajjanag at mit.edu
Sat Nov 7 23:42:36 CET 2015
On Sat, Nov 7, 2015 at 4:57 PM, Michael Niedermayer
<michael at 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.buitenhuis at 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
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 at ffmpeg.org
More information about the ffmpeg-devel