[FFmpeg-trac] #3902(undetermined:closed): FFmpeg MD5 output different with same data #3

FFmpeg trac at avcodec.org
Mon Sep 1 22:00:34 CEST 2014


#3902: FFmpeg MD5 output different with same data #3
-------------------------------------+-------------------------------------
             Reporter:               |                    Owner:
  ahthovaikied                       |                   Status:  closed
                 Type:  defect       |                Component:
             Priority:  normal       |  undetermined
              Version:  git-master   |               Resolution:  duplicate
             Keywords:  mpeg2video   |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by ahthovaikied):

 Replying to [comment:39 cehoyos]:
 > As explained in ticket #3871, the output of above command line generally
 depends on the enabled decoders. If the mpeg2video decoder gets disabled,
 the output becomes 726d4f2a3d79e000e0bbde6397311bb2 and the console output
 changes
 You did'nt explain anything, you repeated several times that this is
 expected because libavformat depends on libavcodec, or because the build
 configuration is different. This is not an explanation.
 Demuxing and decoding are different and independant things, and the former
 is supposed to be deterministic and reproducible.

 Replying to [comment:39 cehoyos]:
 > At least on all Linux systems, you can always disable the mpeg2video
 decoder with {{{--disable-decoders --disable-hwaccels}}}, '''it makes no
 difference if you specify {{{--disable-vdpau}}}, {{{--disable-vaapi}}}'''
 or {{{--disable-xvmc}}} or not. Your original configure line only
 contained {{{--disable-decoders}}} but not {{{--disable-hwaccels}}}.
 This is not what I foud out.
 On my system, builds compiled with {{{--disable-decoders --disable-
 hwaccels}}} or {{{--disable-decoders --disable-vdpau --disable-vaapi}}}
 produce 0b0257acc6662c99b71e879d27705ce9, and builds with just
 {{{--disable-decoders}}} produce 726d4f2a3d79e000e0bbde6397311bb2.
 Builds with only {{{--disable-decoders --disable-vaapi}}} or {{{--disable-
 decoders --disable-vdpau}}} both produce 726d4f2a3d79e000e0bbde6397311bb2.
 So the difference of MD5 is only present with builds with '''BOTH'''
 libvaapi and libvdpau.
 Doesn't that look weird to you?

 Replying to [comment:39 cehoyos]:
 > The md5 output changed with ac293b66 / 194be1f4 just as for ticket
 #3871.
 I did some testing, and at 8851437 (before the merge) MD5 is different
 from the reference, but always similar, with or without {{{--disable-vdpau
 --disable-vaapi}}}. At 194be1f4, the MD5 was always
 726d4f2a3d79e000e0bbde6397311bb2, at ac293b6 it started to differ with
 {{{--disable-decoders --disable-vdpau --disable-vaapi}}}.
 Given the fact that ac293b6 is supposed to be a simple merge of 194be1f4,
 don't you find that even more weird?

 Replying to [comment:39 cehoyos]:
 > On your corei7 system at least one hardware acceleration library
 including its header is present (vdpau, vaapi or xvmc) meaning the
 mpeg2video decoder was enabled because it is required by all mpegvideo
 hwaccels, on the atom system none of the hardware acceleration libraries
 is present with an appropriate header meaning the mpeg2video decoder was
 not enabled.
 Yes, that is what I found out too. Even ignoring the fact that a decoder
 is compiled despite {{{--disable-decoders}}}, it does not explain why it
 causes a different of MD5.
 There is no decoder involved in demuxing, and there is no such thing as
 hardware accelerated demuxing.
 This is only one of the things left unexplained: there is also the fact
 that the difference is there only when demuxing video '''and''' audio, and
 the 16 bytes difference among a several megabyte file.

 I'd like to understand the results I get, and for now we only know that
 builds linked with libvaapi and libvdpau produce a different MD5.
 I'm sincerely grateful for the time you have spent on this, but this is
 nowhere near a satisfying explanation of what is going on, and I don't
 think you should have closed this ticket.

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


More information about the FFmpeg-trac mailing list