Implemented in DGIndexNV rc7. Unfortunately my main computer motherboard had a major failure on July and I am still waiting for newer CPUs to become available. Hope to be testing newer builds soon! :salute: If you meant Ryzen 5000, they are available, but surely overpriced AF. Same as of RTX 3080. ...

Hi, Rocky. Since you decided to poke the code, it will be nice to have this fixed - https://i.imgur.com/beQEYc2.png
On indexing it shows meaningful frame counting, but on completion those fields becomes "1".

Someone asked me to make AvsCompat with PVBob definition, I just shared my findings to Myrsloik. He also added CullRezise filters.

My materials are 4:2:0, but I only want to touch Y component. Colors are fine in 99% cases.
In general I want to undo cheap upscaling method on Y plane, re-upscale with better option, resize to 1080p and add colors back.

Grayscale 8-16 bit will be pretty enough for me. But if it possible to retain float from GPU, that's even better.
If it requires 4:2:0 input, it's fine. I'll pad input with dummy color planes when needed.

https://slow.pics/c/WWEG58rB - new comparison, now added eedi3+nnedi3.
NGX looks slightly sharper and less noisy, but still impressive.

I'm pretty satisfied with results, it's visually as good as eedi3+nnedi3 but probably better and with less computational effort. I'd like to see Vapoursynth implementation for that and use for my anime re-scaling script.

Now it works!
https://slow.pics/c/XjBd5YLA

Well, I managed to fix missing dll stuff (downloaded opencv_word342.dll from internet and copy-renamed it to opencv_core342.dll, opencv_imgcodecs342.dll and opencv_imgproc342.dll), now it outputs C:\Users\DJATOM\Downloads>isr NVIDIA NGX ISR Sample --factor Super resolution factor (2, 4, 8) --input I...

It says I have a newer version of that product installed. Can't continue.

I have all redists installed (2015 and 2017 superseded by 2019). As for driver version,

https://pastebin.com/4KaU8N49 it still depends on extra libraries

It says I'm missing NvDecoder.dll, NvEncoder.dll, avformat-57.dll, avutil-55.dll and avcodec-57.dll files.

MGVC is a way too proprietary solution, only few Panasonic players can play it.
8 bit part is accessible as a regular BD, but 2-10 bit stream coded some sneaky way that didn't figured out howto decrypt that.

So it's only for mpls files... I thought DGDemux will support regular demuxing, as DGIndexNV does

I don't see a use case since DGSource still have to copy back decoded video into RAM, so doing that by extra call in the script might be even faster.

Sure. No is no, I'll just trust you

I thought of separate counting for demuxed .264 ES IDR sequences and increasing IDR stamps on it, as diff shows: https://www.diffchecker.com/GYLT5LUh. Or just doing second instance of indexing before writing demuxed video stream onto disk (we should have an option for it in that case).

If I do understand index structure properly, it writes position (in bytes) to IDR frame and then explains how much data it can decode (in frames) and describes a type/etc. So in case of .264 ES we just need to correct those positions after demuxing step (and fix file extension). Other parts of index...

I've tuned Meari sample to match mpv's output (slightly brighter, but looks better for me)

Not to mention that mainline is avs+ nowadays, as 2.6 being dead for many years.

I'm not sure if it's possible to reuse Opticflow vectors data in mvtools2, but if it's compatible, that should provide nice speedup in scripts.

Obviously DGSource returns de-interlaced and resized data, then DGTelecide do his stuff. If that's what you asked for.

Even if we have PCI-E 4.0 Ready MB, with PCI-E 3.0 devices there are no actual improvement in bandwidth. I'm planning to buy Ryzen 3900x and considering between x470 and x570 chipsets. Probably I should wait for comparisons, x470 most likely will perform worse.

I just have to sort by extension and delete a bunch of logs, that's the most annoying part. If it's intended behaviour — okay, I'll add explicit del command to clean it up.