> > there are much better places for optimalization here which will
> > gain 400% speed boost in this are)
> >
> Can we try to get yuv2rgb and rescale code from mplayer ?
> Imho their code is well optimized.
Well I've had some short discussion about this with Arpi - well
he mostly hates to write code usable also by other people
(i.e. ignoring support for shared libs)
Thus once there will be enough time I'll rewrite this code to
fit my needs (the second possibility is that Arpi will do that
sooner - as usualy he initialy refuses to do it in some way - but
somehow he usualy goes this way after some time later anyway :))
> > There would be much better idea to implement the mmx pipeline -
> > In reality we actually do not need fast memcpy at all...
> >
> Yes the best idea is to have these basic functions optimized for all
> aplications (glibc :-) and put our time in more important problems.
> what do you mean mmx pipeline ? (or in which part of code ?)
Well the worst problem isn't the memcpy itself - the enemy here
is the memory bandwidth and it's very bad to process image this way:
decompress image - scale - rgb covert - rotate - blur - compress.
the best here is to program a filter (I call it mmx pipeline just
because it's supposed to use any available acceleration)
which will consume some set of line and will do operation with them
with just small chunks and will take advantage of the L2 cache.
(Of course if you have Xeon CPU you have no problems here as
1MB L2 usually solve the problems here :)
Mplayer seems went in a way to write hyper optimized version
of scaler & resizer last time I've checked it.
I'm not such a CPU freak so I will sacrifice few CPU cycles on
the call of pipelined implementation - it'll be surely slower
(so instead of 1hour movie processing it will take about 1hour and
0.1 second or so :) but I don't care about this difference)
The second problem with mplayers code is - gcc generates relatively
ugly code for some parts of Michaels code when it's compiled
in the 'shared' mode - so they will have to be rewritten as well..
Again - Arpi refuses to accept modification for this - thus I'm
left alone in this area and I'll put my hand on this when there
will be no other more important work....
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- When in doubt, just blame the Euro. :)
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
