[FFmpeg-devel] [PATCH] Bunch of accumulated patches...

[Sigbjørn Skjæret]

>> [..Please CC me if you want me to reply, otherwise I'll have to break the thread like now..]

*cough* -^

> true still, libavutil is not a trashcan, all functions there must be needed,
> usefull, clean, ...

Well, while we're on the whole issue of clean, I've mentioned this in
semi-private before, but it's probably worth mentioning again, the current
design of exposing global variables that contain the size of opaque structs
(like av_aes_size etc) so that the *caller* can (actually must) allocate them
is extremely unclean IMO, and there's even a potentially triggered bug because
of it in tree.c:av_tree_destroy() where it av_free()s the node (which might
have been allocated by anything, or even on stack as the docs doesn't really
tell you that it is required to use av_malloc (not to mention that this means
it already is dependent on mem-funcs, so what's the point?))...

A sane approach would be adding APIs for managing these opaque structs, but
IIRC you were against that since it would make everything depend on the
mem-funcs .. well, personally I don't think that's so bad (atleast not as bad
as it is now)...

> that said i did not say it should not be in libavutil, just that the reason
> you provide is not an argument toward it
> one would have to demonstrate that av_fast_realloc() is of practical use, 
> important, well designed, clean, ...

So you're argumenting towards the removal of this function from avcodec? ;)

>> Ok, then I'm open to suggestions, what is the best suited errorcode? EILSEQ
>> doesn't define the error any better than ENOEXEC...
> i dunno, but i wont change a bad one to another bad one and while doing so
> possibly break some applications

Ok, so would an acceptable approach be to define AVERROR_NOFMT to something
else if EILSEQ doesn't exist (then ABI is intact on systems avcodec already
builds on, and will actually build on the rest)?


- CISC