VirtualDub2

[Morku]

And when you open cropping dialog, it is normal (not strange)? Btw how it is in strange way, may a screenshot show this?
I also received a somehow related ticket https://sourceforge.net/p/vdfiltermod/tickets/186/
Do you have Nvidia drivers?

Hi,
to describe the distortions, I think it's the best to show as a video. Depending where the window of VirtualDub is, the preview 'moves' and you can create that "winning solitair" effect (or crashing IE on windows95, you know...).
Check the video: https://www.dropbox.com/s/ri897y11tfkh3ai/virtualdub.mp4?dl=0

What me also wonder, when I start the recoding, the distortions stops and the preview is fine. No matter which position of VirtualDub.

Yes, the Cropping windows is always fine. I can move around the window without issues.

Yes, I use NVIDIA GTX 980 Ti with 416.34

[shekh]

Yes, I use NVIDIA GTX 980 Ti with 416.34

So maybe it is the same Nvidia issue and you can try older drivers?

The distortion looks really weird. You can also try display preferences (enable/disable "use directx" etc) to see if it has effect on this.

[Morku]

I can confirm the reporting on sourceforge. I uninstalled the driver (Microsoft basic driver) and have Overlay Preview without issue. Also Preview (system) works fine.

I installed for testing 399.07 -> same issue like current driver
I tried 388.31 -> no issues anymore

Which display prefences do you mean? Nvidia settings? in VirtualDub? Windows?

[shekh]

I meant VirtualDub preferences.

P.S.
Although it is not an issue, I find it still confusing how capture preview modes are organized, after inspecting again:
"Overlay" tries to render "videoPort" pin first, then "preview", then "capture"
"Preview" only renders "capture" pin but in the middle there is also "Sample Grabber"

I see no evidence that in either case any video overlay is expected.
And the fact that "Preview" mode never connects to "preview" pin does not help to understand.
So these are quite meaningless choices.

[Morku]

Okay, I played around a little in the setting.
Not matter which setting I change it doesn't effekt the Overlay, Preview (system). There is no preview.

But it does effect the "Display with Filters" setting:

uncheck "Use DirectX for display panes" fix the glitchy moving VirtualDub preview
It is also fixed when Direct3D 9, or OpenGL or Direct3D 11 is checked.
Any other optioncombination you would like to know?

[shekh]

Thanks, nothing left to check and it seems the problem cannot be solved (very unlikely).

[Morku]

Haha, okay. But at least we found some workarounds.

[WorBry]

@Shekh,
Sorry, but I'd appreciate further clarification on this:

Checked what is going on with chroma,
444 -> 422: each pixel is convolved with kernel 0.25, 0.5, 0.25
As I understand this creates some blurring.

422 -> 444: odd pixel is copied as is, even pixel is blended from two neighbor source pixels
This is simple.

https://i.postimg.cc/gJ7VB4QS/checker422.png

From the screenshot it seems Sony is using bilinear downsampling for 444->422, this blends max 2 neighbor pixels as opposed to summed area.
I changed various interpolation options until I got very similar picture.
For 442->444 it is still bilinear upsampling, no changes.
https://i.postimg.cc/zX4JT3bR/checker-2.png

You said there that VDub2 sub-samples 444 > 422 using this "each pixel convolved with kernel 0.25, 0.5, 0.25" modality, whereas Vegas is using bilinear re-sampling which "blends max 2 neighbor pixels as opposed to summed area".

As it turns out, both Resolve (15.1.2) and Premiere Pro produce exactly the same results as VDub2 when the Checkers-444 (ProRes_4444) clip is 'pass through' exported to v210, giving the same pattern, as per the image in your first post:

http://i.imgur.com/nMWv0Vm.png (https://imgur.com/nMWv0Vm)

Whereas Resolve 15.1 behaves in the same way as Vegas Pro, giving the same pattern as the one in your second post:

http://i.imgur.com/FLgkvPP.png (https://imgur.com/FLgkvPP)

Which is also the same as the 'Checkers-422' clip (ProRes_HQ 10bit 422) that was exported from the original image created in Natron. So Natron must use the same sub-sampling modality too:

http://i.imgur.com/1pQI4ewm.png (https://imgur.com/1pQI4ew)

What's confusing me is that when I use AVISynth+ to do the 444 > 422 conversion with 'bilinear' chroma-resampling and then encode to v210 with VDub2, the pattern of results is exactly the same as when the conversion is done in VDub2 (i.e. importing the original Checkers-444 clip).

