VirtualDub2

[StainlessS]

Yip, MagicUV and also UT_Video are great lossless codecs for AVI, and AVI is pretty much bulletproof as source clip [so long as you aint daft enough to use DivX/XVid],
you can spend a lot of time screwing around with non AVISource source filters, almost always less strain on the heart to first just convert to AVI via FFMPeg,
exception being DGIndex where is pretty damn solid too. [EDIT: 10 bit AVI may though still be problematic]

[osgZach]

So, interesting development.

I took 15 minutes of footage, decided to just arbitrarily put in a huge file size (10GB) and then limit the frames to 7100 frames and run a segmented export.

It gave me four total segments. 3.19GB, 3.45GB, 3.80GB, and 155.56MB (respectively 4m:56s each, and 11 seconds)


So.... I guess there is no sanity check on that input box or something? Or maybe the wording on it just never got update
I did a stream copy so no idea if that influenced it at all.

[poisondeathray]

Originally Posted by osgZach

So, interesting development.

I took 15 minutes of footage, decided to just arbitrarily put in a huge file size (10GB) and then limit the frames to 7100 frames and run a segmented export.

It gave me four total segments. 3.19GB, 3.45GB, 3.80GB, and 155.56MB (respectively 4m:56s each, and 11 seconds)


So.... I guess there is no sanity check on that input box or something? Or maybe the wording on it just never got update
I did a stream copy so no idea if that influenced it at all.

Different types of content have different compression ratios

7100 frames of complex, noisy footage would be much larger than 7100 frames of 1 color black, for all types of compression schemes (lossy, lossless, I-frame, or long GOP)

Uncompressed video, however, will lead to the same filesize per frame

[osgZach]

I think you've overlooked the context of the data.

As mentioned earlier, I output lossless MagicYUV files.
I requested a modification to the alleged 2GB file size limit on segmented AVI output - which it appears is not an actual limit after some further testing. I put 10GB on purpose to see if it would reject it or break the output in some way, and then I chose 7100 to make sure I got several segments over a 21k frame selection range.

[LigH]

I believe the 2 GB limit for legacy AVI is not related to FAT32 files, but to 32 bit chunk sizes in the AVI structure, which are often even interpreted as signed. OpenDML was the AVI 2.0 extension to circumvent this internal limit.

[StainlessS]

Makes sense, thanks LigH.

[osgZach]

hmm ok, still seeing some weirdness here I guess.

I took a MagicYUV (M8Y0) input for a denoised Wrath of Khan I made a while ago, and gave it enough frames to split down the middle (58m15s both files). But when I try to open either of them in WMP, JRiver, etc it won't play. VLC says it has to rebuild the file index. Openinng with Vdub prompts an operation for "Reconstructing Index Block", it hangs for a bit, then throws out this warning



seeking around takes a few seconds to accomplish.

I can open an earlier aborted output just fine, because that file was only 500MB so I am guessing there may still be something to investigate with VDubs file splitting abilities. The only thing I did here aside from specify a large maximum frame per segment, was increasing the file size limit to 500GB I'll experiment with some lower values on the size limit to see if it has any weird influence on output errors.

[wonkey_monkey]

Sounds like VirtualDub just literally splits the file output, rather than creating two valid AVI files. The index would be in the second half (it's also always written on abort, I believe, making an aborted file valid), and the second half would not contain any headers.

[osgZach]

Originally Posted by wonkey_monkey

Sounds like VirtualDub just literally splits the file output, rather than creating two valid AVI files. The index would be in the second half (it's also always written on abort, I believe, making an aborted file valid), and the second half would not contain any headers.

I don't think this is the case. I just set it to 2GB segment size and every single one outputs / loads fine independently outside of Vdub, even moved a single segment to another location and loaded without any hiccups.
I'm going to re-run the job I just with the messed up outputs when I go to bed and see what happens. Still hoping I just caused a glitch doing other stuff on the PC.

[osgZach]

The magic number seems to be a segment size of 4096MB anything above this appears to produce index errors in all files, except for the final segment, if it is below that size.

[shekh]

There is error in file creation when using segments: odml header/index is disabled. Looks fixable

[osgZach]

I've been testing out a fixed build provided by shekh, and it appears to work well.

I am also currently investigating my work flow to try and determine where and how an extra frame was inserted into a video stream (at the end). I will report back here when I have some findings. I vaguely recall confusion about the way vdub reports an extra frame in the past - or perhaps I am misremembering?

[lansing]

Bug reporting, setting in preference doesn't save unless I explicitly clicked "save". Clicking "ok" after changes doesn't save.

[shekh]

Originally Posted by lansing

Bug reporting, setting in preference doesn't save unless I explicitly clicked "save". Clicking "ok" after changes doesn't save.

This is the purpose of "save". Not a bug

[wonkey_monkey]

I would say it is outdated/unexpected behaiour, though. These days an "OK" is expected to save and for those changes to persist. That's if there is even an "OK" to begin with, since even that seems to be falling out of fashion these days.

[shekh]

Originally Posted by wonkey_monkey

I would say it is outdated/unexpected behaiour, though. These days an "OK" is expected to save and for those changes to persist. That's if there is even an "OK" to begin with, since even that seems to be falling out of fashion these days.

This project has deep roots in legacy and software archeology
Anyway, thanks for suggestion.

[lansing]

Originally Posted by shekh

This is the purpose of "save". Not a bug

But then why does the setting change get "remembered" for that instance of the program and not after I close and reopen the app?

[shekh]

Originally Posted by lansing

But then why does the setting change get "remembered" for that instance of the program and not after I close and reopen the app?

Exactly, to let you use the setting "now" while keeping the saved preferences unchanged (for someone paranoid about making global changes?).
I made it worse with this feature: https://sourceforge.net/p/vdfiltermod/wiki/vdscript/

[lansing]

Originally Posted by shekh

Exactly, to let you use the setting "now" while keeping the saved preferences unchanged (for someone paranoid about making global changes?).

That does not make any sense. Why would anyone making a change in setting scared about making changes? If anyone is scared about messing up, there can be a "restore default" button.

[MeteorRain]

Feature request:

When rendering video from YUV to RGB on the UI, is there a place for me to select which colormatrix to use for the input pane?

Imported a BT.2020 YUV420P16 avs clip, and the color displayed seems to be either 601 or 709 matrix.

Hopefully there's an option to select the correct colormatrix.

I'm perfectly fine with a context menu to pick 2020 every time I load a clip. But if this has already been implemented somewhere, please kindly let me know.

Edit: It seems Decoding Format is what I was looking for. Still, 2020 could be added to the input color space.