[x264-devel] commit: Spare a vec_perm and a vec_mergeh though using a LUT of permutation vectors . (Guillaume Poirier )

maaanuuu at gmx.net maaanuuu at gmx.net
Tue Feb 10 19:09:23 CET 2009


Hello,


> Hello,
>
> On Tue, Feb 10, 2009 at 4:37 PM,  <maaanuuu at gmx.net> wrote:
>> Hello,
>>
>> the output of this version differs slightly from earlier ones.
>
> How can this be? What did I miss?
>
>
>
>>> +        CV(0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,  /*
>>> pix=mod16, i_stride=mod8  */
>>> +           0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F),
>>> +    };
>>
>> isn't i_stride always mod16 now? Then the permutation vector should  
>> be
>
> What I understood is that pix was always mod16 now.
>
>
>> CV(0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
>>       0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F)
>>
>>
>>> +    vec_u8_t perm = perm_tab[ ((i_stride & 8) >> 3) ];
>>
>> I think ((i_stride & 8) >> 3) has no effect, the index depends on pix
>> being mod16 or mod8, or am I wrong?
>
> Please run some experiments and submit a patch with a test case that
> shows the problem (if you don't mind of course).

OK, I ran some encodings on small trailers.
For example, I did test encodings on a 480x260 video using the  
following commands on a ppc970 and gcc 4.2.1:
./x264 --crf 21 ../test.y4m -o test.h264
./x264 --crf 21 ../test.y4m -o ref.h264 --no-asm
cmp test.h264 ref.h264

The encoded videos aren't the same here.

I attached a patch that works and fixes that for me.


Manuel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_variance.diff
Type: application/octet-stream
Size: 837 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20090210/4917ca81/attachment.obj 
-------------- next part --------------



More information about the x264-devel mailing list