On Sat, Jul 26, 2014 at 09:58:16AM -0400, Ronald S. Bultje wrote: > Hi, > > > On Sat, Jul 26, 2014 at 9:34 AM, Michael Niedermayer <michae...@gmx.at> > wrote: > > > This provides a public sustainable API/ABI for DSP functions. > > Only externally used dsp functions are included. > > The structure is extensible without ABI issues compared to the > > existing dsp contexts. > > > Please don't add new shithole-for-everything structs and interfaces, we > already have enough of these. Just call it "avsimpleidctcontext" or > "avsimplefdctcontext" or something, and put just idct or just fdct in it. I > don't mind the concept of externally visible structs at all, but this seems > designed as dsputil-with-an-av-prefix and that's scary. > > Please don't reintroduce dsputil with most issues still there.
Well, what do you suggest ? for ABI/API compatibility we need AVClass + AVOptions per struct so for example (i)dct algo can be choosen by the user and future additions can be configured too in a ABI compatible way also several filters need mutiple contexts, users will probably not like having to alloc, setup, init and free multiple contexts. Also due to ABI if we want to allow the structs to be extended their size isnt known at build time and each struct will need a pointer. this may affect speed as multiple pointers might need to be kept in registers Above is why i put them all in one struct, i had hoped that by limiting them to function pointers which are actually used, it would be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
