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.

I think it might be a bug, since I set Enable_Info_Log=0 and it's ignored when I'm making indexes in cmd.
I'm on slipstream 175 right now.

I didn't tried, but probably you can decode and resize with any suitable decoder and set mastering data during encoding process. It should remains the same (at least there is no difference on non-resized tonemapped UHD frame, then resized to 1080p and bicubic-resized UHD to 1080p and then tonemapped).

admin wrote: ↑

Fri May 03, 2019 9:38 am

$15 is not much but he also needs to buy an nVidia card.

Indeed. And probably 1660 or better, if he needs max performance. 1650 looks castrated a bit, but probably fine for decoding.

No, it's impossible w/o card as it relies on HW decoder by NVidia.
There is no trial for DGNV, I believe $15 is not that much for you.