AVS Developers: AviSynth 2.5 alpha

[Wilbert]

Try this Release build. It shouldn't be any different from 2.06.

This works!!!

Alternatively try creating the registry entry:

HKEY_LOCAL_MACHINE\\Software\\Avisynth\PluginDir2_5 and set it to an empty directory. (Even though there is only a VERY small chance it'll work).

Doesn't work. Why is there a very small chance that it would work?

[sh0dan]

Great! Just replaced the avisynth.dll with the release build.

Nevermind - it was just to see if that helped - it's just the plugin directory for 2.0 - it cannot be the same as 2.0 (yet), since plugins have to be recompiled!

[sh0dan]

Made resizing work (all of them). Not as fast as possible yet, but still fairly ok. New binary is uploaded. Source is in CVS.

[Wilbert]

Little update. I had Xvid and DivX4 on my computer, and tried to load an avs file in the modified Virtual Dub. Both of them couldn't decompress a YV12 stream (or something else is wrong):

"Couldn't locate decompressor for format 'YV12' (unknown)

VirtualDub requires a Video for Windows (VFW) compatible codec to decompress video. DirectShow codecs, such as those used by Window Media Player, are not suitable."

I will try DivX5 tonight.

[sh0dan]

Yes - I get the same without DivX5 - the best solution would be a Vdub mod, or a huffyuv mod. Avery Lee says he might enable YV12 for 'fast recompress' for 1.4.11, but we still need a decompressor, if we want to be independent of DivX.

[Belgabor]

While you're at breaking filter compatibility, have you added some facility for programs to query info about available filters via avisynth?
(please forgive my ignorance if you already did so ;))

Cheers
Belgabor

[sh0dan]

Not yet, but it's on the TODO-list. I've implemented an experimental "filter info" routine, that nice filters should implement, returning info about the filters (name, author, parameters, etc), but I don't think it's good enough yet - main problem being multiple commands for a single filter. My result so far (used tweak as an example):

AVSValue __cdecl Tweak::FilterInfo(int request) {
switch (request) {
case FILTER_INPUT_COLORSPACE:
return AVSValue(VideoInfo::CS_YUY2|VideoInfo::CS_YV12);

case FILTER_NAME:
return AVSValue("Tweak Filter");

case FILTER_AUTHOR:
return AVSValue("Donald Graft");

case FILTER_VERSION:
return AVSValue("1.1");

case FILTER_ARGS:
return AVSValue("c[hue]f[sat]f[bright]f[cont]f");

case FILTER_ARGS_INFO:
return AVSValue(";0.0,1.0,0.0;0.0,2.0,1.0;0.0,1.0,0.0;0.0,2.0,1.0"); // For floats and integers, use "Min, max, default" ';'delimits parameters

case FILTER_ARGS_DESCRIPTION:
return AVSValue("Input clip;Hue offset;Saturation;Brightness;Contrast"); // Description. Use ';' to delimit.

case FILTER_DESCRIPTION:
return AVSValue("Adjusts color and light levels of your picture depending on your parameters.");
}
return AVSValue(-1);
}


The user should then be able to write:
tweak().filterinfo()

But just a basic call to return the names of all filters would be a beginning.

[trbarry]

I had thought to convert my filters over to 2.5a by first getting the YUY2 flavor to work and then the YV12.

But there appears to be a problem with ConvertToYUY2. For instance the following script will work (with divx.dll conversion):


LoadPlugin("D:\MPEG2DEC3_YV12\MPEG2Dec3_YV12.dll")
mpeg2source("D:\VCR\CTHD\CTHD2.d2v")
return last


But if I try the following one the top half of the screen is black and the bottom is grey (and it crashes):


LoadPlugin("D:\MPEG2DEC3_YV12\MPEG2Dec3_YV12.dll")
mpeg2source("D:\VCR\CTHD\CTHD2.d2v")
converttoYUY2
# I had been going to put a test YUY2 filter here.
converttoYV12
return last


Very confusing.

- Tom

[sh0dan]

@trbarry: Seems like MPEG2Dec3 decodes to I420 (Sames as YV12 but with U&V swapped). It shouldn't matter, but I had forgotten to check for this in the conversion, so data was actually treated as RGB. Try the latest version. It should be fixed now.
Otherwise try AviSource, or colorbars with converttoyv12().

[HarryM]

@Sh0dan:

