[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-
 decoders}}}.
 >
 > 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
 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.
 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
 configuration).
 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
 understand.
 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