<p>Based on all info, it looks like the difference occurs with FFmpeg's internal MPEG-4 part 2 encoder, whose use can be identified by the string <code>mpeg4 (native)</code> after the 2nd arrow in  <code>Stream #0:0 -&gt; #0:0 (mpeg4 (native) -&gt; mpeg4 (native))</code>. If you use <code>libxvid</code> which is a third-party MPEG-4 part 2 encoder, the error does not occur.</p>

<hr>

<p>My <em>guess</em> is that the behaviour of the internal mpeg4 encoder is related to the possible differences in supplementary instruction sets present between the two machines i.e. MMX, SSE<em>n</em>. Someone with the technical knowledge, please feel free to chime in.</p>

CC BY-SA 3.0
2016-07-15T05:42:32.493Z
2016-07-15T05:42:32.493Z
Gyan
<p>I take a file and make the video slower by using one and the same command two times:</p>

<pre><code>ffmpeg -nostdin -i test.avi -filter:v "setpts=2.0*PTS" -vtag xvid -an slow1.avi
ffmpeg -nostdin -i test.avi -filter:v "setpts=2.0*PTS" -vtag xvid -an slow2.avi
</code></pre>

<p>But <code>slow1.avi</code> and <code>slow2.avi</code> are different.</p>

<p>First check by comparing <code>md5sum</code> and filesize:</p>

<pre><code>1ceef0b7c6b498399e7ee4ff3ce99427  slow1.avi
cc844d77193e2ad37dc1e06d6cac5166  slow2.avi
-rw-r--r-- 1 user user 66606564 Jul 14 09:28 slow1.avi
-rw-r--r-- 1 user user 66867612 Jul 14 09:28 slow2.avi
</code></pre>

<p>Then check by comparing terminal output:</p>

<pre><code>@@ -16,7 +16,7 @@
   Duration: 00:21:52.21, start: 0.000000, bitrate: 344 kb/s
     Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 614x480 [SAR 1:1 DAR 307:240], 203 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
     Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16p, 128 kb/s
-Output #0, avi, to 'slow1.avi':
+Output #0, avi, to 'slow2.avi':
   Metadata:
     ISFT            : Lavf57.25.100
     Stream #0:0: Video: mpeg4 (xvid / 0x64697678), yuv420p, 614x480 [SAR 1:1 DAR 307:240], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
@@ -26,5 +26,5 @@
       unknown side data type 10 (24 bytes)
 Stream mapping:
   Stream #0:0 -&gt; #0:0 (mpeg4 (native) -&gt; mpeg4 (native))
-frame=32804 fps=459 q=2.0 Lsize=   65045kB time=00:43:44.36 bitrate= 203.0kbits/s speed=36.8x    
-video:63486kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.456314%
+frame=32804 fps=438 q=2.0 Lsize=   65300kB time=00:43:44.36 bitrate= 203.8kbits/s speed=  35x
+video:63741kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.446085%
</code></pre>

<p>ffmpeg gives this non-determinism with any file, for example try with:</p>

<pre><code>/usr/local/bin/youtube-dl --recode-video avi -o 'test.%(ext)s' tPEE9ZwTmy0
</code></pre>

<p>Why the same processing of a file by ffmpeg is non-deterministic? Does this influence how this file is actually reproduced by movie player?</p>

<p><strong>EDIT</strong></p>

<p>If we add <code>-flags bitexact</code> before <code>-filter:v</code>, the results differ anyway.</p>

<p>This is the full output on machine A:</p>

<pre><code>user@debian:~/Downloads$ md5sum test.avi 
621ebcd080da91817bb47a93e877cd6e  test.avi
user@debian:~/Downloads$ ./ffmpeg-git-20160714-64bit-static/ffmpeg -nostdin -i test.avi -flags bitexact -filter:v "setpts=2.0*PTS" -vtag xvid -an slow1.avi
ffmpeg version N-80999-gf41e37b-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (Debian 5.4.0-6) 20160609
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --enable-frei0r --enable-libfribidi --disable-indev=sndio --disable-outdev=sndio --enable-librtmp --enable-libmfx --enable-libzimg --cc=gcc
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 50.100 / 57. 50.100
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, avi, from 'test.avi':
  Metadata:
    encoder         : Lavf57.25.100
  Duration: 00:00:01.04, start: 0.000000, bitrate: 777 kb/s
    Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 854x470 [SAR 1:1 DAR 427:235], 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16p, 128 kb/s
