[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