[FFmpeg-devel] MXF D10 regression tests

Reimar Döffinger Reimar.Doeffinger
Mon Mar 16 12:50:33 CET 2009


Hello,
As some of you may have noticed, regression tests are broken on PPC,
PPC64 and ARM, curiously in the same way on all of these, e.g.:
--- /misc/fate/beagle/source/tests/libav.regression.ref	2009-03-15 00:19:14.593308713 +0000
+++ tests/data/lavf.regression	2009-03-16 10:32:47.398450178 +0000
@@ -12,9 +12,9 @@
 259a87c8d22aab76665047ecdbfa9267 *./tests/data/b-libav.mxf
 535097 ./tests/data/b-libav.mxf
 ./tests/data/b-libav.mxf CRC=0xd7ff387d
-0a7cc51de3da754ce36dffeeda290c45 *./tests/data/b-libav.mxf_d10
+e3f2a399f03916512c92792ff58fc83b *./tests/data/b-libav.mxf_d10
 5330989 ./tests/data/b-libav.mxf_d10
-./tests/data/b-libav.mxf_d10 CRC=0xd241c8b6
+./tests/data/b-libav.mxf_d10 CRC=0x9664b562
 c0cc2ae4df6a8b3df84986929a393116 *./tests/data/b-libav.ts
 471316 ./tests/data/b-libav.ts
 ./tests/data/b-libav.ts CRC=0xcc4948e1

For some reason the MPEG-2 encoder encodes differently on those
platforms (or it gets different data).
--disable-mmx did not change the x86 result, I even set ARCH_X86 etc.
all to 0 to get a pure C version, nor could I see a change when using
--disable-altivec on PPC, nor did valgrind show any issues.
Keep in mind though that I often mess something up when doing that kind
of testing.
Since all that is a complete mystery to me I leave it to someone else to
fix it, and give you what I have so far.

The file is generated by this command:
./ffmpeg_g -y -flags +bitexact -dct fastint -idct simple -sws_flags
+accurate_rnd+bitexact -t 1 -qscale 10 -f image2 -vcodec pgmyuv -i
./tests/vsynth1/%02d.pgm -f s16le -i ./tests/asynth1.sw -ar 48000 -ac 2
-r 25 -s 720x576 -padtop 32 -vcodec mpeg2video -intra -flags
+ildct+low_delay -dc 10 -flags2 +ivlc+non_linear_q -qscale 1 -ps 1 -qmin
1 -rc_max_vbv_use 1 -rc_min_vbv_use 1 -pix_fmt yuv422p -minrate 30000k
-maxrate 30000k -b 30000k -bufsize 1200000 -top 1 -rc_init_occupancy
1200000 -qmax 12 -f mxf_d10 ././tests/data/b-libav.mxf_d10


The first difference is around offset 0x1dc, an encoded slices takes up
2 bytes more, compare these hex dumps (at 0x1d8d starts the first block
of the 3rd slice):
x86_64:
00001d80 02 30 04 04 df c3 f6 8d-1a 30 c3 0c 30 00 00 01
00001d90 03 33 7b ff 90 02 80 46-ff 40 08 1b eb 7f 20 05
00001da0 07 82 17 fa 00 40 df 00-f9 22 86 b7 d7 7e 48 a1
00001db0 ad fa 9c 00 6f 47 37 e6-5f 40 40 04 ea 50 19 f5
00001dc0 6f 52 0a 83 9b fc f5 fa-5a 3e b0 00 00 01 03 31
00001dd0 df bd be 40 0a 01 1b fd-00 20 6f 8e 02 00 15 82

ppc64:
00001d80 02 30 04 04 df c3 f6 8d-1a 30 c3 0c 30 00 00 01
00001d90 03 33 7b ff 90 02 80 46-ff 40 08 1b eb 7f 20 05
00001da0 07 82 17 fa 00 40 df 00-f9 22 86 b7 d7 7e 48 a1
00001db0 ad fa 9c 00 6f 47 37 e6-5f 40 40 04 ea 50 19 f5
00001dc0 6f d5 f3 da 51 8d fe 72-7d 9f b6 c2 d8 00 00 01
00001dd0 03 31 df bd be 40 0a 01-1b fd 00 20 6f 8e 02 00

Not that the next block of the slice starts out identical again,
but starts to differ again after 0x78 bytes, with the PPC64 version
again 2 bytes longer.
The complete files are available in incoming as b-libav_x86.mxf_d10 
and b-libav_ppc64.mxf_d10 respectively.

Greetings,
Reimar D?ffinger




More information about the ffmpeg-devel mailing list