[FFmpeg-trac] #3871(avcodec:new): FFmpeg MD5 output different with same data #2

[FFmpeg]

#3871: FFmpeg MD5 output different with same data #2
--------------------------------------+-----------------------------------
             Reporter:  ahthovaikied  |                    Owner:
                 Type:  defect        |                   Status:  new
             Priority:  normal        |                Component:  avcodec
              Version:  2.2.4         |               Resolution:
             Keywords:  md5 aac h264  |               Blocked By:
             Blocking:                |  Reproduced by developer:  0
Analyzed by developer:  0             |
--------------------------------------+-----------------------------------

Comment (by ahthovaikied):

 Replying to [comment:9 cehoyos]:
 > (And please remember that in ticket #3524 we found out that you can get
 different output with identical build options and identical CPU apparently
 depending on the compiler, and that nobody so far claimed that the used
 compiler is buggy.)
 My understanding is that it was due to the use of avx instructions, and
 that in that case did change '''decoder''' output.
 I am now trying to calculate MD5 without decoding, so this is unrelated.

 Replying to [comment:9 cehoyos]:
 > Since demuxers can depend on libavcodec, one implies the other.
 I don't understand this dependency, especially since I built FFmpeg with
 {{{--disable-encoders --disable-decoders}}}.

 Replying to [comment:9 cehoyos]:
 > If you have a Matroska file for which libavformat returns broken packets
 with a default configuration, please report it here (or on the user
 mailing list).
 I am not able to characterize 'broken' here, however I know that in same
 system with different FFmpeg versions (or with version 2.2.7 on different
 CPU), the '''demuxing''' operation does not produce the same output.
 The results in comment:4 that show that taking steams individually produce
 the same MD5, but taking them together does not, make me quite suspicious.
 You seem to think this is normal, can you please explain why the
 '''demuxing''' process can produce different output with the same file?

 Replying to [comment:9 cehoyos]:
 > But I really wouldn't rely on FFmpeg internals to check for file
 validity.
 Since 'MD5' is an exposed output format, can you really consider this
 internal?

 Replying to [comment:9 cehoyos]:
 > Sorry, I expected you to write something like "yes, it works with
 version x but fails with y". Anyway, please try:
 > {{{
 > $ make distclean
 > $ git bisect reset
 > $ git bisect start
 > $ git checkout x
 > $ git bisect good
 > $ git checkout y
 > $ git bisect bad
 > }}}
 > Then build and test and depending on the result either use {{{make
 distclean && git bisect good}}} or {{{make distclean && git bisect bad}}}
 to continue testing and find the version introducing the problem you see.
 I run bisects on FFmpeg every day so I can help you if needed, but you may
 have to explain how I can reproduce the problem without using a script.
 Thanks for your help.
 I get a difference of MD5 between tag n2.2.7 and tag n2.3.
 I tried your command sequence, and I get the same error as previously:
 {{{Bisecting: a merge base must be tested}}} warning after the first
 {{{git bisect good}}}, and once I have tested the 2 "anchors", the command
 {{{git bisect bad}}} returns error code 3 and git does not change the
 current HEAD.

 To check if current HEAD is good or bad, run: {{{./ffmpeg -loglevel quiet
 -i ref.mkv -map v -map a -c:v copy -c:a copy -f md5 -}}} (ref.mkv being
 the file whose URL can be found in my first post).
 If the output is {{{MD5=db38f94668ac6f033b714877eb42e354}}}, it's "good",
 otherwise "bad".

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3871#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker