[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:15 cehoyos]:
 > Please read my comment:11 again, you are trying the opposite of what I
 suggested there.
 Sorry, I get it now: good revisions should be marked as "bad".
 Thanks for your help :)

 So I ran a git bisect with my script, here is the bisect log:
 {{{
 git bisect start
 # bad: [bef4d9bf87f755be62c8cc35b1c333596e41b3c6] RELEASE_NOTES: update
 git bisect bad bef4d9bf87f755be62c8cc35b1c333596e41b3c6
 # good: [49fa398858df1a1e425740672de5fb4819b4d947] Changelog: add entry
 for proresenc
 git bisect good 49fa398858df1a1e425740672de5fb4819b4d947
 # good: [e4a6310cce5c1663f68253c50f364fc0c055f05a] update for 2.2
 git bisect good e4a6310cce5c1663f68253c50f364fc0c055f05a
 # good: [8522dd380b2a0f98cfaafcf0ae64bd46ac031ae1] Merge commit
 'c7603b3c243331057300337a61464e6ac4a605cb'
 git bisect good 8522dd380b2a0f98cfaafcf0ae64bd46ac031ae1
 # good: [da53de07306a301830b234a38bc103c6af9ded7c] tests: add adpcm
 trellis tests
 git bisect good da53de07306a301830b234a38bc103c6af9ded7c
 # bad: [a9f7972844b70c8e94520f52080884bb1507171f] Merge commit
 '1b04eb20f7e3f0a71f73ba91efcc3d60a435e443'
 git bisect bad a9f7972844b70c8e94520f52080884bb1507171f
 # good: [9025072e6c25ffd4507f0268b53743f9c4d52cd6] avcodec/h264_slice:
 support skipping loop filtering for non key frames
 git bisect good 9025072e6c25ffd4507f0268b53743f9c4d52cd6
 # bad: [e3fd263f0b73e4425192d6dd1ab18027ecaa35db] Show duration for large
 asf files as written in the file header.
 git bisect bad e3fd263f0b73e4425192d6dd1ab18027ecaa35db
 # bad: [1ebc77bc7d68748598878c08c85a571b526a729f] Merge commit
 '49a242687cf44f86570b706db3c5912ff06bc6c2'
 git bisect bad 1ebc77bc7d68748598878c08c85a571b526a729f
 # good: [0608bc65025a29b2ec56aa17dd76d76ed730be11]
 swresample/audioconvert: fix () in FMT_PAIR_FUNC()
 git bisect good 0608bc65025a29b2ec56aa17dd76d76ed730be11
 # good: [bd148ce07de08dcd03178e869bacf1e1ef6358df] Merge commit
 'cfbdd7ffbd9fe14d110fd1bb89bf52f0f7bde016'
 git bisect good bd148ce07de08dcd03178e869bacf1e1ef6358df
 # good: [88514378bac99872265dad28072fb30160b26bfa] avcodec/ass: move
 playres parameters below scripttype
 git bisect good 88514378bac99872265dad28072fb30160b26bfa
 # bad: [1d54f5108477938268d51162be536cecd746e56a] avformat/mux: simplify
 ff_choose_timebase()
 git bisect bad 1d54f5108477938268d51162be536cecd746e56a
 # bad: [ac293b66851f6c4461eab03ca91af59d5ee4e02e] Merge commit
 '194be1f43ea391eb986732707435176e579265aa'
 git bisect bad ac293b66851f6c4461eab03ca91af59d5ee4e02e
 # bad: [194be1f43ea391eb986732707435176e579265aa] lavf: switch to
 AVStream.time_base as the hint for the muxer timebase
 git bisect bad 194be1f43ea391eb986732707435176e579265aa
 # first bad commit: [194be1f43ea391eb986732707435176e579265aa] lavf:
 switch to AVStream.time_base as the hint for the muxer timebase
 }}}


 The commit that introduced the change is this one:
 {{{
 commit 194be1f43ea391eb986732707435176e579265aa
 Author: Anton Khirnov <anton at khirnov.net>
 Date:   Sun May 18 12:12:59 2014 +0200

     lavf: switch to AVStream.time_base as the hint for the muxer timebase

     Previously, AVStream.codec.time_base was used for that purpose, which
     was quite confusing for the callers. This change also opens the path
 for
     removing AVStream.codec.

     The change in the lavf-mkv test is due to the native timebase (1/1000)
     being used instead of the default one (1/90000), so the packets are
 now
     sent to the crc muxer in the same order in which they are demuxed
     (previously some of them got reordered because of inexact timestamp
     conversion).
 }}}

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