VirtualDub2

[poisondeathray]

Originally Posted by dipje

Ah crap, so what is broken on my system..
With input delivery I mean the same setting as you, intermediate bitdepth.

Do you have / use an alpha channel in all of this ? I'm feeding it 'dry' non-alpha rgb48 which vapoursynth wraps in b64a for VfW. Maybe I should try with a dummy alpha channel.

Another (very minor) thing. Opening a .vpy file now requires me to explicitly select the avisource reader. Just opening the .vpy gives an ffmpeg error, so I guess the ffmpeg input driver tries to open vapoursynth scripts now. This wasn't always the case.

edit might it even that there is an avx(2) codepath or something enabled in the cineform RGB mode that my old i7 doesn't support?

Everything else was exactly the same as your test setup , RGB48 . I tested 1280x720 (maybe you have some weird dimensions causing crash?)

I just dragged the vpy to vdfm , and it automatically chose AVI, with "internal DIB decoder (b64a)" as reported in file=>file information

The CPU I tested on has avx2 . Win8

Was that on XP ? Some ffmpeg changes made XP support more difficult, maybe it has something to do with that ?

[WorBry]

Originally Posted by poisondeathray

For me, it just crashes, regardless of export codec. Both x86, x64 versions

But works ok (without highlight issue) when fed through vapoursynth or avisynth

I think it has to do with the caching input driver

No crash here with that sample clip. And like I said, the odd thing is that:

Originally Posted by WorBry

... it (the aberration) doesn't occur with 4K/HD-AVC (8bit) clips recorded with full luma range i.e. decode format YUV420-709-FS.

....and that includes clips recorded on the same camera - a Pana GH5 in this case, which gives the option to select the 'luminance level' (i.e. luma range) - 16-235, 16-255 or 0-255 in 8-bit. As can be seen from the YUV Histogram, the above sample clip was shot in 16-255 range, which is how most camcorders record 8-bit 4K/HD-AVC also - i.e. Rec709 allowing for excursion/overshoot of data values into the super-whites.

Evidently, with these 16-255 range clips something is going on YUV420-709 > YUV420 or YUYV (YUY2) 'conversion' that is preventing transfer of the full data range. Come to that, why does YUV420-709 need to be 'converted' to YUV420 anyway if the decompression format 'interpretation' is set for 'no change' in the component range ? Surely it's just pass-through ?

Anyhow, hopefully Shekh will get to the bottom of it.

[shekh]

Originally Posted by dipje

Ah crap, so what is broken on my system..
With input delivery I mean the same setting as you, intermediate bitdepth.

Do you have / use an alpha channel in all of this ? I'm feeding it 'dry' non-alpha rgb48 which vapoursynth wraps in b64a for VfW. Maybe I should try with a dummy alpha channel.

Another (very minor) thing. Opening a .vpy file now requires me to explicitly select the avisource reader. Just opening the .vpy gives an ffmpeg error, so I guess the ffmpeg input driver tries to open vapoursynth scripts now. This wasn't always the case.

edit might it even that there is an avx(2) codepath or something enabled in the cineform RGB mode that my old i7 doesn't support?

I'm returning from vacation tomorrow and will take close look after.

Opening vpy issue: maybe you used driver override feature in error, try to see Open dialog, select vpy file, and then change preferred driver to default one (in dropdown there should be AVIfile, then caching..)

avx in cineform: no I don't think there is such code. And I run some tests on core2.

[dipje]

Ok.. I am on (Semi-)recent Win10 x64, so no XP related stuff.

If you want me to report more, give more info or make / send dumps let me know (and let me know how :P).

[shekh]

Originally Posted by WorBry

Something else I've observed with VDFM (40716 32bit & 40717 64bit) ; when transcoding native 4K and HD AVC (8-bit YV12, Rec709) clips to any YUV format, specular highlights get encoded black.
...

Sample (2sec) of above clip to test:
http://www21.zippyshare.com/v/77EZFJQ6/file.html

There is error in color space conversion (it is also in the original VD).
The conversion 709->601 with out-of-range luma values requires clipping which is not applied.
I will replace the procedure.

[WorBry]

Originally Posted by shekh

There is error in color space conversion (it is also in the original VD).
The conversion 709->601 with out-of-range luma values requires clipping which is not applied.

I'm not converting 709 > 601 though. Both the Color Space and Component Range interpretations are set as 'No Change' (the default).

[shekh]

Originally Posted by WorBry

I'm not converting 709 > 601 though. Both the Color Space and Component Range interpretations are set as 'No Change' (the default).

This part of UI is confusing, I want to change it somehow.

Actually "no change" in compression pixel format means nothing.
Currently more informative is the line "Using conversion: YUV420-709 -> YUV420"

To really have no colorspace change, either select "pixel format-> same as decoding" or set colorspace explicitly the same as source (709).

[poisondeathray]

I did some more testing, and the crash for me was from using video=>fast recompress
(You used to be able to bypass all the other extraneous conversions by using it in classic vdub)

I agree that current part of the UI with color space / component range is confusing

[shekh]

Originally Posted by dipje

I have a Vapoursynth script outputting RGB48. If I open it in 40716 (x64) it seems to open fine as B64a (as it should IIRC).

