#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
