[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 cehoyos):

 Replying to [comment:10 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

 Neither jamal nor I were able to reproduce an issue with avx so I would
 say this is an impossible explanation.

 > Replying to [comment:9 cehoyos]:
 > > Since demuxers can depend on libavcodec, one implies the other.
 > I don't understand this dependency

 There is nothing to understand, it is just a fact: Just run {{{ldd
 libavformat}}} on a shared library to see the dependency.

 > especially since I built FFmpeg with {{{--disable-encoders --disable-
 decoders}}}.

 Meaning you cannot compare the behaviour with a build using default
 configuration (at least for some files and some command lines).

 > 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.

 Yes, it indicates that you refuse to believe me that testing demuxers
 without decoders has very limited use.

 > You seem to think this is normal, can you please explain why the
 '''demuxing''' process can produce different output with the same file?

 I explained several times that there are multiple reasons (or
 explanations) why the output can be different (including different FFmpeg
 configuration). Please note that you refuse to explain your usecase.

 > 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?

 Nothing about the md5 output format is internal. Testing demuxer output
 means imo that you rely on FFmpeg internals that may change, be it because
 of a bugfix or because the behaviour of the demuxer changes.

 > 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.

 Since 2.3 is "newer" than n2.2.7 you did mark n2.3 (and all revisions that
 behave the same) as {{{bad}}} and n2.2.7 (and all revisions with the same
 output) as {{{good}}}? This is the only way {{{git bisect}}} works and it
 will show you the commit that introduces the change.

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