Do you plan to update the Vdub version of the pluggin ?
I mean, Vdub have made several update, but pluggin have not
follow.
- No 64bits version.
- Still no support of direct YCbCr format VDub allow now since a
long time.
- Vdub now support High depth bit color on some format.
If there is some compatibility problem with avisynth (64bits and/or
YCbCr and/or high depth bit color), you still can sell on the same
package a specific avisynth version of the pluggin, and a specific VDub
version of the pluggin.
It's too bad that VDub evolve with great new functionnalities, but the
pluggin is still stick with the olds.
Yes, we plan to update all versions including the VirtualDub version. It just takes time because we support many hosts now, every host application has its own set of new features, that are not always the same and require some special adjustments. We try to support them all but this takes time. For example, the Mac versions of NV have been waited by Mac users for a long time and have been developed only recently. They still require a lot of our attention, and we get many requests as well, because Mac users want Neat Video too. Anyway, we will update the VirtualDub version too and will most likely support at least some of the points you have mentioned. This is in the works, as soon as it is ready, the updates will go online.
Thanks for your answer.
I was however mistaken on one point. Even if VDub can input and
output high depth bit color, it can't process them in the chain
filter.
Maybe this will be done by A.Lee in the future, but nothing
for now.
Do you plan to support/work on native 4:2:2 (YUY2 for exemple) or in 4:2:0 (YV12), wich will :
- Avoid unecessary RGB convertion (not the most critical point).
- Greatly speed-up things (4:2:0 is 2 twice smaller in data size than 4:4:4) (most critical point).
Not for the very next update. BTW, the conversion does not really slow rendering down. The slowest part is the filter itself, while conversion takes just a few percents. So we mostly work on speeding up the filter itself.
I thought it worked independantly on each plane, that filtering process didn't correlate data between each plane, so, there was no need for each plane to have the same size. Indeed, if when filtering Y for exemple, the filter don't need data from Cb and/or Cr, i don't understand in that case, why Cb and Cr should have the same size than Y
Many possible designs of filter are of course possible, including with independent planes and their sizes. In our case, all planes must be of the same size, at least in the current version of the algorithms.