Mod4? Why?

I think, that YV12 are limited to use (only) mod2 at horizontal and vertical too...

[sh0dan]

It must be mod 4 vertically - otherwise interlaced material will have big problems (different amout of chroma data for each field).
Mod 4 horizontal is to allow filters to have some kind of optimization - otherwise you often end up processing single bytes. You can always convert to YUY2, if you need more precision.

[trbarry]

I don't know what's legal but probably if a frame based clip was vertically size to mod 2 it might be ok. But field based clips seem like they would need vertical mod 4 so each field can be mod 2.

- Tom

[sh0dan]

I'll give the vertical restriction a thought. If it can be implemented so that users don't get strange results, I'll change it back.

[trbarry]

@trbarry: Seems like MPEG2Dec3 decodes to I420 (Sames as YV12 but with U&V swapped). It shouldn't matter, but I had forgotten to check for this in the conversion, so data was actually treated as RGB. Try the latest version. It should be fixed now.

Sh0dan -

Thanks, both YV12 & YUY2 seem to be working now. I posted about it in that other YV12 thread but I've released the test version of my new UnDot() dot removing filter for Avisynth 2.5 alpha.

see:
www.trbarry.com/Readme_Undot.txt and
www.trbarry.com/UnDot.zip (dll and simple YV12 source example)

Back to YV12 MoComp.

- Tom

[HarryM]

Originally posted by sh0dan
It must be mod 4 vertically - otherwise interlaced material will have big problems (different amout of chroma data for each field).
Mod 4 horizontal is to allow filters to have some kind of optimization - otherwise you often end up processing single bytes. You can always convert to YUY2, if you need more precision.

Mod4 'must be' or only 'recommended'?
I think, that mod4 is for many peoples (me too) already too restrictive :(

[sh0dan]

Well, the problem is that filters will get a lot slower when they must consider Mod2 resolutions. The resizer is processing 4 pixels in parallel, and having to restrict it to two pixels wil slow it down considerably.
Spatial filters will also have the possibility to use the mod-4 restriction for optimizations, since it cannot use the mod16 pitch (will lead to garbage pixels on the left).
I can remove the internal restriction, but many filters will not handle mod2 correctly, and I'll not be fixed for the first release of 2.5.

[MaTTeR]

Originally posted by trbarry
I posted about it in that other YV12 thread but I've released the test version of my new UnDot() dot removing filter for Avisynth 2.5 alpha. Tom,

Maybe you mentioned this already in another thread but I didn't find it. Do you have any future plans to add parameters to UnDot such as threshold or strength? Thx again, this filter is wicked fast on my system! YV12 is such a treat to use.

Sorry for being off topic, back on now:)

[trbarry]

No current plans. It's faster this way and I can not find any cases where it is too strong and someone would want to make it weaker. For more elaborate control and greater filtering I would probably instead add new options to STMedianFilter but I won't be making a YV12 version of that soon.

- Tom

[vlad59]

Originally posted by sh0dan
Well, the problem is that filters will get a lot slower when they must consider Mod2 resolutions. The resizer is processing 4 pixels in parallel, and having to restrict it to two pixels wil slow it down considerably.
Spatial filters will also have the possibility to use the mod-4 restriction for optimizations, since it cannot use the mod16 pitch (will lead to garbage pixels on the left).
I can remove the internal restriction, but many filters will not handle mod2 correctly, and I'll not be fixed for the first release of 2.5.

I think I missed something, if avisynth 2.5 require mod4 width you can process 4 luma values in parallel but you can't use the same thing with chroma (in this case it's only mod-2) ?!?! :confused:

My first tests of C3D YV12 require a mod8 width to allow working everytime with 4 values in parallel.

I really should be missing something !

[sh0dan]

ok - I have the following suggestion:

- We allow all mod2 resolutions.
- mod16 (luma) and mod8 (chroma) rowsizes can still be requested using PLANAR_Y_ALIGNED and PLANAR_V_ALIGNED. (thus we keep the mod16 pitch)
- I add a function, that copies the border pixels, if a filter requests it, filling up to mod16. This will never be visible to the users.

This would enable spatial filters to get mod16 widths, and not get garbage, when they read outside the actual image.

Does anyone forsee any problems with height not being mod4/8/16? I can't see any situation where this could be an issue, but I want to make sure.

[trbarry]

