Answers.Body: <p><em>Data errors in the compressed bit-stream, <strong>possibly</strong> due to transmission errors</em></p>
  
  <p>(emphasis mine).</p>
  
  <p>It may just be corruption in the bitstream. Another possibility is that the <a href="https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels" rel="nofollow noreferrer">level</a> flagged in the bitstream is under-specified. But that shouldn't be an issue in software playback, and it should probably occur more than once during playback, so I lean on the first candidate - corrupt bitstream.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-09T18:38:48.550Z
Answers.Text: Thanks for the answer, Gyan. Please, have a look at the question below McFlySoHigh's answer.
Answers.UserDisplayName: pmor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-27T14:31:45.947Z
Answers.LastActivityDate: 2018-08-27T14:31:45.947Z
Answers.UserDisplayName: Gyan
Answers.Body: <p>The data stream is missing sections of data. If the entire image suddenly goes highly blocky (edge to edge), that means the data loss includes the header frame of whatever structure (GOP) / codec was used to encode the file. </p>
  
  <p>If you have small horizontal chunks missing, then there was data loss after the header frame, which can't be filled in by subsequent frames thereafter- as the loss was greater than the "error correction rate" of the encoding algorithm. </p>
  
  <p>My guess is the top example is a case where the data loss included a full or partial loss of the GOP header frame, and the second example provided is one where a small packet of data was either encoded incorrectly, corrupted thereafter, or lost somehow. </p>
  
  <p>The only way to correct this is to fill in the data, which would require recovery volumes (such as PAR files), to re-encode and hope it's not on the master; or 3 paint it out frame by frame in photoshop. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-09T18:37:46.740Z
Answers.Text: Thanks for the detailed answer. In this case is there any idea of how it was possible to get the corruption in the bitstream (case when the data stream is missing sections of data)? These videos were initially downloaded via the TCP (guaranteed delivery), so no data loss was possible during the transmission. Meaning that somehow at the video producer's side during video compression something has happened, which resulted in the bitstream corruption? If so, any idea (according to the practice/experience) of what exactly could happen? Asking out of curiosity. Thanks.
Answers.UserDisplayName: pmor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-09-08T04:24:43.903Z
Answers.LastActivityDate: 2018-09-08T04:24:43.903Z
Answers.UserDisplayName: McFlySoHigh
Body: <p>During watching H.264 compressed videos one faced several times with an artifacts.</p>
  
  <p>Example 1:<a href="https://i.sstatic.net/AT7gc.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/AT7gc.png" alt="enter image description here"></a>
  Example 2:<a href="https://i.sstatic.net/R8QVP.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/R8QVP.png" alt="enter image description here"></a></p>
  
  <p>Wikipedia's article [1] tells that the typical reason is «Data errors in the compressed bit-stream, possibly due to transmission errors...». However, in case of local decoding there are no transmission errors. Then I noticed that during viewing the locally decoded video these artifacts appear at the same place in the timeline. The duration of these artifacts is about 0.5-1 seconds. These artifacts appear in the 1.5 hours video only once.</p>
  
  <p>What are the possible reasons of these artifacts?</p>
  
  <p>References:</p>
  
  <ol>
  <li><a href="https://en.wikipedia.org/wiki/Compression_artifact" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Compression_artifact</a></li>
  </ol>
  
  <p>PS. The question is also copied to dsp.stackexchange.com.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-08-28T00:51:00.080Z
Comments.Text: Please don't cross post questions.
Comments.UserDisplayName: Michael Liebman
Tags: <compression><h.264>
Title: Grime-like blocking compression artifacts on the decompressed video (H.264)
UserDisplayName: pmor
ThreadText: # Grime-like blocking compression artifacts on the decompressed video (H.264)
  
  (Asked by: username_0 on 2018-08-27)
  
  During watching H.264 compressed videos one faced several times with an artifacts.
  
  Example 1:[![enter image description here](https://i.sstatic.net/AT7gc.png)](https://i.sstatic.net/AT7gc.png)
  Example 2:[![enter image description here](https://i.sstatic.net/R8QVP.png)](https://i.sstatic.net/R8QVP.png)
  
  Wikipedia's article [1] tells that the typical reason is «Data errors in the compressed bit-stream, possibly due to transmission errors...». However, in case of local decoding there are no transmission errors. Then I noticed that during viewing the locally decoded video these artifacts appear at the same place in the timeline. The duration of these artifacts is about 0.5-1 seconds. These artifacts appear in the 1.5 hours video only once.
  
  What are the possible reasons of these artifacts?
  
  References:
  
  1. <https://en.wikipedia.org/wiki/Compression_artifact>
  
  PS. The question is also copied to dsp.stackexchange.com.
  
  **Tags:** compression, h.264
  
  > **Comments:**
  > **username_1**: Please don't cross post questions.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-08-27. Score: 1 | Accepted answer
  
  *Data errors in the compressed bit-stream, **possibly** due to transmission errors*
  
  (emphasis mine).
  
  It may just be corruption in the bitstream. Another possibility is that the [level](https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels) flagged in the bitstream is under-specified. But that shouldn't be an issue in software playback, and it should probably occur more than once during playback, so I lean on the first candidate - corrupt bitstream.
  
  > **Comments:**
  > **username_0**: Thanks for the answer, username_2. Please, have a look at the question below username_3's answer.  
  
  ---
  
  ### Answer by username_3 on 2018-09-08. Score: 1
  
  The data stream is missing sections of data. If the entire image suddenly goes highly blocky (edge to edge), that means the data loss includes the header frame of whatever structure (GOP) / codec was used to encode the file.
  
  If you have small horizontal chunks missing, then there was data loss after the header frame, which can't be filled in by subsequent frames thereafter- as the loss was greater than the "error correction rate" of the encoding algorithm.
  
  My guess is the top example is a case where the data loss included a full or partial loss of the GOP header frame, and the second example provided is one where a small packet of data was either encoded incorrectly, corrupted thereafter, or lost somehow.
  
  The only way to correct this is to fill in the data, which would require recovery volumes (such as PAR files), to re-encode and hope it's not on the master; or 3 paint it out frame by frame in photoshop.
  
  > **Comments:**
  > **username_0**: Thanks for the detailed answer. In this case is there any idea of how it was possible to get the corruption in the bitstream (case when the data stream is missing sections of data)? These videos were initially downloaded via the TCP (guaranteed delivery), so no data loss was possible during the transmission. Meaning that somehow at the video producer's side during video compression something has happened, which resulted in the bitstream corruption? If so, any idea (according to the practice/experience) of what exactly could happen? Asking out of curiosity. Thanks.  
  
  ---
  
  