Maybe a MVTools issue

[tebasuna51]

pm received from Soloiam68 user, like is a general question must be in this subforum:

I am a hobbyist encoder and have been using a filter named MVTools for a while with great results. However, recently I encountered some issues. I encoded a video and noticed some weird horizontal line-type blockings. It’s not banding and i think neither compression artifact because i tested both x264 and x265 with highest settings. when a cloudy-type object covers a wide area and moves, it looks like multiple horizontal lines of box-type patterns appear and it shows up on multiple parts of the video. It's not present in the source file and isn't coming from any other prefilters used before MDegrain3. When the video goes through MVTools and removes the grain, the issue appears. I am facing this issue recently and have tried everything to solve the problem, but nothing has worked. I also used the latest and many other versions of MVTools, but the issue persists.

I am now hopeless. Can you please look into the matter kindly. My request

here is all the files and images of artifact (https://drive.google.com/file/d/17647P0pgmzSZCFe_G4Lomv1X7G6ACBgj/view)


i am using Avisynth+ 3.7.3 and x264 encoder (veryslow preset)

Sorry but I can't see the issue, maybe other video expert user can answer to Soloiam68.

[gispos]

"...i tested both x264 and x265 with highest settings." ?

In my opinion, the problem is that the encoder's bitrate is set too low.
With lossless, everything looks good, but I used FFMPEG x264 with CRF 21 and lossless.

Contrast and brightness have been greatly increased for better recognition.
https://i.postimg.cc/28FgbTyN/Analisys2.jpg (https://postimg.cc/dL35g2G5)

[Soloiam68]

@gispos i used x264.exe with crf 16.8 here is my encoding settings:

x264.exe --level 4.1 --preset veryslow --crf 16.8 --deblock -3:-3 --ref 4 --ipratio 1.2 --pbratio 1.2 --vbv-bufsize 78125 --vbv-maxrate 62500 --qcomp 0.65 --aq-mode 3 --aq-strength 0.95 --merange 48 --no-dct-decimate --no-fast-pskip --no-mbtree --colorprim bt709 --transfer bt709 --colormatrix bt709 --output output.264 test.avs

I don't think this is just ordinary blocking due to compression. There are multiple horizontal cross-field artifacts, similar to interlacing, that are not very visible. I'm not sure what artifact it is; I found it in other scenes as well under similar conditions, but it becomes visible only when the video is degrained. If you tested my script and found nothing in the lossless version, could it be related to the encoder? Also, can you send me the video file that you encoded? I tested both x264 and x265 encoders, and both have the same problem. It's very confusing.

[gispos]

I don't think this is just ordinary blocking due to compression. There are multiple horizontal cross-field artifacts, similar to interlacing, that are not very visible. I'm not sure what artifact it is; I found it in other scenes as well under similar conditions, but it becomes visible only when the video is degrained. If you tested my script and found nothing in the lossless version, could it be related to the encoder? Also, can you send me the video file that you encoded?
I have used your script,
and I didn't notice anything when I looked at the frames individually with the source not yet encoded.
I have used Tweak to brighten it up, even with lossless there are no differences. So it can only be due to the encoder settings.

I think that the clouds are not easy to encode, even with CRF 10 you can still see clear differences when you brighten it up. But for me these are compression artifacts.

Unfortunately I have already deleted my encoded files.

Edit:
I still found the lossless.
If you look very closely, lossless is not 100% lossless. The lossless encoded material is a little less sharp (more denoised).
https://drive.google.com/drive/folders/1-2MOIzJ6R3jQOlWh0Fq0x8fbscr_FEcn?usp=drive_link

I think the picture is too dark to get a higher data rate from the CRF automatic. If the video is made brighter before encoding, there is hardly any difference to be seen with CRF 17, but then the file size shoots up to approx. 80 MB

[Soloiam68]

Actually, you are right. The issue was on my side, but it was not the encoder; it was the filters. After testing and debugging everything, I found nothing. The last thing I did was delete all the Avisynth plugins from the plugins folder and keep only the required ones. Surprisingly, the artifact was gone. So, the issue might have come from some other plugin that interfered with the main plugins during encoding and caused those artifacts. However, which plugin did that will remain a mystery. :)

[tebasuna51]

I recommend you the Groucho Avisynth Info Tool (https://forum.doom9.org/showthread.php?p=1864682#post1864682) to check your AviSynth install with duplicated functions inform, etc.

[Boulder]

I wouldn't be surprised if avstp.dll is causing some issue. MVTools works fine without it but I think that if the dll is found, internal multithreading is enabled by default in various parts of it. pinterf has already fixed one long standing case of random lock-ups but the tool seems very hard to trace and debug.

[ChaosKing]

Check if your source filter is frame accurate.

[Soloiam68]

@Boulder Oh, should I remove it? Doesn't it slow down the process? I am using dither.dll and mvtools2.dll. I think both require that.

[Boulder]

@Boulder Oh, should I remove it? Doesn't it slow down the process? I am using dither.dll and mvtools2.dll. I think both require that.

You can try and see if everything works better. You can use the internal Avisynth multithreading to compensate (and it's often faster).