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

Sigbjørn Skjæret cisc
Tue Jan 15 07:02:32 CET 2008

>>>> [..Please CC me if you want me to reply, otherwise I'll have to break the thread like now..]
>> *cough* -^
> If you're going to participate in discussions, I strongly advise you
> to do whatever you have to in order to create proper replies with
> references.

Sigh, why do you think I keep telling you to CC? :P

>> 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)?
> What makes you believe EILSEQ is even remotely appropriate here?
> EILSEQ is intended for things like invalid multi-byte characters, not
> random "something not found" errors.

Uhm, I already said EILSEQ is quite inappropriate, however there is no good
posix E* to match the definition of AVERROR_NOFMT, so either get rid of the
posix E*s (like already suggested), or atleast use E*s that exist everywhere.

>> 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)...
> See above
> If you have a suggestion which would be cleaner while retaining simple code,
> high speed and low memory requirements, just say it ...

Well, it's obviously not possible to avoid malloc&co without adding callbacks,
but that would rule out stuffing it to stack...

>> So you're argumenting towards the removal of this function from avcodec? ;)
> i wanted to remove it, yes
> but someone posted benchmarks showing its faster than gnu libc realloc() so i
> wont remove it

Well, if it's good enough not to get removed, and by that definition better
than av_realloc as well, does it not belong in avutil? ;)


More information about the ffmpeg-devel mailing list