http://i.imgur.com/itsMacg.png (https://imgur.com/itsMacg)

FFVideoSource("{Path}:\checkers-444.mov", fpsnum=25, fpsden=1, threads=1)
Converttoyuv422(interlaced=false, chromaresample="bilinear") # which VDub2 decodes to p210

So I'm left wondering, if your interpretation of the 'Vegas' pattern is 'Bilinear' (by definition) then why is the AVISynth 'Bilinear' re-sampler giving this other pattern that results from "each pixel being convolved with kernel 0.25, 0.5, 0.25 "(summed area) ?

Had a look at the AVISynth 'Resampling' docs to see what I could glean, but I'm none the wiser:

http://avisynth.nl/index.php/Resampling#Example:_the_bilinear_resampling_filter_-_downsampling

Is this other 'summed area' modality a variant of Bilinear or something different altogether ? I've seen mention of a so called 'area averaging' method of sampling (as distinct from 'Bilinear') but only in the context of image scaling algorithms.

https://superuser.com/questions/375718/which-resize-algorithm-to-choose-for-videos

Could you point me to any references that explain, and ideally illustrate this more fully ?

Edit: Here also, but again in relation to resolution scaling:

http://www.enfocus.com/manuals/UserGuide/PP/10/enUS/en-us/concept/c_aa1135518.html#c_aa1135518

FFMPEG also:

https://ffmpeg.org/ffmpeg-scaler.html#toc-Scaler-Options

But nothing I can find relating to 444 > 422 sub-sampling specifically.

[poisondeathray]

@WorBry - The vegas/natron/resolve15.1 histogram pattern in your screenshot looks very close to the "box" kernel using fmtc in vapoursynth

https://i.postimg.cc/XXRgs5K7/vpy-fmtc-box000000.png (https://postimg.cc/XXRgs5K7)


clip = core.lsmas.LibavSMASHSource(r'F:\checkers-444.mov')
clip = core.fmtc.resample(clip, css="422", kernel="box")
clip = core.fmtc.bitdepth(clip, bits=10, dmode=1)
clip.set_output()


1 frame video sample (zipped) for non vpy users
https://www.mediafire.com/file/td58t1or1a555k4/v210_fmtc_box_dmode%3D1.zip/file

Not sure what the equivalent is in avisynth. I thought maybe avisynth dither tools (same author) could do it , but I can't get it to do it properly, it's csp for dither_resize16 only does 8bit formats like "YV16", not YUV422P10

[WorBry]

I wondered about Box also, but it's not one of the chromaresample options given for AVISynth Convert and I'm not set up for VapourSynth.

Reassuring at least to find that Resolve now behaves in the same manner as Premiere Pro, as it makes for consistent 422 sampling outcomes on export from 444 and 422 inputs. I don't how, but that's the observation from these 'pass-through' tests.

[poisondeathray]

Actually you can do it with avs+ using dither tools, if you use the stacked format

I think Firesledge (aka Cretindesalpes) retired from avisynth stuff before avs+ became more stable (where you can use native formats now), so you can use the hacked 8bit MSB/LSB stack format (which was used for higher bit depth formats when he was active) ; I don't think dither tools was updated for the native pixel formats


LsmashVideoSource("checkers-444.mov", format="YUV444P10", stacked=true)
Dither_resize16(1920,1080, kernel="box", csp="YV16")
ConvertFromStacked(bits=10)


There are some slight histogram differences, but it's quite close. Might be some minor dithering or rounding differences

[WorBry]

@WorBry - The vegas/natron/resolve15.1 histogram pattern in your screenshot looks very close to the "box" kernel using fmtc in vapoursynth

https://i.postimg.cc/XXRgs5K7/vpy-fmtc-box000000.png (https://postimg.cc/XXRgs5K7)


It does doesn't it. I'll look at this some more tomorrow.

[shekh]

Sorry for confusion, here is illustration

https://i.postimg.cc/1t4WN1pc/resize2.png

I did not write the original algorithm in VD, only filled missing parts to communicate with higher precision formats. Overall it is the same in 8-bit, I don't think you have to stick to high bit depth to experiment with resampling.
By nature downsampling and upsampling are resizing of image applied to chroma planes. The differences are in small detail what filters are selected, subpixel offsets etc.