I should probably go back and try to stare at that Stacy Spears picture of interlaced YV12 data for awhile. But I'm worried that if you were to crop 2 lines off the top of an interlaced picture then it might not do a subsequent YV12->YUY2 (or anywhere) conversion quite as well, causing a different flavor of chroma bug. But I'm not sure.

- Tom

[sh0dan]

I will make AviSynth refuse to create non-mod4 vertical resolutions, if the video is fieldbased. Creating non-mod4 interlaced YV12 images simply isn't possible.

Furthermore I have updated the documentation on the alpha page, with a description of how to handle YV12 interlaced data properly.

[vlad59]

@Sh0dan

Sorry, it seems I posted a dumb question, I'm somehow too tired ;) ;) ;)

I reread your doc about getRowsize

If I request any rowsize PLANAR_Y(U or V)_ALIGNED you change the PVideoFrame to adapt the pitch to allow working in 8 bytes in parallel. That's right ???

It will be wonderfull if you could add a copy of border pixels.

Sorry again

[sh0dan]

Originally posted by vlad59
If I request any rowsize PLANAR_Y(U or V)_ALIGNED you change the PVideoFrame to adapt the pitch to allow working in 8 bytes in parallel. That's right ???

Yes! It already works this way. When you use src->GetRowSize(PLANAR_Y_ALIGNED) you will always get a mod16 width. Same for src->GetRowSize(PLANAR_V_ALIGNED) - just always mod 8 size. You can already do this!
It will be wonderfull if you could add a copy of border pixels. I've already done it, but it needs a bit more testing.

[Marc FD]

>It will be wonderfull if you could add a copy of border pixels

I'm not sure, but mirroring of border pixels may be better, no ?

[sh0dan]

@MarcFD: I cannot see any reason for this. The only this this extra space will be needed for is spatial processing (blur, etc.). If you think of how you would like the border pixels to be blurred, straight copying will make the most sense, otherwise information on the other side of the pixel will have too much weight.

@All:

Mod2 support will be somewhat limited. Not in AviSynth, but elsewhere.
- DivX only supports mod 4. Images will ALWAYS be heavily distorted when sent through DivX.
- Xvid only supports MOD16 (as far as I can see), mod8 and 4 may be supported, but I'm positive that mod2 isn't. Again I get picture distortion.
- HuffYUV actually only support mod4, therefore, exporting as YUY2 in non-mod4 gives chroma-distortions at the right of the picture. This is also present when using older versions, and since nobody is complaining, I guess nobody uses non-mod4.

So, here is what you get: Internal mod2 support for all filters, and there isn't much excuse for NOT supporting it. BUT you CANNOT export as YV12 or YUY2 in other than mod4. This will give you an error.

I think that it is much better to give an error message to the user, than delivering them invalid data 95% of the time.

[Marc FD]

>I cannot see any reason for this.

i'll explain

>The only this this extra space will be needed for is spatial processing (blur, etc.).

of course.

>If you think of how you would like the border pixels to be blurred, straight copying will make the most sense, otherwise information on the other side of the pixel will have too much weight.

an example :
original pixels :

ABCD

3 pixels border copy :

AAAABCD

3 pixels boder mirroring :

DCBABCD

this way, if you use for ex. a 121 blur kernel, the right pixel would be half A/half B, otherwise, it would be 1/4 B and 3/4 A, and the smoothing is less effective.

it's not _better_, but that's another way of doing it, and i readed that it gived better result quality-wise. maybe not ?

i dunno if it worth it, and it's true that border pixel are almost insignifiant when speaking of a 640x480 pixel image.

just an idea, feel free (not) to use it ^^

[sh0dan]

@Marc: Thanks for the suggestion - since I've already written the code, I prefer to keep it. It can be changed later without any problems.

[vlad59]

Hi all,

here is attached the first beta version of Convolution3D for YV12. Please read the Convolution3DYV12.txt before its use, especially the known problems.

