On Tuesday 16 December 2003 23:35, Richard Ellis wrote:
Hi Richard,
> In that case it will kill the majority of the performance benifit
> provided by the caches, because there's very little locality of
> reference for the cache to compensate for. It moves through at least
> 512k for pass one, then through the same 512k again for pass two, but
> the data in the cache is from the end of the frame, and we are
> starting over at the beginning of the frame. Massive cache thrash in
> that case. Memory bandwidth becomes a much more limiting factor.
Exactly what I though when I restructured encoding to a per macroblock basis a
few months back. The performance gain was.... not measurable.
They key 'thinko' here is that most of the time goes into motion estimation
and in motion estimation the search windows of neighbouring macroblocks
overlap > 90%. Cache locality is pretty good. Playing around with prefetch
(etc etc) has never brought measurable gains.
The main bottleneck in the current encoder (for modern CPUs) is the first
phase (4X4 subsampling) of the subsampling motion estimation hierarchy. For
speed this would need to be replaced with a predictive estimator.
The next bottlenecks would be the run-length coding and the use of variance
instead of SAD in motion compensation mode and DCT mode selection. Sadly
there's not too much can be done easily about the former and the latter
cannot be removed without noticeable reduction in encoding quality (I tried
it :-().
However, I have some ideas to try when I get back in the new year!
Andrew
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
