[FFmpeg-devel] [PATCH] install aes.h, des.h and rc4.h

Reimar Döffinger Reimar.Doeffinger
Sun Feb 8 01:00:13 CET 2009


On Sun, Feb 08, 2009 at 01:20:05AM +0100, Michael Niedermayer wrote:
> On Sat, Feb 07, 2009 at 02:07:36PM +0100, Reimar D?ffinger wrote:
> > Well, I'd happily take a pretty solution if you can offer one.
> 
> > But making the AES API public while the only way to use it is a way you
> > wouldn't accept in libavformat seems pointless to me.
> > I don't care, I wasn't the one who requested to move everything to a
> > public API.
> 
> i really dont see the problem, malloc() can be used to allocate a struct,

You objected to the patch that used av_malloc, so obviously it is not
quite as simple.

> alloca() can as well

alloca is not portable

> so can a uint64_t array.

and all of these do not allow to use SSE or similar in future
implementations. Not that I have any plans, but you seemed to consider
simplifying future improvements important enough to prefer an
inconvenient API over having to bump the major version.
I very much understand your concerns, but for my taste they feel a bit
much like "keeping it extensible for the sake of it", or short
"overengineered".
Overall I don't mind trusting your estimation that it is a bad idea though,
I just don't consider it sensible to continue the efforts to create a public
API.

> I honestly dont see how your custom macro would be better, it requires the
> reader to search for the code of the macro to understand it ...

Well, I generally consider working and useful code a good thing.
Wanting an public API but only variants that wouldn't be accepted in
libav* seems rather hypocritical to me (or IOW I'll object to a public
API that is not the same for AES, DES and RC4 and good enough to be used
in asfcrypt.c and mxfdec.c).
Not that I see any hurry, we can just let this rest until someone comes
up with some better idea.




More information about the ffmpeg-devel mailing list