[avi @ 0x51c4680] Setting the AVFormatContext to bitexact mode, because the AVCodecContext is in that mode. This behavior will change in the future. To keep the current behavior, set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.
[avi @ 0x51c4680] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, avi, to 'slow1.avi':
    Stream #0:0: Video: mpeg4 (xvid / 0x64697678), yuv420p, 854x470 [SAR 1:1 DAR 427:235], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
Stream mapping:
  Stream #0:0 -&gt; #0:0 (mpeg4 (native) -&gt; mpeg4 (native))
frame=   27 fps=0.0 q=13.4 Lsize=      99kB time=00:00:01.83 bitrate= 444.1kbits/s speed=15.7x    
video:93kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 7.451477%
user@debian:~/Downloads$ md5sum slow1.avi 
653f2bf66a01b67911b5bd61a4e197e0  slow1.avi
</code></pre>

<p>This is the full output on machine B:</p>

<pre><code>user@debian:~/Downloads$ md5sum test.avi 
621ebcd080da91817bb47a93e877cd6e  test.avi
user@debian:~/Downloads$ ./ffmpeg-git-20160714-64bit-static/ffmpeg -nostdin -i test.avi -flags bitexact -filter:v "setpts=2.0*PTS" -vtag xvid -an slow2.avi
ffmpeg version N-80999-gf41e37b-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (Debian 5.4.0-6) 20160609
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --enable-frei0r --enable-libfribidi --disable-indev=sndio --disable-outdev=sndio --enable-librtmp --enable-libmfx --enable-libzimg --cc=gcc
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 50.100 / 57. 50.100
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, avi, from 'test.avi':
  Metadata:
    encoder         : Lavf57.25.100
  Duration: 00:00:01.04, start: 0.000000, bitrate: 777 kb/s
    Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 854x470 [SAR 1:1 DAR 427:235], 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16p, 128 kb/s
[avi @ 0x468f680] Setting the AVFormatContext to bitexact mode, because the AVCodecContext is in that mode. This behavior will change in the future. To keep the current behavior, set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.
[avi @ 0x468f680] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, avi, to 'slow2.avi':
    Stream #0:0: Video: mpeg4 (xvid / 0x64697678), yuv420p, 854x470 [SAR 1:1 DAR 427:235], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
Stream mapping:
  Stream #0:0 -&gt; #0:0 (mpeg4 (native) -&gt; mpeg4 (native))
frame=   27 fps=0.0 q=14.8 Lsize=     102kB time=00:00:01.83 bitrate= 456.8kbits/s speed=17.9x    
video:95kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 7.225229%
user@debian:~/Downloads$ md5sum slow2.avi 
9e6eed35b37a05c62141adefd249751f  slow2.avi
</code></pre>

CC BY-SA 3.0
2016-07-14T05:25:48.353Z
All I can say is upgrade. I performed a test using your command 4 times and I got identical output. Try the binaries at http://johnvansickle.com/ffmpeg/
Gyan
CC BY-SA 3.0
2016-07-14T06:11:58.460Z
@Mulvya With version N-80953-gd4c8e93-static the results are the same on one computer, but if the same file is processed with equal ffmpeg version on different computers (both 64bit), the result differs anyway, as described. Anyway, what may be the cause of the diff of terminal output shown in the question?
Igor Liferenko
CC BY-SA 3.0
2016-07-14T06:57:40.573Z
Add `-flags bitexact` and check.
Gyan
CC BY-SA 3.0
2016-07-14T07:54:08.237Z
Show the full console output.
Gyan
CC BY-SA 3.0
2016-07-14T08:23:45.040Z
Try it with the same version of ffmpeg.
Gyan
CC BY-SA 3.0
2016-07-14T09:14:09.277Z
Run the commands with `-v trace` and run the diff.
Gyan
CC BY-SA 3.0
2016-07-14T09:38:46.110Z
@Mulvya this is the diff http://pastebin.com/fk2wNWQ7, this is full log from A http://pastebin.com/LVJJ1kKv, this is full log from B http://pastebin.com/0hVByQtE
Igor Liferenko
CC BY-SA 3.0
2016-07-14T13:09:14.943Z
I see no significant difference in the readouts. This may have to do with the native mpeg4 encoder. Try with `-c:v libxvid` or `-c:v libx264`
Gyan
CC BY-SA 3.0
2016-07-15T05:37:10.660Z
@Mulvya `-c:v libxvid` solved the problem - the hashsums are equal now.
Igor Liferenko
CC BY-SA 4.0
2018-09-29T03:53:20.803Z
Because `ffmpeg` is so complex it has achieved sentience and free will.
Chloe
<ffmpeg><slowmotion>
Why ffmpeg works non-deterministically?
Igor Liferenko
# Why ffmpeg works non-deterministically?

