<p>If the hashes for the decoded streams are identical, then the streams are essentially identical.</p>
<p>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.</p>

CC BY-SA 4.0
2020-12-25T04:45:21.253Z
2020-12-25T04:45:21.253Z
Gyan
<p>Say I have two files <code>A.mkv</code> and <code>B.mkv</code> 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.</p>
<p>I can extract and hash frames from the files like so:</p>
<pre class="lang-bash prettyprint-override"><code>$ 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
</code></pre>
<p>Then compare them with <code>diff</code> or <code>git diff</code> (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 <code>wc</code> and some basic arithmetic. <em>However</em>, if I now spend the time to decode these videos and get their framemd5 output, i.e.,</p>
<pre class="lang-bash prettyprint-override"><code>$ ffmpeg -i A.mkv -map 0:v -f md5 A.decoded.framemd5
$ ffmpeg -i B.mkv -map 0:v -f md5 B.decoded.framemd5
</code></pre>
<p>These logs are <em>exactly</em> the same, content wise.</p>
<p>Does this imply that visually, the two videos are the same, and that they just happen to be encoded slightly differently?</p>
<p>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.</p>
<p>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?)</p>
<p>(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).</p>
<p>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).</p>

CC BY-SA 4.0
2020-12-07T10:07:56.410Z
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
CC BY-SA 4.0
2020-12-21T00:49:43.727Z
@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
CC BY-SA 4.0
2020-12-21T04:13:30.887Z
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
CC BY-SA 4.0
2020-12-25T04:03:00.473Z
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
<ffmpeg><analysis>
Are two videos "identical" if their decoded data is the same, but not the encoded data?
13steinj
# Are two videos "identical" if their decoded data is the same, but not the encoded data?

(Asked by: username_0 on 2020-12-07)

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).

**Tags:** ffmpeg, analysis

> **Comments:**
> **username_1**: 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.  
> **username_0**: @username_1 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?  
> **username_1**: 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.  
> **username_0**: 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 @username_1  

---

## 1 answers

### Answer by username_1 on 2020-12-25. Score: 1 | Accepted answer

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.


---

