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

[Michael Niedermayer]

On Tue, Jan 15, 2008 at 07:02:32AM +0100, Sigbj?rn Skj?ret wrote:
> @M?ns:
> >>>> [..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

Well i would CC you if i didnt forget it every time :)
Now it happened again, i pressed r and am too lazy to go back and press
something else. After all you are also to lazy to find a way to create proper
replies. Also my MUA connects the mails based on subj if they lack the
proper headers but look like replies.


> 
> >> 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.
> 
> @Michael:
> >> 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...

Well, you might be unaware but the current tree code does avoid malloc&co
without callbacks. Only the destroy function is missing but its not needed
in the normal *malloc() free usecase. And with av_malloc() the current (old)
destroy works fine.


> 
> >> 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? ;)

maybe but i think someone should
* redo the benchmarks just to check its still worth it
* check that the growing algorithm is a good choice in terms of
  wasted memory vs. speed
* change the argument to size_t of all the *alloc() functions on the next
  verstion bump

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080115/a8cd7134/attachment.pgp>