Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-25T04:45:21.253Z
Answers.LastActivityDate: 2020-12-25T04:45:21.253Z
Answers.UserDisplayName: Gyan
Body: <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>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-07T10:07:56.410Z
Comments.Text: 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.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-21T00:49:43.727Z
Comments.Text: @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?
Comments.UserDisplayName: 13steinj
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-21T04:13:30.887Z
Comments.Text: 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.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-25T04:03:00.473Z
Comments.Text: 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
Comments.UserDisplayName: 13steinj
Tags: <ffmpeg><analysis>
Title: Are two videos "identical" if their decoded data is the same, but not the encoded data?
UserDisplayName: 13steinj
ThreadText: # 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:
  
  ```bash
  $ 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.,
  
  ```bash
  $ 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.
  
  
  ---
  
  