Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-15T05:42:32.493Z
Answers.LastActivityDate: 2016-07-15T05:42:32.493Z
Answers.UserDisplayName: Gyan
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T05:25:48.353Z
Comments.Text: 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/
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T06:11:58.460Z
Comments.Text: @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?
Comments.UserDisplayName: Igor Liferenko
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T06:57:40.573Z
Comments.Text: Add `-flags bitexact` and check.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T07:54:08.237Z
Comments.Text: Show the full console output.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T08:23:45.040Z
Comments.Text: Try it with the same version of ffmpeg.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T09:14:09.277Z
Comments.Text: Run the commands with `-v trace` and run the diff.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T09:38:46.110Z
Comments.Text: @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
Comments.UserDisplayName: Igor Liferenko
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T13:09:14.943Z
Comments.Text: 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`
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-15T05:37:10.660Z
Comments.Text: @Mulvya `-c:v libxvid` solved the problem - the hashsums are equal now.
Comments.UserDisplayName: Igor Liferenko
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-09-29T03:53:20.803Z
Comments.Text: Because `ffmpeg` is so complex it has achieved sentience and free will.
Comments.UserDisplayName: Chloe
Tags: <ffmpeg><slowmotion>
Title: Why ffmpeg works non-deterministically?
UserDisplayName: Igor Liferenko
ThreadText: # 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.
  
  
  ---
  
  