[FFmpeg-devel] [PATCH] avoid mb_xy recalculation in h264

Michael Niedermayer michaelni
Wed May 7 21:15:34 CEST 2008


On Wed, May 07, 2008 at 02:49:20PM -0400, Alexander Strange wrote:
>
> On May 7, 2008, at 8:53 AM, Michael Niedermayer wrote:
>
>> On Wed, May 07, 2008 at 03:05:47AM -0400, Alexander Strange wrote:
>>> This line appears in a lot of h264.c functions:
>>> const int mb_xy= s->mb_x + s->mb_y*s->mb_stride;
>>>
>>> It only changes once per MB, so we can add it to the context and only
>>> recalculate it in decode_slice().
>>> I put it at the end of H264Context, but it could be moved up earlier if
>>> someone likes it there. The position doesn't seem to affect performance
>>> much; it can't be moved next to mb_x/mb_y since that would put it in
>>> MpegEncContext, and none of the other codecs use it.
>>>
>>> Patches:
>>> 1- does that, updating it for MBAFF when needed
>>> 2- removes some newly unused variables
>>> 3- does the same thing to svq3.c
>>>
>>> Before: avg 8.799s max 8.8s min 8.794s
>>> After: avg 8.645s max 8.651s min 8.641s
>>
>> Knowing the cpu and compiler would also be usefull.
>
> gcc 4.0.1, core 2 x86-32 Darwin
>
> I guess it's about the same as the usual distro compiler, but this isn't 
> really a sensitive messing-with-the-register-allocator patch.

How does the change compare to a splited (litterally duplicated)
decode_cabac_residual()
with the mb_xy only calculated for the "cat"s which actually need it?
That is one for cat=0/3 and one for the others
or
with the mb_xy calc moved in the if(cat=0/3) which use it?

Iam not at all against putting mb_xy in the context but i somehow doubt
that this is what causes the speed difference.

Also it would be very nice if you had a few more compilers installed
if you want to do more optimizations & benchmarks.

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20080507/4f3fcab1/attachment.pgp>



More information about the ffmpeg-devel mailing list