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

CC BY-SA 4.0
2019-09-09T18:38:48.550Z
Thanks for the answer, Gyan. Please, have a look at the question below McFlySoHigh's answer.
pmor
CC BY-SA 4.0
2018-08-27T14:31:45.947Z
2018-08-27T14:31:45.947Z
Gyan
<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>

CC BY-SA 4.0
2019-09-09T18:37:46.740Z
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.
pmor
CC BY-SA 4.0
2018-09-08T04:24:43.903Z
2018-09-08T04:24:43.903Z
McFlySoHigh
<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>

CC BY-SA 4.0
2018-08-28T00:51:00.080Z
Please don't cross post questions.
Michael Liebman
<compression><h.264>
Grime-like blocking compression artifacts on the decompressed video (H.264)
pmor
# 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.  

---

