[parsec-users] X264 is nondeterministic in terms of output size (1 thread)?

Zhunping Zhang jzz at mit.edu
Sat Jan 19 18:36:39 EST 2013


Hello,

It seems that the culprit is a function named x264_memcpy_aligned_sse2,
implemented in common/x86/mc-a.asm, that does not work on my computer. It is
supposed to be a fast memcpy but it apparently doesn't copy anything 
over. This
function is used to initialize some lookup tables named "cabac_tmp" in
encoder/rdo.c, so these uninitialized lookup tables lead to the 
nondeterminism.
The following patch (to common/x86/mc-c.c) corrects it:

--- mc-c.c	2012-12-11 09:56:49.000000000 -0500
+++ mc-c-new.c	2013-01-19 18:08:38.000000000 -0500
@@ -284,7 +284,7 @@
     if( !(cpu&X264_CPU_SSE2) )
         return;

-    pf->memcpy_aligned = x264_memcpy_aligned_sse2;
+    pf->memcpy_aligned = memcpy;
     pf->memzero_aligned = x264_memzero_aligned_sse2;
     pf->hpel_filter = x264_hpel_filter_sse2_amd;


I am not so sure why the function x264_memcpy_aligned_sse2 does not work in my
computer. Any ideas?

My computer has operating system Linux 2.6.32-5-amd64, and I compiled the code
with gcc 4.4.5 and flag -O1.

Regards,
Justin

Quoting Zhunping Zhang <jzz at MIT.EDU>:

> Hello,
>
> In my experiment, I seem to have different sizes of output from 
> different runs
> of the same x264 executable. In my executions, the deterministic flag
> (h->param.b_deterministic) is set to one and I only use one thread. I run the
> program three times to encode eledream_640x360_128.y4m, and I got 5Mb, 5.4Mb
> and 5.3Mb for output sizes.
>
> Wonder if someone know the reason and can pinpoint me to the source?
>
> I collected some further information to diagnose the problem. It seems that
> different runs encode each frame into different sizes. The following table
> shows the encoding size for the first 16 frames for three different runs.
>
> Frame_No. 1stRun_Frame_Sizes(in B) 2ndRun_Sizes 3rdRun_Sizes
> 1         73623                    73623        73623
> 2         73518                    73518      **73519**
> 3         7431                     7431         ...
> 4         7286                     7286         ...
> 5         7140                     7140         ...
> 6         6706                     6706         ...
> 7         66012                    66012        ...
> 8         38288                    38288        ...
> 9         65971                    65971        ...
> 10        34793                    34793        ...
> 11        66053                    66053        ...
> 12        66098                    66098        ...
> 13        37602                    37602        ...
> 14        39738                    39738        ...
> 15        40088                    40088        ...
> 16        66592                  **37931**      ...
>
> Any help will be appreciated!
>
> - Justin
>
>
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>



More information about the parsec-users mailing list