It seems I used wrong terms in wrong places.
All chroma resampling in VD is called "linear" and applied independently in with/height. Also there is "interpolation only". It seems Avisynth bilinear is exactly the same as VD "linear".
The second picture ("sony") should be called "bilinear interpolation" (not same as "bilinear resampling"). Or is it plain averaging?

This definition sounds correct: "Bilinear interpolation uses a 2x2 environment of a pixel and then takes the average of these pixels to interpolate the new value. It's not the best algorithm, but rather fast." = "sony".

Bilinear resampling averages more pixels by applying weights which fall off in linear law. By coincidence, in this example 0.5, 1, 0.5 are exactly pixel areas if you draw a box around them. Thus you could call it "Area averaging" but it behaves differently with other scales.

[WorBry]

Thanks Shekh,

So if I understand correctly, your interpretation of the 'Sony Vegas' (Resolve 15.1, Natron) Checkers-444 > v210 pattern holds - "blends max 2 neighbor pixels as opposed to summed area" - and that is what the lower diagram illustrates:

https://i.postimg.cc/1t4WN1pc/resize2.png

That also fits with a definition of Bilinear Interpolation - "....uses a 2x2 environment of a pixel and then takes the average of these pixels to interpolate the new value. It's not the best algorithm, but rather fast." Did that definition come from Sony btw ?

The other pattern observed with VDub2 represents Bilinear Resampling where "each pixel convolved with kernel 0.25, 0.5, 0.25" (corresponding to the top diagram), which is consistent with the 444 > 422 results obtained with AVISynth using the 'Bilinear' re-sampler, along with Resolve 15.1.2 and Premiere Pro.

@PDR. Many thanks also. I think you've clinched it.

The vegas/natron/resolve15.1 histogram pattern in your screenshot looks very close to the "box" kernel using fmtc in vapoursynth

https://i.postimg.cc/XXRgs5K7/vpy-fmtc-box000000.png (https://postimg.cc/XXRgs5K7)


It does doesn't it. I'll look at this some more tomorrow.

I ran the AVISynth scipt you posted:

LsmashVideoSource("checkers-444.mov", format="YUV444P10", stacked=true)
Dither_resize16(1920,1080, kernel="box", csp="YV16")
ConvertFromStacked(bits=10)

Here's the scope profile and checker pattern of the resulting v210 encode compared to your VapourSynth 'v210_fmtc_box_dmode=1' clip, the Resolve 15.1 export and original 'Checkers-422' (ProRes_HQ) clip. They match up very well don't they.

http://i.imgur.com/SvjFnC2m.png (https://imgur.com/SvjFnC2)

I also compared the AVISynth 'Box Kernel' v210 vs Resolve 15.1 v210 export with quality metrics and the SSIM and PSNR scores are not too shabby either:

http://i.imgur.com/aR0pxlL.png (https://imgur.com/aR0pxlL)

That's the one - it's 'Box Kernel' resampling.

So does that tally with '"blends max 2 neighbor pixels as opposed to summed area" ?

If so I think we can marked this up as "solved".

Edit: I'm also able to replicate the behavior observed when the Checkers-422 clip is 'pass-through' exported to v210 in Resolve 15.1

LSMASHVideoSource("{Path}:\checkers-422.mov", format="YUV422P10", stacked=true)
Dither_resize16(1920,1080, kernel="bilinear", csp="YV24")
Dither_resize16(1920,1080, kernel="box", csp="YV16")
ConvertFromStacked(bits=10)

http://i.imgur.com/9hw3gLgm.png (https://imgur.com/9hw3gLg)

Which confirms Bilinear up-sampling to 444 on import and Box sub-sampling to 422 on export.

It was that behavior which sparked this study in the first place as it was deemed to reflect sub-optimal 422 chroma sub-sampling.

[shekh]

@WorBry
Yes, you understood me right.
"Did that definition come from Sony btw" - it is from answers from stackexchange link you gave above, from explanation of ffdshow filters.

When just 2 pixels are averaged there is not enough information to guess original intent. Both the results can be from box filter but with different chroma location.

[WorBry]

@WorBry
"Did that definition come from Sony btw" - it is from answers from stackexchange link you gave above, from explanation of ffdshow filters.


So it is :o

Thanks again.

[WorBry]

@ poisondeathray. Here's another eye-opener:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=79163&start=100#p448972

[shekh]