(Asked by: username_0 on 2016-07-14)

I take a file and make the video slower by using one and the same command two times:
ffmpeg -nostdin -i test.avi -filter:v "setpts=2.0*PTS" -vtag xvid -an slow1.avi
ffmpeg -nostdin -i test.avi -filter:v "setpts=2.0*PTS" -vtag xvid -an slow2.avi

But slow1.avi and slow2.avi are different.
First check by comparing md5sum and filesize:
1ceef0b7c6b498399e7ee4ff3ce99427  slow1.avi
cc844d77193e2ad37dc1e06d6cac5166  slow2.avi
-rw-r--r-- 1 user user 66606564 Jul 14 09:28 slow1.avi
-rw-r--r-- 1 user user 66867612 Jul 14 09:28 slow2.avi

Then check by comparing terminal output:
@@ -16,7 +16,7 @@
   Duration: 00:21:52.21, start: 0.000000, bitrate: 344 kb/s
     Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 614x480 [SAR 1:1 DAR 307:240], 203 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
     Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16p, 128 kb/s
-Output #0, avi, to 'slow1.avi':
+Output #0, avi, to 'slow2.avi':
   Metadata:
     ISFT            : Lavf57.25.100
     Stream #0:0: Video: mpeg4 (xvid / 0x64697678), yuv420p, 614x480 [SAR 1:1 DAR 307:240], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
@@ -26,5 +26,5 @@
       unknown side data type 10 (24 bytes)
 Stream mapping:
   Stream #0:0 -> #0:0 (mpeg4 (native) -> mpeg4 (native))
-frame=32804 fps=459 q=2.0 Lsize=   65045kB time=00:43:44.36 bitrate= 203.0kbits/s speed=36.8x    
-video:63486kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.456314%
+frame=32804 fps=438 q=2.0 Lsize=   65300kB time=00:43:44.36 bitrate= 203.8kbits/s speed=  35x
+video:63741kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.446085%

ffmpeg gives this non-determinism with any file, for example try with:
/usr/local/bin/youtube-dl --recode-video avi -o 'test.%(ext)s' tPEE9ZwTmy0

Why the same processing of a file by ffmpeg is non-deterministic? Does this influence how this file is actually reproduced by movie player?
EDIT
If we add -flags bitexact before -filter:v, the results differ anyway.
This is the full output on machine A:
user@debian:~/Downloads$ md5sum test.avi 
621ebcd080da91817bb47a93e877cd6e  test.avi
user@debian:~/Downloads$ ./ffmpeg-git-20160714-64bit-static/ffmpeg -nostdin -i test.avi -flags bitexact -filter:v "setpts=2.0*PTS" -vtag xvid -an slow1.avi
ffmpeg version N-80999-gf41e37b-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (Debian 5.4.0-6) 20160609
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --enable-frei0r --enable-libfribidi --disable-indev=sndio --disable-outdev=sndio --enable-librtmp --enable-libmfx --enable-libzimg --cc=gcc
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 50.100 / 57. 50.100
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, avi, from 'test.avi':
  Metadata:
    encoder         : Lavf57.25.100
  Duration: 00:00:01.04, start: 0.000000, bitrate: 777 kb/s
    Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 854x470 [SAR 1:1 DAR 427:235], 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16p, 128 kb/s
[avi @ 0x51c4680] Setting the AVFormatContext to bitexact mode, because the AVCodecContext is in that mode. This behavior will change in the future. To keep the current behavior, set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.
[avi @ 0x51c4680] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, avi, to 'slow1.avi':
    Stream #0:0: Video: mpeg4 (xvid / 0x64697678), yuv420p, 854x470 [SAR 1:1 DAR 427:235], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg4 (native) -> mpeg4 (native))