EDIT : As it seems that no modo is around ;) you can also download it here (http://membres.lycos.fr/tempask/Convolution3DYV12.zip)

[HarryM]

Originally posted by vlad59
Hi all,

here is attached the first beta version of Convolution3D for YV12. Please read the Convolution3DYV12.txt before its use, especially the known problems.

EDIT : As it seems that no modo is around ;) you can also download it here (http://membres.lycos.fr/tempask/Convolution3DYV12.zip)

Finally! Thanks!

Can you add into Convolution3D any SCD (Scene Change Detection, for better temporal filtering, optional - ON/OFF), pleaseeee?

[vlad59]

@HarryM

a SCD, That was the job of Temporal influence (disabled for this release but will be enabled soon).

As explained in the .txt :
For each I build a
change limit = Temporal Luma Threshold * Temporal influence
With default values :
Change limit = 8 * 3 = 24

When I compute two pixel, I make a SAD between current, previous and next luma values :


Previous : 104 108
Current : 100 108
Next : 92 107

SAD = abs (100 - 104) + abs (108 - 108) + abs (100 - 92) + abs (108-107) = 4 + 0 + 9 + 1 = 14

14 < 24 so I will use a real 3*3*3 convolution

if not I only do a 3*3 spacial convolution


With this release Temporal Influence is not used at all but the temporal thresholds should take care by itself of scenechange and not produce any ghosting (if they stay below 10).

I hope I was clear enought ;) ;)

EDIT : sorry for being OT, HarryM if you want that we continue to talk about this could you please post your questions in the Convolution3d V1.00 thread.

Thanks in advance

[rui]

Originally posted by SansGrip
sh0dan: VDub cannot handle YV12 internal

Do you (or anyone else) know if other "destinations" (TMPGEnc, CCE, Nandub etc.) can handle YV12?

I believe not. At least CCE and TMPGEnc. Found the below table at this site: http://web.tiscali.it/benis/dvd/agg3.htm


Cinema Craft Encoder Stand alone:

RGB ---> YES

YUV 4:2:2(YUY2) ---> YES

YUV 4:2:0 (YV12) ---> NO

faster format available:YUV 4:2:2 (YUY2)

[HarryM]

@Sh0dan:

You have wrong link at your Alpha 2.5 page.

Download link is still for 04112002 binaries, but on site exists only 07112002 binaries!

[MaTTeR]

sh0dan,

Is it possible for AVS 2.5 to display the date using version() on your next build? It's very nifty for someone like myself juggling all sorts of versions for testing:) Thx!

[int 21h]

Originally posted by rui
I believe not. At least CCE and TMPGEnc. Found the below table at this site: http://web.tiscali.it/benis/dvd/agg3.htm


Cinema Craft Encoder Stand alone:

RGB ---> YES

YUV 4:2:2(YUY2) ---> YES

YUV 4:2:0 (YV12) ---> NO

faster format available:YUV 4:2:2 (YUY2)

