VirtualDub2

[dipje]

the AVFS utility to create virtual-avi files was changed to support the high bitdepth-support from avs+ and Vapoursynth (and it's the same utility to read .vpy or .avs files to create virtual avi files).

From what I understand from Myrsloik is that he basically merged the VFW module / support or something. So a good chance it might be working or it is a very small change.

[shekh]

Checked avs+ source, as far as I understand it does not support any high bitdepth with VFW output. AVFS is different piece, can`t be used to open .avs directly.

[dipje]

True. But if it mounts Avi files with high bitdepth formats and your vdub opens those formats, it can't be a big step I guess to make it directly so I'm guessing.
Or is there no VFW interface at all anymore in AVS+?

[shekh]

Originally Posted by dipje

True. But if it mounts Avi files with high bitdepth formats and your vdub opens those formats, it can't be a big step I guess to make it directly so I'm guessing.
Or is there no VFW interface at all anymore in AVS+?

Maybe better to ask this in avs+ thread.
My best understanding:
AVS+ has VFW and native output
AVFS is using native output from AVS
VD is using VFW output from AVS

Meanwhile, it seems VapourSynth can output some compatible formats:
b64a = rgba 4*16-bit (confirmed long ago)
v210 = YUV 422*10-bit
P210 = YUV 422*10-bit
P216 = YUV 422*16-bit

[Myrsloik]

Originally Posted by shekh

Maybe better to ask this in avs+ thread.
My best understanding:
AVS+ has VFW and native output
AVFS is using native output from AVS
VD is using VFW output from AVS

Meanwhile, it seems VapourSynth can output some compatible formats:
b64a = rgba 4*16-bit (confirmed long ago)
v210 = YUV 422*10-bit
P210 = YUV 422*10-bit
P216 = YUV 422*16-bit

The output formats I support in both vsvfw and avfs (if you use avs+ with the vapoursynth version of avfs you can also output most of these formats):
b64a
YUY2
YV12
Y800
YV24
YV16
Y41B (may be buggy, still investigating)
YVU9 (not really tested either)
P010
P016
v210
P210
P216
Y416 (in a debate with madvr author and nevcairiel about the actual component order, I think I'm right though)

Which ones do you support for input?

[shekh]

for input:
I am not sure about old 8-bit formats, have to look in source.
If in doubt it is here: https://github.com/shekh/VirtualDub2...rce/bitmap.cpp

fourcc formats:
YUVY
YUYV
YUY2
YV24
YV16
YV12
I420
IYUV
YVU9
Y8[32][32] (same as Y800)
Y800
v210
P216
P210
Y3[10][10] (AV_PIX_FMT_YUV422P10)
Y3[10][16] (AV_PIX_FMT_YUV422P16)
Y416
HDYC
NV12
b64a
BRA[64] (AV_PIX_FMT_BGRA64)

those in bold intersect with your list

most of it also works for output, with exception of P210,P216

[Myrsloik]

Then I request Y416 support for input. That could come in handy later when I test things.

[shekh]

Originally Posted by Myrsloik

Then I request Y416 support for input. That could come in handy later when I test things.

Yes, I was thinking of it.

[shekh]

Originally Posted by Myrsloik

Then I request Y416 support for input. That could come in handy later when I test things.

Originally Posted by Myrsloik

in a debate with madvr author and nevcairiel about the actual component order, I think I'm right though

I implemented as in MS spec, and the picture looks correct
Current implementation does some not very optimized repacking to convert it to YUV444P16 and drops alpha completely. I assume you don`t expect alpha anyway?

[Myrsloik]

Originally Posted by shekh

I implemented as in MS spec, and the picture looks correct
Current implementation does some not very optimized repacking to convert it to YUV444P16 and drops alpha completely. I assume you don`t expect alpha anyway?

I never return alpha. Mostly because nobody's requested it.

[dipje]

@Myrsloik: But in the b64a data I get back from Vapoursynth / AVFS I have to tell After Effects to ignore the alpha channel, otherwise everything is 100% transparent. Is this just random what it's filled with or do you write some filler data somewhere? If you write alpha data, is it you returning 'full transparent' or is After Effects at fault by interpreting everything as transparent? (Like I said, I can tell AE to ignore alpha, so no big issue at all!)

[Myrsloik]

I think I always write 0 to the alpha. This should probably be changed for some output formats like b64a...

[jpsdr]

Out of curiosity, is there somewhere an update of the last SDK v1.2 (an 1.2a or even more an 1.3) with this new colors formats and property ? I think i may begin to take an interest with these extended color formats for my plugins.
I was thinking is there at least a new vplugin.h with the new VDXPixmapFormat value for new color formats ?
Maybe some changes are made to the VDXPixmap ?
Otherwise, can we just assume for 10-16bits data, that all the informations on the VDXPixmap for exemple are still the same, except that it's 16 bits data pointers instead of 8 bits ?
Is RGB64 top/bottom memory reversed like the RGB32 is ? (Where first line in memory is bottom of picture, when for all others planar mode first line of memory is top of picture.)

[shekh]

There is no update for sdk, but since you indicate interest I will prepare something.
Right now the best I can offer is rgb_levels source code, as it implements RGB64 mode https://sourceforge.net/projects/vdf...s/version%202/

Quick summary
Unfortunately there was no chance to modify VDXPixmap without breaking compatibility (or I was not smart enough) so I had to do some workarounds to access new fields.
Basically yes, for RGB64
format = 57
pitch is doubled
data points to uint16 elements

The rules for memory layout (top or bottom) are valid only for input/output, not for filters.
In a filter you always use data+pitch*y (pitch may be positive or negative)

Also there are some metadata:
alpha_type: alpha may be flagged as present or absent per picture.
value range (ref_r etc): may be 0xFFFF for normalized 16-bit data, or something else.
For example it is 0xFF00 for P210,P216,Y416 sources and 0x03FF for Y3[10][10] sources.
These values are also variable per frame.
A filter may request normalized input for simplicity, to always deal with 0xFFFF.

[jpsdr]

Originally Posted by shekh

There is no update for sdk, but since you indicate interest I will prepare something.

Thanks, but take your time, absolutely no rush.
The first and "only" thing i may need in the begining are just the new several values for the new colors format.
As there is 5 new color formats, it means there is 20 new VDXPixmapFormat values (5 x (Rec.709/601 + Full/Limited).

No, error...
RGBA64 has only one value.
4:2:2-10, 4:2:2-16 and 4:4:4-16 have 4 values (Rec.709/601 + Full/Limited).
4:2:0-16 has 16 values (Rec.709/601 + Full/Limited)x("nothing"/i/it/ib)
Resulting in 1+3x4+16=29 new values.

Edit :
I take a more deep look, it seems that you've added even more color data format (like NV12, I8, etc...). So, finaly, the first thing needed may be the list of all these new values. But again, take time, no rush.
It's something i'm just begining to thought about, so taking thinks quietly.
And not touching VDXPixmap may indeed be a good safe thing.

[shekh]

It is easy to find by yourself, look here https://github.com/shekh/VirtualDub2...c/h/vd2/plugin

kPixFormat_XRGB64 = 57,
kPixFormat_YUV444_Planar16 = 58,
kPixFormat_YUV422_Planar16 = 59,
kPixFormat_YUV420_Planar16 = 60,
kPixFormat_Y16 = 61,
kPixFormat_XYUV64 = 62,

I wanted to stop format explosion, so only 1 format for all colorspaces. Colorspace matrix/range identifiers are attached as metadata to Pixmap.
These are not expected to vary per-frame, and I have no clear plan how to communicate with filter about them. Open for ideas.

edit:
not all formats are meant for filter processing.
Currently only
kPixFormat_XRGB64
kPixFormat_YUV444_Planar16
kPixFormat_YUV422_Planar16
kPixFormat_YUV420_Planar16

edit:
NV12, I8, etc were set before me.

[jpsdr]

Unfortunately it seems you can provide this only with VDXPixmapFormat, so you can't avoid the format explosion for a simple solution.
Otherwise, it seems it involves complex and high risk modifications in VDXFilterActivation or others things like this to be able to provide your FilterModPixmapInfo data to the filter.

It's the easy, and mosf of it, the 100% safe way.

[shekh]

Yes as you can see in rgb_levels it has additional dll exports: VirtualdubFilterModuleInit2, FilterModModuleInit
Details of activation are hidden by c++ wrapper (VDXFrame), with plain C interface it is a bit complex. In no case it has any risk in it.

But this interface was designed with side-by-side development of official VD in mind, now as official VD RIP I think I can drop unnecessary complexity.
Even format id for kPixFormat_XRGB64 was exposed with a function (not constant), now I dropped that idea (too much trouble for nothing).

[shekh]

To clarify, I made extra effort to solve this problem:
possible to make single plugin binary which works
1) with all versions of FilterMod (with features enabled based on availability)
2) with backwards compatible versions of official VD (with FM features disabled)
3) with future/imaginary versions of official VD (with FM features disabled)

now (3) seems useless, and it is what creates most interface trouble.

[jpsdr]

I agree for now for leaving (3).
When i work on updating my plugins, i'll take a look at the code of your plugin, and probably asked you again at this time. Don't need to bother you anymore right now.