user23040: During watching H.264 compressed videos one faced several times with an artifacts.
Example 1:
Example 2:
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:

https://en.wikipedia.org/wiki/Compression_artifact

PS. The question is also copied to dsp.stackexchange.com.

user1871: 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 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.

user14504: 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. 

23040: <p>During watching H.264 compressed videos one faced several times with an artifacts.</p>

<p>Example 1:<a href="https://i.stack.imgur.com/AT7gc.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/AT7gc.png" alt="enter image description here"></a>
Example 2:<a href="https://i.stack.imgur.com/R8QVP.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/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>
 1871: <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>
 14504: <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>
