[FFmpeg-devel] [PATCH] Faster CABAC H.264 residual decoding

[Guillaume POIRIER]

Hello,

On Sun, May 4, 2008 at 5:46 PM, Alexander Strange <astrange at ithinksw.com> wrote:
>
>  On May 4, 2008, at 3:07 AM, Guillaume POIRIER wrote:

>  > I can test on PPC970 to have an idea of how this new code behaves on a
>  > RISC machine.
>  >
>  >> I'll apply it tomorrow
>  >> unless someone thinks it's still worse on Athlon.
>  >
>  > Well, I guess it's better to measure speed on Athlon rather than
>  > making a wild guess ;-)
>
>  Yeah, if I had one. The asm is a lot shorter with this version,
>  though, so I really hope it's not slower.

On a PPC970, the new code is 0.12% faster on my sample (a 1100.0 kbps
672x560 video). It's really not much, but at least, it doesn't slow
down decoding, which is all I ask when a change is done on a codec I
use regularly.


>
>  If it is, then:
>  uint8_t *ctx = (abslevelgt1 != 0 ? 0 : abslevel1) +
>
> abs_level_m1_ctx_base;
>  ...
>  abslevel1 = FFMIN( 4, abslevel1+1 );
>  ..
>  ctx = 5 + abslevelgt1 + abs_level_m1_ctx_base;
>  abslevelgt1 = FFMIN( 4, abslevelgt1+1 );
>
>  should also be better than the current code on x86, but it's not
>  really better on PPC where you don't have cmov.

While trying to write an smart reply to your mail, I asked Google what
it knew about PPC and predicates (I vaguely remembered that PPC had
some support for writing assmebly with predicates).
The best source I found was this piece: http://www.warthman.com/ex-CWG.htm

I'm sorry to see that this time around both x86 and Itanium has a much
more useful instructions to optimize the code snippets you pasted.

:-(

Guillaume
-- 
I don't measure a man's success by how high he climbs but how high he
bounces when he hits bottom.
 -- George S. Patton