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

FFmpeg trac at avcodec.org
Sat Aug 23 22:28:16 CEST 2014


#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:13 cehoyos]:
 > Replying to [comment:12 ahthovaikied]:
 > > So let's say I want to copy streams (without transcoding) in another
 Matroska file. That is the same command line except you replace {{{md5}}}
 by {{{matroska}}}, and stdout by a filepath. How is that different?
 >
 > It isn't, it can fail for some files depending on your configure
 options.
 >
 > Please understand that this isn't necessarily the case for your example
 in this ticket (your bisect will show once you try it as suggested below),
 I just want to explain to you that imo your whole process is flawed (at
 least with the configure line you are apparently using) because it will
 fail for some examples. And I am not convinced that a demuxers output is
 ''specifed'' the way you seem to believe it is (and the way you test it).
 I get your point of view.
 Unless you can explain me why '''demuxing''' logically depends on
 '''decoding''' (see my SRT example question above), I think there is not
 point repeating the same arguments.

 Replying to [comment:13 cehoyos]:
 > Funny that your output shows that you tried something different that
 cannot work (and this has nothing to do with FFmpeg).
 Why the sarcastic tone? Maybe you can tell me what you think I did wrong.
 I just tried on another machine and I get the same error 3.
 As you don't seem to believe me, here is the full Bash output (some parts
 are in French):
 {{{
 $ git bisect reset
 Pas de bissection en cours.
 $ git bisect start
 $ git checkout n2.3
 Note: checking out 'n2.3'.

 You are in 'detached HEAD' state. You can look around, make experimental
 changes and commit them, and you can discard any commits you make in this
 state without impacting any branches by performing another checkout.

 If you want to create a new branch to retain commits you create, you may
 do so (now or later) by using -b with the checkout command again. Example:

   git checkout -b new_branch_name

 HEAD est maintenant sur bef4d9b... RELEASE_NOTES: update
 $ git bisect good
 $ git checkout n2.2.7
 La position précédente de HEAD était bef4d9b... RELEASE_NOTES: update
 HEAD est maintenant sur 49fa398... Changelog: add entry for proresenc
 $ git bisect bad
 Bisecting: a merge base must be tested
 $ ./configure --enable-gpl \
 >               --enable-version3 \
 >               --enable-nonfree \
 >               --disable-runtime-cpudetect \
 >               --disable-ffserver \
 >               --disable-ffplay \
 >               --disable-encoders \
 >               --disable-decoders \
 >               --disable-filters \
 >               --disable-debug \
 >               --cpu=$(get_cpu_arch) &> /dev/null
 $ make -j 8 &> /dev/null
 $ ./ffmpeg -loglevel quiet -i ../ref.mkv -map a -map v -c:v copy -c:a copy
 -f md5 -
 MD5=d43af925610b84575d609dedf3954310
 $ make distclean
 $ git bisect bad
 The merge base e4a6310cce5c1663f68253c50f364fc0c055f05a is bad.
 This means the bug has been fixed between
 e4a6310cce5c1663f68253c50f364fc0c055f05a and
 [bef4d9bf87f755be62c8cc35b1c333596e41b3c6].
 $ echo $?
 3
 $ git rev-parse HEAD
 e4a6310cce5c1663f68253c50f364fc0c055f05a
 }}}
 As you can see the last command returned an error and git bisect did not
 continue (the HEAD is the same).
 I believe you can get the same behaviour if you try to do the same on your
 machine.

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


More information about the FFmpeg-trac mailing list