Unofficial VirtualDub Support Forums [Powered by IB Forums]

Printable Version of Topic
Click here to view this topic in its original format

Unofficial VirtualDub Support Forums > Testing / Bug Reports > Video Filter Branching Support

Posted by: phaeron May 29 2011, 03:09 AM

Alright, I've been dark for quite a while, but I've gotten things in my dev tree to the point that I'd like some feedback. Here's 1.10.1 test-8:

http://www.virtualdub.org/beta/VirtualDub-1.10.1-test8.zip
http://www.virtualdub.org/beta/VirtualDub-1.10.1-test8-src.7z
http://www.virtualdub.org/beta/VirtualDub-1.10.1-test8-AMD64.zip

The reason I'm posting this here instead of in the pinned thread is that this version contains some big and possibly flaky changes that I'd like specific feedback on. The changes are:

Video filters can now read from more than one input. There is still no support right now for bringing in more than one video file, but you can branch and then re-merge in the filter chain (basically, now a filter graph).
There are two new filters: blend layers and merge layers. Blend layers does a Photoshop-style merge of one layer into another, whereas merge layers does a blend between two inputs using a third input as a mask. Currently these are RGB only, but they are both 3D acceleration enabled.
The video filter chain dialog now allows you to name outputs and add inputs to filter instances, by a new set of context menu options (right-click). This is how you manage branching in the filter chain. The reason I did it this way was to avoid complicating the simple linear case, but the interface is still clunky and I don't like it much. Opinions are desired here, particularly if it would be worthwhile to switch over to a filter graph UI like for the audio filters, or if there's some way that a list UI might be made preferable.
This version introduces a new version of the video filter API, V16. This version is different than previous versions in that it contains explicit deprecation code. If your filter announces itself as V16 or higher, you can no longer use the legacy bitmap structure (VBitmap) or last frame (FILTERPARAM_NEEDS_LAST), you must use FILTERPARAM_SUPPORTS_ALTFORMATS, and the output default is changed to flexible output pitch (mpPixmapLayout->mPitch = 0). The reason for this is to try to start getting rid of some of the older stuff that's a pain to continue supporting. However, I ran into more difficulties than usual porting the internal filters, so I'm considering changing this. I'd like to know some thoughts on this. There is no official documentation for this yet as I'm still in the process of moving the plugin SDK docs to use XSLT instead of my lousy homebrew generator. Also, the V16 API is not final yet.
V16 filters can now reliably prefetch zero source frames for a given output frame, to break unnecessary source dependencies. This is not allowed for V15 and earlier as previous versions of VirtualDub don't handle it very well.
VirtualDub now enables the V6 common controls, and therefore picks up visual styles. My concern with regard to compatibility still applies, but the reason I was forced to move over is that I discovered Microsoft has started breaking the V5 common controls with Windows 7, such as smooth column scrolling no longer working. This means that plugin authors need to make sure their UIs work with the V6 common controls (which mainly means don't use monochrome bitmaps).
3D video filter acceleration changes:
- Prevents display from going to sleep while active.
- Now uses Direct3D9Ex on Windows Vista and Windows 7, which means that accelerated filtering no longer halts rendering with an error if the workstation is locked or if you log in over remote desktop. Sorry, folks using XP or earlier, not enough API support in the older versions.
- Minor optimizations to YUV upload.
- The grayscale filter now supports 3D acceleration (hey, I was using it for testing).
All video filters are now available in the AMD64/x64 version. Some of them are still unaccelerated, but they're all ported.

Posted by: jpsdr May 29 2011, 07:52 AM

Thanks for these updates.
Just to notify : Link for the source code doesn't work.

Posted by: phaeron May 29 2011, 07:43 PM

Oops, wrong extension. Fixed.

Posted by: jpsdr May 30 2011, 09:08 AM

I've just, out of curiosity, done the following :
Configure input and output to 420 interlaced BT601 Limited and create a TFF RGB cube.
- Adding Null filter, indeed, input/output stay 420i.
- Adding Deinterlace filter or Resize filter with interlaced checked, both forced a 444 conversion...
Well, at least, until fully support of the feature, only convert to 422, 444 seems a litle "too much".
I must said that with deinterlace i was expecting 420 output, and resize to stay 420i.

Maybe you plan to support it in the future ?

Edit : Is it normal to have the [C] almost always displayed when no conversion is needed ?

Posted by: jpsdr May 30 2011, 02:08 PM

First little feedback.

I've updated all my filters to fully use all the new parameters for format.

I've tested the follwing : I want to convert 420-601 to 420-709, and doing some process where i need RGB.
So, i've configured : Input in 420-601 Limited interlaced, output to 420-709 Limited (not interlaced).

Played with all my filters, everything seems to be fine, except that there is the [C] displayed, even when input format is handle by the filter...
In the almost end of my process, i've the ouput to 444-709.
Now, i add your convert format to YV12, and displayed is 420 (not 420-709).
So, my question is : What finaly happend ? Has the video be converted back to BT601 against my will ?
Will the output be re-converted to BT709 even if not needed ?

If i input an 422-709 in your resize filter, what will the output be ?

I think in the actual state, it's impossible to use these extended format, as internal filters break things...
Maybe it's my fault, and i was too hasty, and it's not something you intended to do now.

Posted by: phaeron Jun 5 2011, 09:18 AM

I haven't gone through the internal filters yet to see which ones can have format support expanded.

[C] showing up when no conversion is needed is probably a regression related to me having to rewrite part of the format negotiation code. I fixed some of these before the test release, but if you have specific examples of ones that are still there I'd like to know. The one known and pre-existing exception is that if you have inputs going into a filter that does not support ALTFORMATS, VirtualDub may need to force a conversion to enforce upside down orientation for RGB bitmaps. This shouldn't happen with the internal filters as all of them have been upgraded to the V14 API.

The YV12 selection in the convert format filter selects 4:2:0 Rec. 601 color space. It will be re-converted back to Rec. 709 if you have a later filter or option that requests that.

The resize filter currently only supports the limited excursion, Rec. 601 formats, although adding the additional formats will not be hard.

Posted by: jpsdr Jun 6 2011, 08:28 AM

Resize is just a general question, it's not realy on my needs now, so, don't specialy hurry.

I've just tested the following with one of my filter, code is like this :

CODE

uint32 JPSDR_AutoYUY2::GetParams()
{
bool full_mode,bt709;

if (g_VFVAPIVersion<12) return(FILTERPARAM_NOT_SUPPORTED);

switch(fa->src.mpPixmapLayout->format)
{
/* case nsVDXPixmap::kPixFormat_XRGB1555 :
case nsVDXPixmap::kPixFormat_RGB565 :
case nsVDXPixmap::kPixFormat_RGB888 :
case nsVDXPixmap::kPixFormat_XRGB8888 :
case nsVDXPixmap::kPixFormat_YUV422_YUYV :
case nsVDXPixmap::kPixFormat_YUV422_UYVY :
case nsVDXPixmap::kPixFormat_YUV444_Planar :
case nsVDXPixmap::kPixFormat_YUV422_Planar :*/
case nsVDXPixmap::kPixFormat_YUV420_Planar :
/* case nsVDXPixmap::kPixFormat_YUV411_Planar :
case nsVDXPixmap::kPixFormat_YUV410_Planar :
case nsVDXPixmap::kPixFormat_Y8 :*/
case nsVDXPixmap::kPixFormat_YUV420i_Planar :
case nsVDXPixmap::kPixFormat_YUV420ib_Planar :
case nsVDXPixmap::kPixFormat_YUV420it_Planar :
full_mode=false;
bt709=false;
break;
/* case nsVDXPixmap::kPixFormat_YUV422_YUYV_709 :
case nsVDXPixmap::kPixFormat_YUV422_UYVY_709 :
case nsVDXPixmap::kPixFormat_YUV444_Planar_709 :
case nsVDXPixmap::kPixFormat_YUV422_Planar_709 :*/
case nsVDXPixmap::kPixFormat_YUV420_Planar_709 :
/* case nsVDXPixmap::kPixFormat_YUV411_Planar_709 :
case nsVDXPixmap::kPixFormat_YUV410_Planar_709 :*/
case nsVDXPixmap::kPixFormat_YUV420i_Planar_709 :
case nsVDXPixmap::kPixFormat_YUV420ib_Planar_709 :
case nsVDXPixmap::kPixFormat_YUV420it_Planar_709 :
full_mode=false;
bt709=true;
break;
/* case nsVDXPixmap::kPixFormat_YUV422_YUYV_FR :
case nsVDXPixmap::kPixFormat_YUV422_UYVY_FR :
case nsVDXPixmap::kPixFormat_YUV444_Planar_FR :
case nsVDXPixmap::kPixFormat_YUV422_Planar_FR :*/
case nsVDXPixmap::kPixFormat_YUV420_Planar_FR :
/* case nsVDXPixmap::kPixFormat_YUV411_Planar_FR :
case nsVDXPixmap::kPixFormat_YUV410_Planar_FR :
case nsVDXPixmap::kPixFormat_Y8_FR :*/
case nsVDXPixmap::kPixFormat_YUV420i_Planar_FR :
case nsVDXPixmap::kPixFormat_YUV420ib_Planar_FR :
case nsVDXPixmap::kPixFormat_YUV420it_Planar_FR :
full_mode=true;
bt709=false;
break;
/* case nsVDXPixmap::kPixFormat_YUV422_YUYV_709_FR :
case nsVDXPixmap::kPixFormat_YUV422_UYVY_709_FR :
case nsVDXPixmap::kPixFormat_YUV444_Planar_709_FR :
case nsVDXPixmap::kPixFormat_YUV422_Planar_709_FR :*/
case nsVDXPixmap::kPixFormat_YUV420_Planar_709_FR :
/* case nsVDXPixmap::kPixFormat_YUV411_Planar_709_FR :
case nsVDXPixmap::kPixFormat_YUV410_Planar_709_FR :*/
case nsVDXPixmap::kPixFormat_YUV420i_Planar_709_FR :
case nsVDXPixmap::kPixFormat_YUV420ib_Planar_709_FR :
case nsVDXPixmap::kPixFormat_YUV420it_Planar_709_FR :
/* case nsVDXPixmap::kPixFormat_VDXA_RGB :
case nsVDXPixmap::kPixFormat_VDXA_YUV : */
full_mode=true;
bt709=true;
break;
default : return FILTERPARAM_NOT_SUPPORTED;
}

fa->dst.offset=fa->src.offset;
fa->dst.depth=0;
switch(mData.output_format)
{
case 0 : fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_YUYV; break;
case 1 : fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_UYVY; break;
case 2 : fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_Planar; break;
}
/* switch(mData.output_format)
{
case 0 : if (full_mode)
{
if (bt709) fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_YUYV_709_FR;
else fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_YUYV_FR;
}
else
{
if (bt709) fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_YUYV_709;
else fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_YUYV;
}
break;
case 1 : if (full_mode)
{
if (bt709) fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_UYVY_709_FR;
else fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_UYVY_FR;
}
else
{
if (bt709) fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_UYVY_709;
else fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_UYVY;
}
break;
case 2 : if (full_mode)
{
if (bt709) fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_Planar_709_FR;
else fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_Planar_FR;
}
else
{
if (bt709) fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_Planar_709;
else fa->dst.mpPixmapLayout->format=nsVDXPixmap::kPixFormat_YUV422_Planar;
}
break;
} */
fa->dst.mpPixmapLayout->pitch=0;

if (g_VFVAPIVersion<14) return(FILTERPARAM_SUPPORTS_ALTFORMATS|FILTERPARAM_SWAP_BUFFERS);
else return(FILTERPARAM_SUPPORTS_ALTFORMATS|FILTERPARAM_SWAP_BUFFERS|FILTERPARAM_PURE_TRANSFORM);

}

I've set input color to 420 - interlaced BT601, and created a test video cube interlaced TFF.
The display when i put my filter is :
[C] (640x480) (YUV420i) ......
even if i think video is i think already YUV420i.
Note : I've not noticed [C] displayed only with what i could call "extended format".

QUOTE

The YV12 selection in the convert format filter selects 4:2:0 Rec. 601 color space. It will be re-converted back to Rec. 709 if you have a later filter or option that requests that.

No, trouble is the following :
Without the extended format => without telling what colorspace is, i'm doing the following :
Input/output colorspace is YV12.
Convert YV12 to YV16 with my own filter (AUTOYUY2 vdub version i've made).
Convert YV24 to RGB with my own filter, selecting BT601 as color space in UI. YV16->YV24 is made by vdub, my filter only accepting YV24.
Denoising
Convert RGB to YV24 with my own filter, selecting BT709 as color space. But, we are without extended format, format return is YV24. Even if vdub think it's BT601 when it's not, while i'm not doing in the process something related to colorspace, it doesn't matter.
Converting to YV12 with VDub filter convertion. Color space is not changed, as for Vdub it's the same.

So, finaly, in vdub point of view it's, without using extended format :
YV12 -> YV16 (BT 601)
[C] YV24 -> RGB
RGB -> RGB
RGB -> YV24 (BT601)
[C] YV12 -> YV12 (BT601) (Convert format filter)
=> output YV12 (BT601)

when
in reality, vdub is tricked, and i'll have :
YV12 -> YV16 (BT 601)
[C] YV24 -> RGB
RGB -> RGB
RGB -> YV24 (BT709)
[C] YV12 -> YV12 (BT709) (Convert format filter)
=> output YV12 (BT709)

If i'm using extended format, i'll set input on YV12 BT601 and ouput on YV12 BT709.
Result would probably be :
YV12 -> YV16 (BT 601)
[C] YV24 -> RGB
RGB -> RGB
RGB -> YV24_BT709
[C] YV12 -> YV12 (BT601) (Convert format filter) => my color conversion is broken here, and back to BT601.
=> output YV12_BT709 => vdub would probably re-convert to BT709.
I have to colorspace convertion made i don't want... For optimal video quality, it's not the best...

I think in 1rst time, convertion planar-planar should keep range and colorspace from input.
In 2nd time, convertion filter UI should be a 4 panels radio button like this :
Panel 1 : Mode (RGB,YV24, etc...)
Panel 2 : Color space
Panel 3 : Range (full or not)
Panel 4 : Interlaced or not (enabled/disabled according selection on panel 1 is YV12 or not).

Some internal filters adding extended format should not be hard, just reporting input to ouput, but something like resample would probably need more work, because of output cliping wich could change from (16-235/16-240) to (0-255/0-255) for planar mode, resulting the creation of different processing functions according you're in full range or not... I know, because i've been obliged to do this for one of my filters.

Wich make me just realise : I've try to make my own yadiff according informations you've provided to me, and taking a look at your code. I've noticed problems in my yadiff, some color dots wich appear sometimes. I thought it was 1rst my fault, but i've noticed the same problem in your yadiff filter (a little less than mine), so i thought it was yadiff algorithm. Until very recently someone on forum (here or doom9, don't remember), asked "why for the same pictures, there is dots in vdub result and not on the avisynth version) ?
Could it be something like cliping in yadiff not made properly ?

Posted by: phaeron Jun 12 2011, 10:04 PM

QUOTE

[C] YV12 -> YV12 (BT601) (Convert format filter) => my color conversion is broken here, and back to BT601.
=> output YV12_BT709 => vdub would probably re-convert to BT709.
I have to colorspace convertion made i don't want... For optimal video quality, it's not the best...

Yes, but as I said before, this is what you asked for. The convert format filter currently only lists the original BT.601 formats, and this is what it converted to. I haven't added the options to convert to the BT.709 formats yet.

QUOTE

Wich make me just realise : I've try to make my own yadiff according informations you've provided to me, and taking a look at your code. I've noticed problems in my yadiff, some color dots wich appear sometimes. I thought it was 1rst my fault, but i've noticed the same problem in your yadiff filter (a little less than mine), so i thought it was yadiff algorithm. Until very recently someone on forum (here or doom9, don't remember), asked "why for the same pictures, there is dots in vdub result and not on the avisynth version) ?
Could it be something like cliping in yadiff not made properly ?

I don't think it's clipping, more likely a difference in algorithm. I implemented the filter off descriptions of the algorithm and not code, so it's possible there's something else that's difference. One possible difference I do know about is that I think some versions use bicubic interpolation in one of the axes rather than bilinear, but that is unlikely to produce speckling artifacts. A difference in ELA interpolation could also cause or remove dots.

Posted by: jpsdr Jun 15 2011, 07:49 AM

I've just tested the -10 version, and the [C] is still displayed on all my filters even on all supported formats.
Should i send to you the code of one of my filters for checking ? I don't understand what i'm doing wrong...

Posted by: jpsdr Jul 22 2011, 07:50 AM

I've juste tested, using source of 1.10.0, to update my files of SDK to V15, and re-compile my filters so they could said "I'm a V15 filter".
Nevertheless, the [C] is still displayed on supported format on my filters.
I select colordepth input and output to YV12, create a RGB cube (file is YV12), select one of my filters, and what is displayed is :
[C] 640x480 (YUV420) 640x480 (YUV420) (30fps)
No problem with 1.9.11.

Posted by: jpsdr Jul 22 2011, 09:22 AM

Testing updating to V16 using source of 1.10.1-test11 (My filters now report themselves as V16) => [C] is not displayed anymore.

Edit : But it seems that filters are not working anymore !!!

Edit 2 :
If i keep the code source of 1.10.1-test11 (so V16), but put 15 as version of API in vdvideofilt.h, [C] is displayed again, and filters are working again.
In my update from V15->V16, the following files were modified :
vdvideofilt.h
VideoFilter.h
but not VideoFilter.cpp (wich surprised me a little).

Posted by: phaeron Jul 24 2011, 02:41 AM

If your filter is marked as V16+, the runtime enforces some additional rules:

FILTERPARAM_SUPPORTS_ALTFORMATS is always implicitly set
no framebuffers are bound when startProc runs
paramProc defaults to flexible output pitch / vertical orientation for the output buffer, instead of matching the input pitch and offset

These can break your filter if you were relying on this behavior and you update it to V16. The reason for this is that these are behaviors that I want to deprecate. However, updating the internal filters for this was a PITA so I'm probably going to make at least the first one a runtime check rather than a flag override.

The first one is probably the one that is giving you problems. If you were not setting FILTERPARAM_SUPPORTS_ALTFORMATS, the runtime enforces an upside down orientation and will force a conversion if this is not the case. This still works with filters declaring V15 but is more likely to happen now since all of the internal filters have been updated to V16 and will preserve top-down orientation. This will also absolutely break your filter if you switch to V16 since declining to set this mode is no longer supported in that version.

Posted by: jpsdr Jul 24 2011, 07:50 AM

Here source code of one of my filter not working anymore with V16+:

CODE

uint32 JPSDR_Deinterlace::GetParams()
{
if (g_VFVAPIVersion>=12)
{
�if ((mData.mode==5) || (mData.mode==6))
�{
� switch(fa->src.mpPixmapLayout->format)
� {
� �case nsVDXPixmap::kPixFormat_YUV444_Planar :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar :
� �case nsVDXPixmap::kPixFormat_Y8 :
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar :
� �case nsVDXPixmap::kPixFormat_YUV444_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar_709 : � �
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV444_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar_FR :
� �case nsVDXPixmap::kPixFormat_Y8_FR :
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV444_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar_709_FR : � �
� � break;
� �default : return FILTERPARAM_NOT_SUPPORTED;
� }
�}
�else
�{
� switch(fa->src.mpPixmapLayout->format)
� {
� �case nsVDXPixmap::kPixFormat_XRGB8888 :
� �case nsVDXPixmap::kPixFormat_YUV422_YUYV :
� �case nsVDXPixmap::kPixFormat_YUV422_UYVY :
� �case nsVDXPixmap::kPixFormat_YUV444_Planar :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar :
� �case nsVDXPixmap::kPixFormat_Y8 :
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar :
� �case nsVDXPixmap::kPixFormat_YUV422_YUYV_709 :
� �case nsVDXPixmap::kPixFormat_YUV422_UYVY_709 :
� �case nsVDXPixmap::kPixFormat_YUV444_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar_709 : � �
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar_709 :
� �case nsVDXPixmap::kPixFormat_YUV422_YUYV_FR :
� �case nsVDXPixmap::kPixFormat_YUV422_UYVY_FR :
� �case nsVDXPixmap::kPixFormat_YUV444_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar_FR :
� �case nsVDXPixmap::kPixFormat_Y8_FR :
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar_FR :
� �case nsVDXPixmap::kPixFormat_YUV422_YUYV_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV422_UYVY_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV444_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV422_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV411_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV410_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420i_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420ib_Planar_709_FR :
� �case nsVDXPixmap::kPixFormat_YUV420it_Planar_709_FR : � �
� � break;
� �default : return FILTERPARAM_NOT_SUPPORTED;
� }
�}
}

fa->dst.offset = fa->src.offset;

if (!mData.file_mode)
{
�switch(mData.mode)
�{
� case 2 :
� �if (g_VFVAPIVersion<14) return(FILTERPARAM_SUPPORTS_ALTFORMATS | FILTERPARAM_SWAP_BUFFERS);
� �else return(FILTERPARAM_SUPPORTS_ALTFORMATS | FILTERPARAM_SWAP_BUFFERS | FILTERPARAM_PURE_TRANSFORM);
� �break;
� case 5 :
� case 6 :
� �return(FILTERPARAM_SUPPORTS_ALTFORMATS | FILTERPARAM_HAS_LAG(1));
� �break;
� default :
� �if (g_VFVAPIVersion<14) return(FILTERPARAM_SUPPORTS_ALTFORMATS);
� �else return(FILTERPARAM_SUPPORTS_ALTFORMATS|FILTERPARAM_PURE_TRANSFORM);
� �break;
�}
}
else return(FILTERPARAM_SUPPORTS_ALTFORMATS);
}

And StartProc is with :

CODE

if (g_VFVAPIVersion>=12)
{
�const VDXPixmap& pxdst=*fa->dst.mpPixmap;
�const VDXPixmap& pxsrc=*fa->src.mpPixmap;

�idata.src_h0=pxsrc.h;
�idata.src_w0=pxsrc.w;
�idata.src_pitch0=pxsrc.pitch;
�idata.src_pitch1=pxsrc.pitch2;
�idata.src_pitch2=pxsrc.pitch3;

�idata.dst_h0=pxdst.h;
�idata.dst_w0=pxdst.w;
�idata.dst_pitch0=pxdst.pitch;
�idata.dst_pitch1=pxdst.pitch2;
�idata.dst_pitch2=pxdst.pitch3;

wich later trig the error (_h0/_w0 data are not modified) :

CODE

if ((idata.src_h0<8) || (idata.src_w0<8))
{
�ff->Except("Size must be at least 8x8 !");
�return;
}

Source was an YV12 RGG cube video created with the tools.

Posted by: jpsdr Jul 25 2011, 08:32 AM

It seems that i simply should use mpPixmapLayout and not mpPixmap in Start proc...
(After taking a look at your code).
Now, filter is working, and finaly, [C] is not displayed anymore.

Posted by: jpsdr Jul 26 2011, 08:41 AM

I thought my filters were working fine, until i decided to crop !

In V15, everything work fine, in V16, if i crop, pictures are screwed up !
I'm lost. I don't know what's wrong.
Tested in YV12 mode.

Here globaly for a saturation filter, the process. If you can pleeaaaseeee tell me what's wrong...

CODE

uint32 JPSDR_Saturation::GetParams()
{
if (g_VFVAPIVersion>=12)
{
�if (mData.hue==0)
�{
� switch(fa->src.mpPixmapLayout->format)
� {
� �case nsVDXPixmap::kPixFormat_XRGB8888 :
[........]
� � break;
� �default : return FILTERPARAM_NOT_SUPPORTED;
� }
�}
�else
�{
� switch(fa->src.mpPixmapLayout->format)
� {
� �case nsVDXPixmap::kPixFormat_YUV444_Planar :
[........] � � �
� � break;
� �default : return FILTERPARAM_NOT_SUPPORTED;
� }
�}
}

fa->dst.offset = fa->src.offset;

if (g_VFVAPIVersion<14) return(FILTERPARAM_SUPPORTS_ALTFORMATS);
else return(FILTERPARAM_SUPPORTS_ALTFORMATS|FILTERPARAM_PURE_TRANSFORM);
}

void JPSDR_Saturation::Start()
{
Image_Data idata;

if (g_VFVAPIVersion>=12)
{
�const VDXPixmapLayout& pxdst=*fa->dst.mpPixmapLayout;
�const VDXPixmapLayout& pxsrc=*fa->src.mpPixmapLayout;

�idata.src_h0=pxsrc.h;
�idata.src_w0=pxsrc.w;
�idata.src_pitch0=pxsrc.pitch;
�idata.src_pitch1=pxsrc.pitch2;
�idata.src_pitch2=pxsrc.pitch3;

�idata.dst_h0=pxdst.h;
�idata.dst_w0=pxdst.w;
�idata.dst_pitch0=pxdst.pitch;
�idata.dst_pitch1=pxdst.pitch2;
�idata.dst_pitch2=pxdst.pitch3;
�
�switch(pxsrc.format)
�{
� case nsVDXPixmap::kPixFormat_XRGB8888 :
� �idata.src_video_mode=1;
� �idata.video_mode=1;
� �idata.src_modulo0=idata.src_pitch0-4*idata.src_w0;
� �idata.src_size0=idata.src_h0*4*idata.src_w0;
� �idata.src_h1=0;
� �idata.src_h2=0;
� �idata.src_w1=0;
� �idata.src_w2=0;
� �idata.src_pitch1=0;
� �idata.src_pitch2=0;
� �idata.src_modulo1=0;
� �idata.src_modulo2=0;
� �idata.src_size1=0;
� �idata.src_size2=0;
� �idata.src_full_mode=true;
� �idata.src_color_matrix=MATRIX_NONE;
� �idata.src_interlaced=INTERLACED_NONE;
� �break;
[....]
� case nsVDXPixmap::kPixFormat_YUV420_Planar :
� �idata.src_video_mode=6;
� �idata.video_mode=6;
� �idata.src_h1=(idata.src_h0+1)>>1;
� �idata.src_h2=(idata.src_h0+1)>>1;
� �idata.src_w1=(idata.src_w0+1)>>1;
� �idata.src_w2=(idata.src_w0+1)>>1;
� �idata.src_modulo0=idata.src_pitch0-idata.src_w0;
� �idata.src_modulo1=idata.src_pitch1-idata.src_w1;
� �idata.src_modulo2=idata.src_pitch2-idata.src_w2;
� �idata.src_size0=idata.src_w0*idata.src_h0;
� �idata.src_size1=idata.src_w1*idata.src_h1;
� �idata.src_size2=idata.src_w2*idata.src_h2;
� �idata.src_full_mode=false;
� �idata.src_color_matrix=MATRIX_BT601;
� �idata.src_interlaced=PROGRESSIVE; � � � �
� �break;
[....]
�}
�switch(pxdst.format)
�{
� case nsVDXPixmap::kPixFormat_XRGB8888 :
� �idata.dst_video_mode=1;
� �idata.dst_modulo0=idata.dst_pitch0-4*idata.dst_w0;
� �idata.dst_size0=idata.dst_h0*4*idata.dst_w0;
� �idata.dst_h1=0;
� �idata.dst_h2=0;
� �idata.dst_w1=0;
� �idata.dst_w2=0;
� �idata.dst_pitch1=0;
� �idata.dst_pitch2=0;
� �idata.dst_modulo1=0;
� �idata.dst_modulo2=0;
� �idata.dst_size1=0;
� �idata.dst_size2=0;
� �idata.dst_full_mode=true;
� �idata.dst_color_matrix=MATRIX_NONE; idata.dst_interlaced=INTERLACED_NONE; � � � � � � � � � �
� �break;
[....]
� case nsVDXPixmap::kPixFormat_YUV420_Planar :
� �idata.dst_video_mode=6;
� �idata.dst_h1=(idata.dst_h0+1)>>1;
� �idata.dst_h2=(idata.dst_h0+1)>>1;
� �idata.dst_w1=(idata.dst_w0+1)>>1;
� �idata.dst_w2=(idata.dst_w0+1)>>1;
� �idata.dst_modulo0=idata.dst_pitch0-idata.dst_w0;
� �idata.dst_modulo1=idata.dst_pitch1-idata.dst_w1;
� �idata.dst_modulo2=idata.dst_pitch2-idata.dst_w2;
� �idata.dst_size0=idata.dst_w0*idata.dst_h0;
� �idata.dst_size1=idata.dst_w1*idata.dst_h1;
� �idata.dst_size2=idata.dst_w2*idata.dst_h2;
� �idata.dst_full_mode=false;
� �idata.dst_color_matrix=MATRIX_BT601; � idata.dst_interlaced=PROGRESSIVE; � � � � � � �
� �break;
[....]
�}
}
else
{
[....]
} �
image_data=idata;
}

void JPSDR_Saturation::Run()
{
Image_Data idata;
bool dst0,dst1,dst2,n_dst0,n_dst1,n_dst2;
bool chg_scale_Y,chg_scale_UV;

idata=image_data;

if (g_VFVAPIVersion>=12)
{
�const VDXPixmap& pxdst=*fa->dst.mpPixmap;
�const VDXPixmap& pxsrc=*fa->src.mpPixmap;

�idata.src_plane0=pxsrc.data;
�idata.src_plane1=pxsrc.data2;
�idata.src_plane2=pxsrc.data3;
�idata.dst_plane0=pxdst.data;
�idata.dst_plane1=pxdst.data2;
�idata.dst_plane2=pxdst.data3;
}
else
{
�idata.src_plane0=fa->src.data;
�idata.dst_plane0=fa->dst.data;
�idata.src_plane1=NULL;
�idata.src_plane2=NULL;
�idata.dst_plane1=NULL;
�idata.dst_plane2=NULL;

}
}

The pitch data used in the run procedure is the one get during the start procedure.

Posted by: jpsdr Jul 29 2011, 07:51 AM

After a look at your code, it seems that to solve my problem, i need to add the following in paramProc :

CODE

if (g_VFVAPIVersion>=12)
{
const VDXPixmapLayout& pxsrc = *fa->src.mpPixmapLayout;
VDXPixmapLayout& pxdst = *fa->dst.mpPixmapLayout;

pxdst = pxsrc;
}

if i declare V16, not needed if i declared V15.

Posted by: phaeron Jul 31 2011, 11:25 PM

Sorry for the delay in replying (I'm kind of on a weekend cycle now).

Your fixes are both correct. V16 no longer allows you to access mpPixmap in startProc() because that was requiring the runtime to allocate a buffer just to start the filter, which wasted memory. mpPixmapLayout has been valid there since it was introduced and you should use that in startProc for all API versions that have it.

I changed the default behavior of paramProc() for similar reasons, since the default was causing unnecessary constraints on buffer allocation. You don't actually need to copy the entire struct, just the pitch.