Support forum for DG Tools

One is a regression. I've been using b179 for a good while, and I can reload the avs script inside VD2 with no problem. In the progress of debugging the 2nd issue, I tried b198 which is the latest. Every time I reload the avs script inside VD2 it crashes.

---------------------------
DGSource
---------------------------
cuMemHostAlloc() failed
---------------------------

I happen to have b187 and b188. b187 is last known good, and b188 is the first known bad. I guess it has something to do with the new 8k support, but I'm not 100% sure. Yes I'm still on RTX 950 2G, and the file I'm opening is 1440x1080 MPEG2 TS, using VirtualDub2 build 43702 32-bit.

==========

2nd issue is the main issue I hit today. I have a fairly long video capped, a TV program. It has 543022 frames. Eac3to thinks the stream is clean and my video player doesn't complain about it.
This works perfectly from top to bottom.
This works perfectly from top to bottom.
This doesn't work when seeking or playing beyond 1000063 frames. Immediately after 1000063 frames all I see is black image, even when seeking back below 1000063 frames, and reload the video is the only choice.

Seeking to 104xxxx frames could somehow make it produce some correct images, but seeking still cause decoding issues.




I can reproduce it by trim the clip: This triggers the issue at frame #63.

Tested against both b179 and b198. Behavior is exact the same.

However if I simply cut the TS video (using a raw binary file cutter) and re-index, the result works perfectly. I cut at 29292768800 bytes which is about 490000 (980000 at double rate) frames, leaving the remaining 53000 (106000 at double rate) frames.

Any ideas?

Ooh, that's not good.

I'll look at the reload issue today. I assume you mean 'File/Reopen video file'. If not, please advise.

On the second issue, is there any chance to upload the stream to my ftp? Maybe you can cut it down if needed such that it still fails.

Due to a quirk of VirtualDub(2) reload function, a constructor on the new instance of DGDecodeNV is called before the destructor on the first instance. So you need enough memory to allocate twice.

EDIT: Ah, just tested 32-bit and was able to reproduce the failure. Works for me with 64-bit stuff. I'll look into it, but why can't you use 64-bit?

EDIT2: I've experimented with a lot of things and I just can't find a way to get enough memory on 32-bit windows to allow the reload function to work.

The 8K support could be disabled for 32-bit operation. However, do we want ugly warts just to salvage the 32-bit reload in VirtualDub(2)? Methinks not. With the status quo 8K can still be opened in 32-bit, although VirtualDub(2) reload fails.

Not so simple. You can open the script multiple times no problem. So a simple reload goes bananas? Think about it!

Fake news about hospital is joke. Be careful, or I drink you dry.

Rocky wrote: ↑

Sun Dec 29, 2019 10:20 am

On the second issue, is there any chance to upload the stream to my ftp? Maybe you can cut it down if needed such that it still fails.

Cut it down and problem seems to go away.

I'm not sure if it has anything to do with the number 1000000 but looks suspicious.

Because if I disable double rate deinterlace (which make it <600000 frames) problem also goes away.

I just cut 180MB off the head so full video moves forward. Problem starts at the new 1000063 frames after cut.

Where can I upload? It's around 32GB. I'll upload RAR part volumes if you don't mind.

Rocky wrote: ↑

Sun Dec 29, 2019 12:20 pm

EDIT: Ah, just tested 32-bit and was able to reproduce the failure. Works for me with 64-bit stuff. I'll look into it, but why can't you use 64-bit?

EDIT2: I've experimented with a lot of things and I just can't find a way to get enough memory on 32-bit windows to allow the reload function to work.

I could. But my encoding farm and lots of filters are still on 32-bit and I haven't invest the time to sort that out and maybe rewrite lots of C code.

For the time being I think I can switch to 64-bit for previewing and still use 32-bit for encoding. (Unfortunately the farm doesn't have graphics cards so I'm using traditional DG, which still works perfectly by the way.) It's not a blocker issue to me, and I just want to brought the regression issue to your attention.

Sending ftp details by PM. Upload the full unprocessed source. Thank you so much. Together, all is possible.

There is no coded limit of 1000000 frames anywhere in DGDecNV. So I'm curious about this.

Too bad for win32.

With respect to Natasha's comment, the limits are per-process. Opening the script in multiple VirtualDub(2) instances involves multiple processes, whereas the reload involves only one process.

Fortunately there is a simple solution to this problem. DGDecNV has MAX_WIDTH and MAX_HEIGHT of 8192 and 8192. Changing this to 7680 and 4320 (max 8K resolution for UHD) allows the reload to succeed in 32-bit.

Thank you, Mr. Peabody. That's what we'll do!

Investigating issue 2...

Random access is broken for deinterlace=2. I'll fix it but in the meantime you can do this:

DGSource(..., deinterlace=0)
PVBob()

Thanks. In the meantime I'm using DGNV / DGMPG with bob / QTGMC so it's not a blocker. Thanks to the consistency of DG tools I can switch between filters without worrying about frame misalignment.

Happy new year btw!

Happy New Year to you as well! Thank you so much.

I mentioned PVBob() because it will have the same output as deinterlace=2. Of course you can use any deinterlacer you like. DGBob() is a yadif-like implementation. Both PVBob() and DGBob() are CUDA accelerated. Always great to have options!

You'll be happy to hear that I have both of these issues fixed. The reload fix was easy (thank you Mr. Peabody). The seek issue with deinterlace=2 was a bit involved, so I will do some serious regression testing before giving you a slipstream. Could be later today.

Thank you for pointing these out, MeteorRain.

Fixes released in slipstream 199.

Sweeeeet