[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