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

FFmpeg trac at avcodec.org
Sat Aug 23 15:44:12 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:11 cehoyos]:
 > There is nothing to understand, it is just a fact: Just run {{{ldd
 libavformat}}} on a shared library to see the dependency.
 I believe you :)
 I just don't understand the logic behind the fact that both libraries have
 a dependency on each other, since to my understanding (admittedly limited
 about FFmpeg's codebase and codecs internals), (de)muxing and
 encoding/decoding are independent operations.

 Replying to [comment:11 cehoyos]:
 > > especially since I built FFmpeg with {{{--disable-encoders --disable-
 > Meaning you cannot compare the behaviour with a build using default
 configuration (at least for some files and some command lines).
 I can if you believe this can lead to interesting results. I did add these
 switches only to speed up compilation, and because I believed they had no
 impact on the codepath I use for my use case.

 Replying to [comment:11 cehoyos]:
 > > 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
 > > The results in comment:4 that show that taking steams individually
 produce the same MD5, but taking them together does not, make me quite
 > Yes, it indicates that you refuse to believe me that testing demuxers
 without decoders has very limited use.
 What do you mean?
 I can perfectly understand that most users won't need the MD5 stuff, but
 for example remuxing streams in another file without transcoding is a
 pretty common use case, no?

 Replying to [comment:11 cehoyos]:
 > I explained several times that there are multiple reasons (or
 explanations) why the output can be different (including different FFmpeg
 Yes you gave me factors that have an influence on difference I am seeing,
 but not the root logical explanation.
 Sorry if I am insistent. Its the logic that I don't understand. I'm no
 media format expert, so I will give you a simple example of what I don't
 Let's say you write a SRT subtitle file with the characters "123" inside
 it. I know it's probably not a valid subtitle file but this is just for
 the example. You mux this in a Matroska file. So the result is a Matroska
 file with a single stream that is the SRT subtitle data. Now let's say you
 want to demux the Matroska file to get the original SRT data again.
 What I don't understand is how the demuxing operation can result in
 something else than the original SRT file with the 3 chars.
 I am probably missing something stupid, but please explain me.

 Replying to [comment:11 cehoyos]:
 > Please note that you refuse to explain your usecase.
 What do you want to know?
 I believe I did explain my use case in the beginning of comment:8.

 Replying to [comment:11 cehoyos]:
 > 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.
 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?
 Or are saying that in this example, the Matroska muxer may symetrically
 cancel some differences of the demuxer output?

 Replying to [comment:11 cehoyos]:
 > 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.
 Yes I know how git bisect works. That is what I did.
 I believe the error is due to the fact that n2.2.7 is not a direct
 ancestor of n2.3.
 I believe you should be able to reproduce the error by running:
   git bisect start
   git bisect good n2.3
   git bisect bad n2.2.7
   git bisect bad -> this command appears to succeed, but returns 3, and
 git does not select another HEAD to continue the bisect

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

More information about the FFmpeg-trac mailing list