Strange artifcats after container swap

[FLX90]

Hello,

What causes these strange artifcats for one frame after simple container swap from MKV to MP4 with ffmpeg (-c:v copy).
They appear random and I cannot reproduce them.

I first thought that it could've something to do with CPU or SSD peaks produced by other processes during converting.
But I did some stability tests with CPU, RAM and SSD without any errors/problems.

Frame 76 in this sample is defect.
Sample-Video (https://www.swisstransfer.com/d/752df7b1-5b41-4810-b158-7939aa066aca)
Defect frame (https://i.imgur.com/ahcmbVW.jpeg)

[FLX90]

I don't have a solution for this.
But I know how to detect it:

ffmpeg -v warning -i sample.m4v -map 0 -map -0:s -f null NUL
(this only works for the origin container, not for the sample slice ...)

If anybody know a more reliable/sensitive way to detect these errors/artifacts, feel free to tell me.

[Columbo]

We can't replicate the issue because you gave the MP4 result. We need the original source MKV file. Also the full command line you used to go from MKV to MP4.

[FLX90]

Unfortunately this is not possible because the file is simply to big ...

ffmpeg^
-i MARVEL_STUDIOS.Title1491.mkv -i MARVEL_STUDIOS.Title1491_german_forced.srt -i MARVEL_STUDIOS.Title1491_german.srt -i MARVEL_STUDIOS.Title1491_english_forced.srt -i MARVEL_STUDIOS.Title1491_english.srt^
-filter_complex "[0:a:0]channelmap=map=FL-FL|FR-FR|FC-FC|LFE-LFE|BL-BL|BR-BR|SL-FLC|SR-FRC:channel_layout=7.1(wide)[newlayout1]"^
-filter_complex "[0:a:1]channelmap=map=FL-FL|FR-FR|FC-FC|LFE-LFE|BL-BL|BR-BR|SL-FLC|SR-FRC:channel_layout=7.1(wide)[newlayout2]"^
-map 0:0 -map "[newlayout1]" -map "[newlayout2]" -map 1:0 -map 2:0 -map 3:0 -map 4:0^
-metadata:s:v:0 handler_name="AVC"^
-metadata:s:a:0 language=deu -metadata:s:a:0 handler_name="Dolby Digital Plus"^
-metadata:s:a:1 language=eng -metadata:s:a:1 handler_name="DTS-HD Master Audio"^
-metadata:s:s:0 language=deu -metadata:s:s:0 handler_name="German (forced)"^
-metadata:s:s:1 language=deu -metadata:s:s:1 handler_name="German"^
-metadata:s:s:2 language=eng -metadata:s:s:2 handler_name="English (forced)"^
-metadata:s:s:3 language=eng -metadata:s:s:3 handler_name="English"^
-movflags disable_chpl^
-c:s mov_text -c:v copy -c:a alac -sample_fmt:a:0 s16p^
MARVEL_STUDIOS.m4v

[Z2697]

19102
https://files.catbox.moe/xtc44t.png

[FLX90]

19102
https://files.catbox.moe/xtc44t.png

Oh nice.
I don't know how these NAL- and SLH-type errors could occur but I'm interested in this detection tool.

Can you tell the name of this tool please?

[Z2697]

Oh nice.
I don't know how these NAL- and SLH-type errors could occur but I'm interested in this detection tool.

Can you tell the name of this tool please?

It's VQ Analyzer.
It's expensive and has a 3 day trial.

I don't understand the errors too, but the video looks like it's from BD, it has open-gop, when it's cut there can be some unexpected issues

[Z2697]

I compared your sample with a full video I found from somewhere and cut at the same position, the "0xb624ba -th" byte in the raw AVC stream is changed from 0x90 to 0x91 in your sample.
Nothing too complicated, just a bit flip, LOL.

You can search for the corrupted block's byte sequence to confirm where did this corruption happen.
(Ideally, extract to raw bitstream, but the sequence is a marcoblock so unlikely to be broken up in contrainers, so search it directly should work as well)

2D BF F8 07 D0 40 C0 7F A5 2B 8A AF 3D 91 F1 18 03 D4 6F DC 02 BE 3D 8C 51 E4 E2
2D BF F8 07 D0 40 C0 7F A5 2B 8A AF 3D 90 F1 18 03 D4 6F DC 02 BE 3D 8C 51 E4 E2

[FLX90]

Crazy. I changed the byte in full file and the video stream is fixed.

But ffmpeg output remains unchanged:

ffmpeg -v error -i "full.m4v" -map 0 -map -0:s -f null NUL
[h264 @ 000001e07b8db240] left block unavailable for requested intra mode
[h264 @ 000001e07b8db240] error while decoding MB 0 43, bytestream 34277

[Z2697]

So the corruption happens in the source MKV?

[FLX90]

No, the source MKV has no errors.
Only the M4V (MP4).

Ah I don't get it ...
I ran the above command with loglevel info and the errors occur at 00:15:26.88 ...
But there is no visible error at this time.
The visible error is at 1:40:12.63 (but there's nothing in the ffmpeg log)...
So I don't know.

I think I double check with:

ffmpeg -v warning -i input.m4v -map 0 -map -0:s -f null NUL

VQAnalyzerConsole.exe input.h264 -regress -errors input.log

Then I should be sure that there's no error ...

[Z2697]

Silent bit corruption is very dangerous, I suggest you run the swapping command again (and more), if it's recurring problem, you should find the root cause and fix it.

[FLX90]

I know now what this error is and how to detect it reliable.

These are concealing errors and you can easily detect them with ffmpeg.
But loglevel info is needed:

ffmpeg -v info -i movie.m4v -map 0 -map -0:s -f null NUL
[h264 @ 000001b2857fb240] concealing 141 DC, 141 AC, 141 MV errors in B frame

[Z2697]

No... concealing error means... to conceal the error... not the actual error is called "concealing"...