to describe the distortions, I think it's the best to show as a video. Depending where the window of VirtualDub is, the preview 'moves' and you can create that "winning solitair" effect (or crashing IE on windows95, you know...).
Check the video: https://www.dropbox.com/s/ri897y11tfkh3ai/virtualdub.mp4?dl=0


Just noticed same issue. DirectDraw display + vsync = wrong window offset.
For some reason vsync is enabled in capture preview, disabled otherwise.
Turns out this is bug in code, not hardware/drivers related.

[lansing]

Reporting a few bugs.

In capture mode, the video levels window can be opened infinite instance instead of just one.

And when I changed the exposure value in the levels setting and start capturing, the exposure value was reset back to the previous value from the "capture filter" instead.

Also, when capture is running, clicking "file->exit capture mode" did not work.

[Morku]

Just noticed same issue. DirectDraw display + vsync = wrong window offset.
For some reason vsync is enabled in capture preview, disabled otherwise.
Turns out this is bug in code, not hardware/drivers related.

Did you change anything related between 42699 and 42711 with Capture AVI...?

Because with the recent version, no matter what I try, I don't get a preview image at all anymore, not even the distorted "Display with Filters" works. I tried all the tricks with disable audio record and back, but no luck. Only the Cropping window shows a preview, which is sadly usless for me.

Revert back to 42699 works and I get my preview. So currently I will keep the older version for capturing avi.

What's also weird, when "Display with Filters" is enabled in current version, moving the VirtualDub2 window around is choppy (like 30fps). When Overlay, the window moves smoothly with my 60Hz monitor refresh rate.
The 42699 does not show that issue. It shows the distorted preview (which is always fixed, when starting capturing), but the VirtualDub2 windows moves with 60Hz.

[shekh]

This is strange. The changes between these versions are minimal and not related to capture or display.
Try moving 42711 to another folder, I saw somewhere that it has effect (maybe drivers keep some crappy settings per exacutable path).
The quoted DirectDraw bug fix is not yet published but you can avoid it: enable dx9 display, or disable vsync

[Morku]

You are right, moving folder seems to affect this. VirtualDub is normal on my D: drive and for testing, I had the previous version on C:. Rebooting PC also seems to help.
So it's not version related. Ignore the post :)

[wonkey_monkey]

Previous versions of VirtualDub would automatically open a whole image sequence if you dragged the first image onto it, but it doesn't seem to do this any more. Is there a preference I can't see, or has this functionality been removed?

[shekh]

Previous versions of VirtualDub would automatically open a whole image sequence if you dragged the first image onto it, but it doesn't seem to do this any more. Is there a preference I can't see, or has this functionality been removed?

My bad. I repeatedly find this annoying but keep thinking this is legacy behavior. Will fix.

[SeeMoreDigital]

My bad. I repeatedly find this annoying but keep thinking this is legacy behavior. Will fix.Thanks

[shekh]

Previous versions of VirtualDub would automatically open a whole image sequence if you dragged the first image onto it, but it doesn't seem to do this any more. Is there a preference I can't see, or has this functionality been removed?

fixed

Reporting a few bugs.

In capture mode, the video levels window can be opened infinite instance instead of just one.

And when I changed the exposure value in the levels setting and start capturing, the exposure value was reset back to the previous value from the "capture filter" instead.

Also, when capture is running, clicking "file->exit capture mode" did not work.

Added fixes for menus. Actually, the whole menu does not reflect "capturing" state, most commands are simply ignored. Now "exit capture" works, and also "device disconnect".
For the exposure I have no idea. Maybe there is bug in driver.

[shekh]

Some new/recent stuff: Audio display was significantly polished and got some new controls: https://sourceforge.net/p/vdfiltermod/wiki/AudioDisplay/
I like the possibility to scroll it left-right. Before it felt barely useful because of continuous glitches. Now I even enabled it to sync with preview (however, this is only possible with caching input driver now because of multithreading problems).
If anyone has ideas what to tweak in audio display it is good time :)

[wonkey_monkey]

Very nice!

[wonkey_monkey]

I just updated and now I find that VirtualDub2 remembers zoom levels from when I last closed it. This, I think, is different to the previous behaviour, where files were always first opened at 100%.

Is there an option to control this?

[shekh]

There is no option. Previously it was not always consistent, was able to remember "auto-size" until you touch anything.
The option would be "remember auto-size and zoom", not big deal to add.

[wonkey_monkey]

