Strange Random Corrupt Frames

[simple_simon]

I'm seeing blank grey frames (except for small pixel noise at the top) in some videos when previewing. Screenshot shows example in AvsPmod:

https://send.cm/279l2wwz9btz

I've noticed it in several different videos now. I'm using lsmashsource as my indexer with MeGUI and encoding to x264 using the latest build. I've ruled out lsmashsource because I get the same results using ffindex. I've ruled out the MeGUI previewer because I get the same results in AvsPmod.

It's usually just a single corrupt frame. Sometimes a few in a row. If I click through the preview linearly frame by frame I don't see the corrupt frames. It appears as though all the frames are correct and accounted for (so the uncorrupted frames exist in the file). But if I skip directly to the area with the corrupt frame then it appears as in my screenshot. Same thing if I click backwards through the frames, the corrupt frames will be there.

There's no way to check for this. The only times I've noticed it has just been complete coincidence from randomly clicking on that specific frame when previewing filters before encoding.

I assumed that this was just a strange anomaly in the previewer that wouldn't exist once encoded but I just happened to check a recently encoded file and saw corrupt frames in the encoded file. I still had the source file, index file & script so I checked the source file for corrupt frames but they didn't exist in the source. I loaded it back up in AvsPmod and sure enough the corrupt frames were there in the previewer (yet weren't there when frames were previewed linearly). I re-encoded the file with the exact same script (just spline36resize & cropping) and x264 settings and the new file didn't have corrupt frames in the encode.

So I can't figure out what's going on or how to prevent it or check for it. I feel like all my thousands of encodes are suspect now. Is there any way to check for corrupt frames without viewing the entire video frame by frame? Or does anybody have an idea what might be going on here?

[poisondeathray]

lsmash /ffms2 versions ?

Did you try threads=1 for lsmash/ffms2 ? It can sometimes help with random seeks

What file type / compression / container ?

Did you try DGSource/DGDecNV ?

[johnmeyer]

If you have corrupted frames when you seek, but don't when you play, then you need to read the file using some other reader. I therefore agree with the last line in poisondeathray's post above.

[simple_simon]

lsmash /ffms2 versions ?

Did you try threads=1 for lsmash/ffms2 ? It can sometimes help with random seeks

What file type / compression / container ?

Did you try DGSource/DGDecNV ?

Versions:
ffms2=3.0.1.0 1328+19 41af11c (compiled 01/2023)
lsmash=r1124 (compiled 11/2022)

I just tried using threads=1 with no change in results.

Source=Bluray(AVC)-->mkv container
Destination=x264 in mkv container

I didn't try DGSource because I thought it only worked for mpeg-2. I assumed since I tried two different indexers though with the same results that that would rule out the indexer as the problem.

The thing that really has me confused is why, out of two encodes with equal settings, one encode had the missing frames encoded into the file and one encode included all the original frames with no corrupt frames. However the previewer consistently shows corrupt frames in the same spot when not previewed linearly frame by frame.

[poisondeathray]

I didn't try DGSource because I thought it only worked for mpeg-2. I assumed since I tried two different indexers though with the same results that that would rule out the indexer as the problem.



DGIndexNV (DGDecodeNV.dll using DGSource, for HEVC, AVC, VC1, MPEG2) is not the same as DGIndex (dgdecode.dll using Mpeg2source, for mpeg2 sources only).

DGSource is the most reliable source filter for avisynth/vapoursynth, but requires a compatible Nvidia card. DG has made it free now. There are tests and results posted in several threads using "seektester" and seek-test.py python script


Versions:
ffms2=3.0.1.0 1328+19 41af11c (compiled 01/2023)
lsmash=r1124 (compiled 11/2022)

I just tried using threads=1 with no change in results.

Source=Bluray(AVC)-->mkv container
Destination=x264 in mkv container


You should not have that problem with random seeks using those recent .dll versions with just source filter

Were there other filters ? What was the full script ?

or was it just "just spline36resize & cropping" ? => this should have no problems

Linear encoding should not have any problems; but possibly some types of temporal filters can have problems with non linear seeks


The thing that really has me confused is why, out of two encodes with equal settings, one encode had the missing frames encoded into the file and one encode included all the original frames with no corrupt frames. However the previewer consistently shows corrupt frames in the same spot when not previewed linearly frame by frame.
Maybe something else going on with your system, overheating, memory issue, read/write corruption (bad storage?) . Run some diagnostics and stress tests

Also, what version of avspmod ? Double check with vdub2 as previewer too

[simple_simon]

DGIndexNV (DGDecodeNV.dll using DGSource, for HEVC, AVC, VC1, MPEG2) is not the same as DGIndex (dgdecode.dll using Mpeg2source, for mpeg2 sources only).

DGSource is the most reliable source filter for avisynth/vapoursynth, but requires a compatible Nvidia card. DG has made it free now. There are tests and results posted in several threads using "seektester" and seek-test.py python script

I have DGDecodeNV but I have a pretty old nvidia card and it ends up bottlenecking everything as opposed to using cpu.

Were there other filters ? What was the full script ?

or was it just "just spline36resize & cropping" ? => this should have no problems

Script was:
[Source]
crop()
spline36resize(960,720)
prefetch(2)

I would suspect the multithreading to be causing a problem but turning it off in the preview doesn't eliminate the issue.

Also, what version of avspmod ? Double check with vdub2 as previewer too

AvsPmod v2.7.3.6

Previewing in virtualdub2 shows same corrupt grey frames, except they are there whether or not the file is previewed linearly AND the corrupt frames seem to be a different place everytime the file is reloaded. Very strange.

Maybe something else going on with your system, overheating, memory issue, read/write corruption (bad storage?) . Run some diagnostics and stress tests

I thought about that. I did a windows memory diagnostic test to check for bad memory but it didn't find any errors. I have a cpu temp app running that gives me realtime temps in my taskbar and it shows temps in the mid 80's °C sometimes when encoding is using 100% cpu but I don't think that's overheating range. What other stress tests would you suggest?

[poisondeathray]

I have DGDecodeNV but I have a pretty old nvidia card and it ends up bottlenecking everything as opposed to using cpu.


But you should try it anyways, to help debug and rule out a source filter issue, perhaps with some specific BD titles - If it "works", you *know* what the problem is. If it exhibits the same issue, it's likely something else on your setup





Script was:
[Source]
crop()
spline36resize(960,720)
prefetch(2)

I would suspect the multithreading to be causing a problem but turning it off in the preview doesn't eliminate the issue.


I don't have any problems with recent ffms2 or lsmash with AVC BD random seeks in MKV (or M2TS) with prefetch(>1) with spatial only filters

Could it be a bad rip? (makemkv ?) . You mentioned "several different videos", so that's more than 1 specific source . But just to rule out several bad sources, if you upload a sample, someone can check if they experience the issue (I seriously doubt it)



AvsPmod v2.7.3.6

Previewing in virtualdub2 shows same corrupt grey frames, except they are there whether or not the file is previewed linearly AND the corrupt frames seem to be a different place everytime the file is reloaded. Very strange.


The "randomness" with reloading is very strange with non temporal filters . Can you try with just source filter ?


I thought about that. I did a windows memory diagnostic test to check for bad memory but it didn't find any errors. I have a cpu temp app running that gives me realtime temps in my taskbar and it shows temps in the mid 80's °C sometimes when encoding is using 100% cpu but I don't think that's overheating range. What other stress tests would you suggest?

Prime95, OCCT , memtest86+ - but it's unlikely to be your problem .

[kedautinh12]

Try add threads=2 to L-SMASH-Works. I remember i had some corrupt frames and i fixed with try add threads=2 to 8. If still error, try change LSMASHVideoSource to LWLibavVideoSource

[simple_simon]

Try add threads=2 to L-SMASH-Works. I remember i had some corrupt frames and i fixed with try add threads=2 to 8. If still error, try change LSMASHVideoSource to LWLibavVideoSource

I tried adding threads=2 and even threads=4 with no change in results. I was already using LWLibavVideoSource

Could it be a bad rip? (makemkv ?) . You mentioned "several different videos", so that's more than 1 specific source .

I did use makemkv to rip but like I said there is no perceivable frame corruption in playback of the source mkv file, so I ruled that out as the source of the problem.

I did notice this is several other videos before in preview but there was no sign of frame corruption in the resulting encode so I assumed, until now, that the anomaly was just in the previewer. I don't remember which videos those were now to recheck. This was the first time I've noticed the corrupt blank frames in the encode as well.

The "randomness" with reloading is very strange with non temporal filters . Can you try with just source filter ?

All I did in virtualdub2 was load the source mkv. No filters were added. I agree, it's even stranger than the original issue.

But you should try it anyways, to help debug and rule out a source filter issue, perhaps with some specific BD titles - If it "works", you *know* what the problem is. If it exhibits the same issue, it's likely something else on your setup

DGDecodeNV indeed doesn't show any signs of corrupt frames where they were being shown in the other 3 decoders. On one hand that's great to know but it doesn't really answer the question of what's going on. Only 1 out 4 of the most popular video decoders are accurately decoding this file(s)? And it's not even consistent because encode #1 had the corrupt frames passed along to the final encode but encode #2 did not. And virtualdub2 is reading corrupt frames seemingly at random. It seems DGDecodeNV is the only decoder I can trust going forward but that's going to severely slow everything down unless I spring for a whole new computer.

[poisondeathray]

DGDecodeNV indeed doesn't show any signs of corrupt frames where they were being shown in the other 3 decoders. On one hand that's great to know but it doesn't really answer the question of what's going on. Only 1 out 4 of the most popular video decoders are accurately decoding this file(s)? And it's not even consistent because encode #1 had the corrupt frames passed along to the final encode but encode #2 did not. And virtualdub2 is reading corrupt frames seemingly at random. It seems DGDecodeNV is the only decoder I can trust going forward but that's going to severely slow everything down unless I spring for a whole new computer.

You can look at the results of seektester and seek-test.py . I think ChaosKing compiled a spreadsheet. Basically , DGSource the most reliable. (But those were insane worse case scenario seeks, nothing that you would encounter in real life. For "normal" scenarios, LSmash and FFMS2 work perfectly fine...for most people

I cannot reproduce the issues you are having on AVC BD's with ffms2 or lsmash on several different BD's with avspmod or vdub2. If there is an issue (which is not limited to your setup), you can try to figure out what is going on, file a bug report, and get it fixed. It has to be consistently reproducable by a developer. I'm not convinced there is an issue on other setups, and I don't know why only you are getting those results (think about it, there would be many more threads reporting this issue since lsmash, ffms2 are commonly used)

[simple_simon]

You can look at the results of seektester and seek-test.py . I think ChaosKing compiled a spreadsheet. Basically , DGSource the most reliable. (But those were insane worse case scenario seeks, nothing that you would encounter in real life. For "normal" scenarios, LSmash and FFMS2 work perfectly fine...for most people

I cannot reproduce the issues you are having on AVC BD's with ffms2 or lsmash on several different BD's with avspmod or vdub2. If there is an issue (which is not limited to your setup), you can try to figure out what is going on, file a bug report, and get it fixed. It has to be consistently reproducable by a developer. I'm not convinced there is an issue on other setups, and I don't know why only you are getting those results (think about it, there would be many more threads reporting this issue since lsmash, ffms2 are commonly used)

It's not all AVC BD's. It's rare. I've only noticed it probably 5 times or less. But I have to click on the frame where the problem is to see it so I'm guessing there's been more that have been unnoticed. After 3 decoder showed the same thing I was convinced it was a problem with my system too but DGDecodeNV handled it without issue. Plus if it was a problem with my system I would expect the corrupt frame to show up in a different part of the video each time (like it's doing in virtualdub2) but at least with lsmash & ffms2 it's in the same place each time I load the file.

I didn't know if cutting a clip out of the source file would still produce the same results but it appears it does so here:

https://send.cm/6kwyhdtho30b

Look at around frames 277 & 1579

[coolgit]

All I did in virtualdub2 was load the source mkv. No filters were added. I agree, it's even stranger than the original issue.

I had some weird grey frames before with certain .mkv files. Open using ffmpeg instead of catching input driver solved the problem for me.

[poisondeathray]

It's not all AVC BD's. It's rare. I've only noticed it probably 5 times or less. But I have to click on the frame where the problem is to see it so I'm guessing there's been more that have been unnoticed. After 3 decoder showed the same thing I was convinced it was a problem with my system too but DGDecodeNV handled it without issue. Plus if it was a problem with my system I would expect the corrupt frame to show up in a different part of the video each time (like it's doing in virtualdub2) but at least with lsmash & ffms2 it's in the same place each time I load the file.

I didn't know if cutting a clip out of the source file would still produce the same results but it appears it does so here:

https://send.cm/6kwyhdtho30b

Look at around frames 277 & 1579


I can reproduce the issue with ffms2 and lsmash, threads=1 or otherwise. You should file a bug report with that sample to get it fixed. There are several IDR frames, so it's a proper sample

DGSource is ok

A workaround for non Nvidia users until it gets "fixed" is to use preroll(60) or some value. This decodes "x" frame linearly before that point

[StvG]

I can reproduce the issue with ffms2 and lsmash, threads=1 or otherwise. You should file a bug report with that sample to get it fixed. There are several IDR frames, so it's a proper sample

DGSource is ok

A workaround for non Nvidia users until it gets "fixed" is to use preroll(60) or some value. This decodes "x" frame linearly before that point

ffmpeg complains about incorrect dts. Doing ffmpeg -i Sample1.mkv -c copy Sample1.h264 and then using mkvtoolnix to mux in mkv, no issues with ffms2/lsmash. I wouldn't use makemkv for mkv muxing. If you originally remux the source in mkv with mkvtoolnix you probably wouldn't have these issues.

[simple_simon]

ffmpeg complains about incorrect dts. Doing ffmpeg -i Sample1.mkv -c copy Sample1.h264 and then using mkvtoolnix to mux in mkv, no issues with ffms2/lsmash. I wouldn't use makemkv for mkv muxing. If you originally remux the source in mkv with mkvtoolnix you probably wouldn't have these issues.

I'm still seeing the problem after remuxing with mkvtoolnix.

[StainlessS]

Recent DgSource does scramble some BD->Mkv frames if seeking, maybe about 1 in 20 BD -> Mkv's [via MakeMkv].
This should rarely/never fail [so long as 8 bit], batch converts to AVI
https://forum.doom9.org/showthread.php?p=1979916#post1979916

[Boulder]

Recent DgSource does scramble some BD->Mkv frames if seeking, maybe about 1 in 20 BD -> Mkv's [via MakeMkv].
This should rarely/never fail [so long as 8 bit], batch converts to AVI
https://forum.doom9.org/showthread.php?p=1979916#post1979916

I've seen some weird stuff happen with DGSource and MVTools functions with Prefetch in the script, but adding RequestLinear(clim=100) right after the source call has fixed them. Pinterf's already fixed one issue a long time ago but I've had them also after that.