Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VirtualDub, VDubMod & AviDemux

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th January 2017, 17:36   #121  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
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.
dipje is offline   Reply With Quote
Old 4th January 2017, 18:10   #122  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
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.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 4th January 2017, 18:38   #123  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
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+?
dipje is offline   Reply With Quote
Old 4th January 2017, 19:26   #124  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by dipje View Post
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
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 7th January 2017, 22:36   #125  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by shekh View Post
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?
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 7th January 2017, 23:03   #126  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
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
__________________
VirtualDub2

Last edited by shekh; 8th January 2017 at 22:16.
shekh is offline   Reply With Quote
Old 7th January 2017, 23:16   #127  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Then I request Y416 support for input. That could come in handy later when I test things.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 7th January 2017, 23:24   #128  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by Myrsloik View Post
Then I request Y416 support for input. That could come in handy later when I test things.
Yes, I was thinking of it.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 8th January 2017, 22:22   #129  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by Myrsloik View Post
Then I request Y416 support for input. That could come in handy later when I test things.
Quote:
Originally Posted by Myrsloik View Post
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?
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 8th January 2017, 22:36   #130  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by shekh View Post
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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 8th January 2017, 23:43   #131  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
@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!)
dipje is offline   Reply With Quote
Old 8th January 2017, 23:46   #132  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
I think I always write 0 to the alpha. This should probably be changed for some output formats like b64a...
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 11th January 2017, 00:50   #133  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
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.)

Last edited by jpsdr; 11th January 2017 at 00:53.
jpsdr is offline   Reply With Quote
Old 11th January 2017, 01:15   #134  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
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.
__________________
VirtualDub2

Last edited by shekh; 11th January 2017 at 01:17.
shekh is offline   Reply With Quote
Old 11th January 2017, 10:00   #135  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
Quote:
Originally Posted by shekh View Post
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.

Last edited by jpsdr; 11th January 2017 at 10:17.
jpsdr is offline   Reply With Quote
Old 11th January 2017, 10:50   #136  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
It is easy to find by yourself, look here https://github.com/shekh/VirtualDub2...c/h/vd2/plugin

Quote:
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.
__________________
VirtualDub2

Last edited by shekh; 11th January 2017 at 10:53.
shekh is offline   Reply With Quote
Old 11th January 2017, 11:30   #137  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
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.
jpsdr is offline   Reply With Quote
Old 11th January 2017, 12:44   #138  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
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).
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 11th January 2017, 12:58   #139  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
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.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 11th January 2017, 14:37   #140  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
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.
jpsdr is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:34.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.