frame=   27 fps=0.0 q=13.4 Lsize=      99kB time=00:00:01.83 bitrate= 444.1kbits/s speed=15.7x    
video:93kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 7.451477%
user@debian:~/Downloads$ md5sum slow1.avi 
653f2bf66a01b67911b5bd61a4e197e0  slow1.avi

This is the full output on machine B:
user@debian:~/Downloads$ md5sum test.avi 
621ebcd080da91817bb47a93e877cd6e  test.avi
user@debian:~/Downloads$ ./ffmpeg-git-20160714-64bit-static/ffmpeg -nostdin -i test.avi -flags bitexact -filter:v "setpts=2.0*PTS" -vtag xvid -an slow2.avi
ffmpeg version N-80999-gf41e37b-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (Debian 5.4.0-6) 20160609
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --enable-frei0r --enable-libfribidi --disable-indev=sndio --disable-outdev=sndio --enable-librtmp --enable-libmfx --enable-libzimg --cc=gcc
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 50.100 / 57. 50.100
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, avi, from 'test.avi':
  Metadata:
    encoder         : Lavf57.25.100
  Duration: 00:00:01.04, start: 0.000000, bitrate: 777 kb/s
    Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 854x470 [SAR 1:1 DAR 427:235], 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16p, 128 kb/s
[avi @ 0x468f680] Setting the AVFormatContext to bitexact mode, because the AVCodecContext is in that mode. This behavior will change in the future. To keep the current behavior, set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.
[avi @ 0x468f680] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, avi, to 'slow2.avi':
    Stream #0:0: Video: mpeg4 (xvid / 0x64697678), yuv420p, 854x470 [SAR 1:1 DAR 427:235], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg4 (native) -> mpeg4 (native))
frame=   27 fps=0.0 q=14.8 Lsize=     102kB time=00:00:01.83 bitrate= 456.8kbits/s speed=17.9x    
video:95kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 7.225229%
user@debian:~/Downloads$ md5sum slow2.avi 
9e6eed35b37a05c62141adefd249751f  slow2.avi

**Tags:** ffmpeg, slowmotion

> **Comments:**
> **username_1**: All I can say is upgrade. I performed a test using your command 4 times and I got identical output. Try the binaries at http://johnvansickle.com/ffmpeg/  
> **username_0**: @Mulvya With version N-80953-gd4c8e93-static the results are the same on one computer, but if the same file is processed with equal ffmpeg version on different computers (both 64bit), the result differs anyway, as described. Anyway, what may be the cause of the diff of terminal output shown in the question?  
> **username_1**: Add `-flags bitexact` and check.  
> **username_1**: Show the full console output.  
> **username_1**: Try it with the same version of ffmpeg.  
> **username_1**: Run the commands with `-v trace` and run the diff.  
> **username_0**: @Mulvya this is the diff http://pastebin.com/fk2wNWQ7, this is full log from A http://pastebin.com/LVJJ1kKv, this is full log from B http://pastebin.com/0hVByQtE  
> **username_1**: I see no significant difference in the readouts. This may have to do with the native mpeg4 encoder. Try with `-c:v libxvid` or `-c:v libx264`  
> **username_0**: @Mulvya `-c:v libxvid` solved the problem - the hashsums are equal now.  
> **username_2**: Because `ffmpeg` is so complex it has achieved sentience and free will.  

---

## 1 answers

### Answer by username_1 on 2016-07-15. Score: 3 | Accepted answer

Based on all info, it looks like the difference occurs with FFmpeg's internal MPEG-4 part 2 encoder, whose use can be identified by the string `mpeg4 (native)` after the 2nd arrow in `Stream #0:0 -> #0:0 (mpeg4 (native) -> mpeg4 (native))`. If you use `libxvid` which is a third-party MPEG-4 part 2 encoder, the error does not occur.

---

My *guess* is that the behaviour of the internal mpeg4 encoder is related to the possible differences in supplementary instruction sets present between the two machines i.e. MMX, SSE*n*. Someone with the technical knowledge, please feel free to chime in.


---