I would suggest such an option should be off by default - if you open VirtualDub2 after weeks or months, you would expect it (by default) to show a view of the file unaffected by what you may have been working on last time. Principle of least surprise rules here :)

[StainlessS]

I would suggest such an option should be off by default - if you open VirtualDub2 after weeks or months, you would expect it (by default) to show a view of the file unaffected by what you may have been working on last time. Principle of least surprise rules here :)

+1 on that.

[wonkey_monkey]

Might there one day be support for AviSynth+'s Planar RGB colourspaces?

[kolak]

Is Vdub width restriction to be mod 16 for Cineform due to codec or Vdub limitations? I thought Cineform can be any frame size.

[shekh]

Might there one day be support for AviSynth+'s Planar RGB colourspaces?

Planar rgb is internally supported, so the question is how to bridge it with avisynth. I'm not sure if vfw output from avisynth already handles them, probably not.

[shekh]

Is Vdub width restriction to be mod 16 for Cineform due to codec or Vdub limitations? I thought Cineform can be any frame size.

It is Cineform limitation. I enforced it after discovering a crash with wrong size (in my early builds the limit was not checked).

[kolak]

Is it hard limitation in codec design which can't be overwritten?

[shekh]

Can't tell exactly, it didn't look simple.
Better to ask on https://github.com/gopro/cineform-sdk
There may be possibility to use metadata-based cropping in the codec (not supported by vd2)

[pinterf]

Planar rgb is internally supported, so the question is how to bridge it with avisynth. I'm not sure if vfw output from avisynth already handles them, probably not.
It's supported but I couldn't test it, search for
OPT_Enable_PlanarToPackedRGB on avisynth.nl

[shekh]

It's supported but I couldn't test it, search for
OPT_Enable_PlanarToPackedRGB on avisynth.nl

Looks like I can add G3/G4 fourcc's, btw where is vfw export in the source code?

[pinterf]

Looks like I can add G3/G4 fourcc's, btw where is vfw export in the source code?

Start of export
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/main.cpp#L1144

Planar RGB plane order is GBR
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/main.cpp#L1251

Planar RGB FourCCs
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/main.cpp#L1638

[shekh]

Start of export
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/main.cpp#L1144

Planar RGB plane order is GBR
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/main.cpp#L1251

Planar RGB FourCCs
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/main.cpp#L1638

Thanks

[StainlessS]

Hi Shekh, I've just (for the first time) gotten a "neighbor solicitation" alert from my firewall (Comodo) saying VirtualDub was attempting to connect to the internet, just curious, what was it doing ? (I've set it as blocked application anyway).
EDIT: Image
https://i.postimg.cc/r0kpVzFZ/Untitled.jpg (https://postimg.cc/r0kpVzFZ)

[shekh]

Maybe it is some 3rd party activity like codec or plugin checking for update? I did nothing that can access internet.

[StainlessS]

I have blocked non-essential windows system (W7) from accessing internet, maybe it was trying to connect to HQ by the back door.

Thanks for your answer, glad I blocked it, I nearly let it through.

[lansing]

Hi I encountered a bug. I have a 1440x1080i video with a DAR 16:9, when I load it into Virtualdub, it was displaying it as 16:9. But when I do a "copy output frame to clipboard", it was copying the original 4:3 ratio. The program is not copying what I saw in the preview panel.

[LigH]

Usually the content will be copied with stored dimensions (here: 1440×1080 pixels), regardless of the display AR, because deskewing would alter the frame content (pixel values would depend on the scaling kernel). I would say it is not a bug, it is working as intended. Deskewing is a convenience for the human audience, but in case you want to analyse technical content, you will need a 1:1 copy of the content as it has been encoded/stored/decoded.

[groen]

Is it possible to batch process a direct stream copy? I can't seem to find that option. I have a x264 with a french and english audio track and I want to stream copy making the english audio track the only audio track.

I can do a single video file fine but I have about 100 to do. Thanks.

[LigH]

This would be a job for a CLI multiplexer for your desired container format (e.g. MP4: MP4Box, or MKV: mkvtoolnix); or possibly ffmpeg as universal tool. But VirtualDub2 is for interactive editing.

[shekh]

Is it possible to batch process a direct stream copy? I can't seem to find that option. I have a x264 with a french and english audio track and I want to stream copy making the english audio track the only audio track.

I can do a single video file fine but I have about 100 to do. Thanks.

If you can do a single job it should also work for multiple files. First setup everything for one video, then go to batch wizard.