> I tryed it with direct rendering enabled and using memcpy optimized for
> mem2agp copy (copy blocks, aligned to cache size) and result is faster.
> But main speed problem is in decoder and because we have no source from
> windows codec we have to use alternative decoders, which are much more
> faster than windows codecs (eg. ffmpeg, divx5).
Well - could you be more specific in which are aviplay is copying memory ?
(i.e. Win codecs are decompressing directly to the specified buffer -
no memcpy - ffmpeg need stride memcpy version - which using mmx code
- and this might be improved for PIII or better CPU by prefetching data -
but I could hardly image it would gain some speed by calling general
accelerated memcpy routine.
> But if you are not able to use direct rendering, the optimized memcpy can
you should be always able to use direct mode unless you want
to rescale RGB (which is btw made in the most stupid way in avifile and
there are much better places for optimalization here which will
gain 400% speed boost in this are)
> bring small diference between 110% and 97% CPU usage.
> Not all users have CPU under 1GHz and accelerated Graphics card.
Well unlike Arpi who will spent hours with optimalizations for
Pentim S3 Trio64 users I've considered myself that I've no time
to suppert users who don't have $30 to buy even some old TNT2 card....
> (i know, that using mplayer is better. But why not add it, if we can.
> If you want i can try it and implement optimized memcpy into avifile).
There would be much better idea to implement the mmx pipeline -
In reality we actually do not need fast memcpy at all...
--
.''`. 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