Now, I want to try the Cineform encoder, so I set compression to Cineform RGB 12bit (also tried with RGBA 12bit), with the 'input delivery' set to 16bit. The output format selection seems to be RGB64, which is fine.
When I try to save (either to .avi or to .mov) VDFD crashes directly at the start.

Am I doing something wrong or is this a known problem?

Here is what I need:

- crash report: when you see "Oops - VirtualDub has crashed..." press "Save" button
- also VirtualDub_AutoSave_xxx.vdproject file (created automatically before crash)
- source video. Please save Vapoursynth output as uncompressed avi (1 frame should be enough)

Originally Posted by poisondeathray

I did some more testing, and the crash for me was from using video=>fast recompress
(You used to be able to bypass all the other extraneous conversions by using it in classic vdub)

Repeated, will be fixed.

[WorBry]

Originally Posted by shekh

To really have no colorspace change, either select "pixel format-> same as decoding" or set colorspace explicitly the same as source (709).

OK, I've got it sorted. What confuses matters is the "(?) Format Not Accepted by Codec, YMMV" comment when transcoding to the 'non-native' vfw codec formats, like MagicYUV and the GoPro Cineform codec. I'll post some shots of the config panels to illustrate what I mean, when I have a moment. But yes, when transcoding these 8-bit YUV420-709 sources to Cineform, setting the YUY2 output colorspace explicitly to 'Rec709' resolves the issue with the black-coded specular highlights - the GoPro vfw Cineform codec complains that "(?) Format Not Accepted by Codec, YMMV" but it still works. I guess that's the reason for the 'YMMV' ;>)

[shekh]

Originally Posted by WorBry

OK, I've got it sorted. What confuses matters is the "(?) Format Not Accepted by Codec, YMMV" comment when transcoding to the 'non-native' vfw codec formats, like MagicYUV and the GoPro Cineform codec. I'll post some shots of the config panels to illustrate what I mean, when I have a moment. But yes, when transcoding these 8-bit YUV420-709 sources to Cineform, setting the YUY2 output colorspace explicitly to 'Rec709' resolves the issue with the black-coded specular highlights - the GoPro vfw Cineform codec complains that "(?) Format Not Accepted by Codec, YMMV" but it still works. I guess that's the reason for the 'YMMV' ;>)

Yes, it is difficult to calculate the actual format applied with vfw codec, there is too much code involved. I chose between showing "YMMV" or nothing.

[WorBry]

I was editing my last post just as you replied. I was going to add that when using the native Cineform encoder, setting the YUY2 output explicitly for Rec709 is accurately reflected in the comment 'Using conversion YUV420-709 ->YUYV-709'.

On the other hand, transcoding (these YUV420-709 inputs) to MagicYUV-YUV420 (configured for Rec709 YUV420 input) does not require specifying 'Rec709' in the output pixel format. Leaving at default 'Same as Decoding' (YUV420-709) works fine (pass-through with no black-coded highlights) provided you ignore the "(?) Format Not Accepted by Codec, YMMV" comment. Same with UTVideo YUV420. Well that's 'my mileage' at least

I won't bother posting any screen shots.

Cheers.

[shekh]

New version with many fixes.

Originally Posted by lansing

I encountered a bug, when I loaded in a 32 bit png, adjust the color using colormill, and then export it as single image out as png, the resulting image became all white.

If you do this again, it is now possible to disable alpha channel with "alias format" filter:



Also same way to enable alpha when it is not detected (e.g. from AviSynth)

[lansing]

I'm requesting an option to chose audio driver on capture mode. I have the ASIO driver installed and I wanted to use that instead of the Windows default.

[shekh]

Originally Posted by lansing

I'm requesting an option to chose audio driver on capture mode. I have the ASIO driver installed and I wanted to use that instead of the Windows default.

Which audio driver, is it source or output?

[lansing]

Originally Posted by shekh

Which audio driver, is it source or output?

Source, the latency of audio recording with the Windows default driver is too long. With ASIO, the latency can be as low as 1 millisecond.

[StainlessS]

Hi Shekh,
Build 40898, and my prev 40879, Problem when switch to Free Adjust, image still scrolls around in box (via mouse), you have to screw around with
sizing it to get it to show full image. Ta very much

[shekh]

Originally Posted by StainlessS

Hi Shekh,
Build 40898, and my prev 40879, Problem when switch to Free Adjust, image still scrolls around in box (via mouse), you have to screw around with
sizing it to get it to show full image. Ta very much

Do you mean scrolling 1px or something bigger?

[StainlessS]

Definitely somewhat bigger (I would not bother too much about 1 pixel, maybe 10, 16 something like that, perhaps bigger).
AVI. EDIT: No, I mean AVS.

Starts out ok, but resize via mouse, then switch to Free Adjust, significant scrolling, even when view area is only a quarter occupied.
Can be way more than 16 pixels.

[shekh]

Originally Posted by StainlessS

Definitely somewhat bigger (I would not bother too much about 1 pixel, maybe 10, 16 something like that, perhaps bigger).
AVI.

Weird. Pls show your source dimensions and some screenshots

Edit: ok