This is because CCE uses DirectShow codecs to decompress the source video, there is no default YV12 codec in Windows, perhaps someone could make a quick one and associate the fourcc of YV12 with it. Then CCE would work with it. (Right now it fails with the error "Could not find appropriate video codec for 'YV12'".

[Marc FD]

i think XVID is registered for YV12 in DShown, no ?
shoudn't be hard to do with the new stuff pete coded.
at least it works very well with VDub ^^
the only problem is, that XviD claims the DIVX and DX50 fourcc. i don't think it's a good idea, how do you do if you want to compare decoders ?
i don't like the idea to use graphedit intensively...

so i need to change the source eaxh time i compile :D .

[sh0dan]

Originally posted by HarryM
You have wrong link at your Alpha 2.5 page.

Thanks - corrected!

[vlad59]

@Sh0dan

Another maybe silly idea.
Another interesting thing added with YV12 is that you can often have the same method called 3 times (one for each plane).

For example in C3D : I got one proc call ProcessPlane and in the GetFrame function, I only call 3 times ProcessPlane (for Y, U and V).

So with this it will be easier to add threading to most avisynth filter. I'm currently testing this with MaTTer and my first tests shows that for my non-SMP box : my threaded version of C3D is slower.

So (I'm sometimes slow to explain), it would be interesting to have a avisynth flag (like the CPU instruction set ones) to tell how many CPU are available.

I hope it's not a silly idea.

[sh0dan]

Doing too fast switching on the same data usually gives a massive overhead due to the added code and cache misses (both CPU's working on the same data).

I _think_ the best way to do SMP would be to process different frames in parallel. That would mean, if the destination program requests frame 'n' , CPU 1 would begin to process frame 'n', and CPU 2 would immediately begin to produce frame 'n+1'. This would mean minimal interaction between CPU1+2. the biggest problem would be when a filter on CPU 1 requests frame 'n+1', then it shouldn't begin to calculate it itself.
I think this could be solved by setting a "being generated flag", so that CPU 2 can finish the frame, and CPU 1 get's the frame when it is done.
There will be some fancy coding needed for this, but I'm pretty sure it will give much better performance than 'micro-SMP', where CPU-switching happends very often.

[vlad59]

@Sh0dan

MaTTer is currently running a full test of C3D SMP, for now he reported a +2-3 fps gain.
but you're right I don't know if the gain would be the same if all filters were SMP.

Anyway I agree on the fact that SMP in avisynth core will be much more powerfull but also much more tricky to build.

Thanks for your clever answer (as always ;) )

[sh0dan]

the new CacheHint feature could also help in cases where you would like the filters to process the data sequencially. (Temporal Cleaner would be a good example).

[HarryM]

I need any deinterlace filter compatible with Avisynth 2.5 (YV12 support).

GreedyHMA_YV12?
Decomb_YV12?
TomsMoComp_YV12?

Do exists anything, please?

[lighty]

Originally posted by HarryM
I need any deinterlace filter compatible with Avisynth 2.5 (YV12 support).

GreedyHMA_YV12?
Decomb_YV12?
TomsMoComp_YV12?

Do exists anything, please?

AFAIK- for the moment there aren't any deinterlace filters ported to YV12 (I am holding some of the encoding I have to make until they're available).
I know that Neuron2/Donald Graft said that he would look to it (Decomb is my favorite anyway) but we're yet to see Decomb ported to YV12.
I am not sure what's been done about porting of GreedyHMA or TomsMoComp.

[HarryM]

Originally posted by lighty
AFAIK- for the moment there aren't any deinterlace filters ported to YV12 (I am holding some of the encoding I have to make until they're available).
I know that Neuron2/Donald Graft said that he would look to it (Decomb is my favorite anyway) but we're yet to see Decomb ported to YV12.
I am not sure what's been done about porting of GreedyHMA or TomsMoComp.


The one of this three filters suffice for me.

[trbarry]

I am not sure what's been done about porting of GreedyHMA or TomsMoComp.

I haven't done anything for a couple days but YV12 TomsMoComp should still be done soon.

GreedyHMA is another matter. I wrote that using a strange internal structure to get around some DScaler limitations at the time. Though it is still fast that somewhat hurts performance and it wouldn't be an easy port, so it is way down on my list. Hopefully a choice of Force Film and a possible YV12 Decomb from Neuron2 will be more than enough that we won't need YV12 GreedyHMA.

And rather than converting Greedy I'd probably just write another one to take advantage of some other IVTC understanding I might have gained since I wrote this.

- Tom

[hakko504]

I'm sorry to hear you won't port Greedy, Tom. I still think it's the best de-interlacer (pure deinterlacer, mode=0) I've compared it with the other deinterlacers again and again, but every time Greedy wins. Note that I prefer blend=false in my encodes of true interlaced films.

[trbarry]

Greedy is really just an early version of TomsMoComp (with SE=1) tacked onto a simple IVTC front end. I'll probably continue to support all these functions but I don't think mods to GreedyHMA are the most effective way to do it. It was my first Avisynth filter but was just a port of DScaler code and things are really more efficient for Avisynth if you know that's the target platform in advance. ;)

So that's why I'm breaking out the functions. TomsMoComp is the next version of the Deinterlace code and UnFilter is an advanced version of the Greedy sharp/soft code, made into separate filters. Eventually I'll probably create something like "UnComb" that has the newest version of the IVTC and deinterlace choice code, both for YUY2 and YV12.

- Tom

[lighty]

Originally posted by trbarry
I haven't done anything for a couple days but YV12 TomsMoComp should still be done soon.

Yes! Yes! Hurry, hurry!!;) I have three movies waiting to encode but alas- we still doesn't have any YV12 deinterlacer. I personally prefer Decomb because I got to know it's options but right now I would get satisfied with anything.:(

[sh0dan]

Originally posted by lighty
we still doesn't have any YV12 deinterlacer. I personally prefer Decomb because I got to know it's options but right now I would get satisfied with anything.:(

You do have the fabulous VerticalReduceby2()!!?!

(ok - I'll shut up now ;)

[WarpEnterprises]

@lighty: where did you find truly interlaced movies? Are you sure they are not only telecined?