0

Say I have two files A.mkv and B.mkv which are meant to be (told to me to be) the same content at the same quality. However my source tells me they suspect that there is a minor difference, but can't put their finger on it.

I can extract and hash frames from the files like so:

$ ffmpeg -i A.mkv -map 0:v -c copy -f md5 A.framemd5
$ ffmpeg -i B.mkv -map 0:v -c copy -f md5 B.framemd5

Then compare them with diff or git diff (I prefer the latter just because I know the options/defaults better) and see that there's 8798 different frames (out of roughly 230555) via wc and some basic arithmetic. However, if I now spend the time to decode these videos and get their framemd5 output, i.e.,

$ ffmpeg -i A.mkv -map 0:v -f md5 A.decoded.framemd5
$ ffmpeg -i B.mkv -map 0:v -f md5 B.decoded.framemd5

These logs are exactly the same, content wise.

Does this imply that visually, the two videos are the same, and that they just happen to be encoded slightly differently?

More interestingly; reading the original diff into a python script and determining where exactly the differences lie, 3198 of them are only off by 1 unit in the presentation timestamp, another 3198 of them are only off by 1 unit in the duration time stamp, and the remaining 2414 actually have differences in their hashes and size.

If this does not imply that visually the two videos are the same, is there any way to extract frames that I wish by their DTS/PTS and compare them using an image filter (or some filter + frame stitching method directly built in to ffmpeg?)

(Before anyone asks, the audio content, both copied and decoded, has no differences in the framemd5 logs nor the md5 hash, and as mentioned in the sample above, I'm only hashing the video stream for the purposes of this question).

Note in case it matters, because I've found conflicting reports about FFmpeg trashing HDR metadata, both files are HDR consisting of the same color space / primaries / bit depth / so on (in case this can cause the result I'm referencing above with the decoded streams).

4
  • The difference can be due to packet ordering or possibly codec configuration data attached to some packets. If the pair-wise decoded frames match, then the encodings are functionally identical.
    – Gyan
    Dec 7 '20 at 10:07
  • @Gyan is there anyway to extract the data that's different in the case of configuration data (or ordering, but I would doubt that) being the cause?
    – 13steinj
    Dec 21 '20 at 0:49
  • No, configuration data is consumed by the decoder. You would have to do a framehash compare on the raw data and then do a binary diff on the differing packets.
    – Gyan
    Dec 21 '20 at 4:13
  • Relatively unfortunate but at least it's a mystery solved. Feel free to leave your comments as a reply and I'll mark it as accepted @Gyan
    – 13steinj
    Dec 25 '20 at 4:03
1

If the hashes for the decoded streams are identical, then the streams are essentially identical.

Differences can be due to bitstream encapsulation (Annex B vs length-prefixed in case of H.264/H.265) or packet arrangement or embedded parameter sets (for configuration). As long as the bitstream is valid, these differences won't affect decoding.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.