[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