Support forum for DG Tools

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.