AviSynth 2.5 updates

[sh0dan]

Hi!

Thought we should have a thread for posting updates and additions to the 2.5 core - and where these changes could be discussed.

New changes:
- Rewrote temporalsoften for yv12, using mmx/isse. It is now many times faster than yuy2. The new algorithm will be converted to yuy2 later.
- Implemented simple cache hints for temporalsoften - it breaks on release build, therefore some optimizations has been disabled. Still is slightly buggy though, which can affect temporalsoften.
- Implemented histogram for YV12. It now shows out-of-range values with a slightly yellow color. (this is a nice filter!) It no longer automatically converts to yuy2.
- Changed limiter default upper luma value to 236.

I found out that the internal cache is broken - or at least works very badly - it is not the easiest code to understand (probably an understatement), so my opinion is that it should be completely rewritten - doing so would probably be necessary for 2.5 beta, to have it tested properly.

In general I feel we are very close to 2.5 beta. I would like to have compare and convertfps working for 2.5 beta, but I don't understand the code that well, so it'll take some time.

Edit: Would you kill me, if you had to recompile all plugins for 2.5 beta? :rolleyes:

[Wilbert]

Nice! The documentation is also getting ready. I updated the faq (but it still must be commited). The list of functions on www.avisynth.org is updated (although I need to correct some stuff), but I'm still missing descriptions of ColorYUV, Limiter (I know what this one does), AlignPlanar (is this a public filter ?), FillBorder (is this a public filter ?). Maybe you can come over to www.avisynth.org and add them, so that I can copy them to sourceforge. At last syntax.html needs to be updated.

[sh0dan]

Great!!!

> AlignPlanar (is this a public filter ?), FillBorder (is this a public filter ?)

No, and No - these are only for filters and plugins to use. Shouldn't be necessary for users to worry about.

ColorYUV is pretty easy. Most ranges are 0 to 256 with 0 being default (no change).

We still need info(), converttoyv12(), many audio filter updates, YV12 filters:
* SwapUV(clip) - Swaps chroma channels.
* UToY(clip) Copies chroma U plane to Y plane (image is now half as big)
* VToY(clip) as above, but V plane.
* YToUV(clipU,clipV) - puts the luma channels of the two clips as U and V channels. Image is now twice as big, and luma is 50% grey. Use MergeLuma, if you want to add luma values.

AviSource, Blanclip, (others??) take YV12 parameters.

I'll keep coding until the beta release, and then I'll give you a hand with the docs.

[vinetu]

Hi

A question (may be bug report)

For decode VOBs in YV12 collor format
I use MainConcept MPEG2 Video Decoder (it come with MainConcept MPEG2 Encoder)
as DirectShow filter and a simple avs:

DirectShowSource("D:\temp\test.VOB")

and it work correct with "avisynth_250_a_041102.zip",but all
new versions (including "avisynth_a_071202.zip") shifts
the collor channel 16 pixels to the right horizontaly !

if I use YUY2 DirectShow filter (Elecard MPEG2 decoder v.2.0) all
new versions work correctly,but the target here is YV12 .
What you think - it's an incompatibility between Mainconcept DS filter and new avisynth versions(newest than 04 nov 2002)
or it's a bug ?

Edit: if I post to wrong tread - remove my post from here!

vinetu

[Wilbert]

No, and No - these are only for filters and plugins to use. Shouldn't be necessary for users to worry about.

Ah, that's what I suspected. Thx.

We still need info(), converttoyv12(), many audio filter updates, YV12 filters:
* SwapUV(clip) - Swaps chroma channels.
* UToY(clip) Copies chroma U plane to Y plane (image is now half as big)
* VToY(clip) as above, but V plane.
* YToUV(clipU,clipV) - puts the luma channels of the two clips as U and V channels. Image is now twice as big, and luma is 50% grey. Use MergeLuma, if you want to add luma values.

AviSource, Blanclip, (others??) take YV12 parameters.
I already added all this (not on sourceforge yet).

I'll keep coding until the beta release, and then I'll give you a hand with the docs.
Ok.

[Boulder]

A small bug report from here as well (I don't know if there's an official bug report form somewhere) :

TMPGEnc won't load my script properly if I resize to 336x272 and add 8 pixel borders on each side so that the resolution is a standard PAL VCD 352x288. If I just resize to 352x288, it works fine.

Here's the script I tested:

SegmentedAVISource("c:\temp\captures\capture.avi")
ConvertToYV12
BilinearResize(352,288) #works
#BilinearResize(336,272).Addborders(8,8,8,8) #doesn't work

Both methods do work with VirtualDubMod so I don't know what the issue actually is. I prefer adding the borders to benefit from the TV overscan area.

[sh0dan]

If it works in vdub it is _probably_ not an AviSynth error, but probably a conversion or import filter bug - you should converttorgb24 anyway, since this seems to be the format TMPGenc uses anyway.

[Boulder]

The problem couldn't be solved by colorspace conversion, I also tried keeping the colorspace as YUY2 (the original colorspace) with no luck. CCE2.5 seems to accept the script just fine.

[Wilbert]

Thus the following script:

SegmentedAVISource("c:\temp\captures\capture.avi").ConvertToYV12
BilinearResize(336,272).Addborders(8,8,8,8).ConvertToRGB24

results in the same error? What happens if you remove ConvertToRGB24 from this script, remove xvid.dll and install DivX5. Still the same error?

[Boulder]

Originally posted by Wilbert
Thus the following script:

SegmentedAVISource("c:\temp\captures\capture.avi").ConvertToYV12
BilinearResize(336,272).Addborders(8,8,8,8).ConvertToRGB24

results in the same error? What happens if you remove ConvertToRGB24 from this script, remove xvid.dll and install DivX5. Still the same error?

If I rename xvid.dll to xvid.bak, the script produces an error "Floating decimal point is divided by 0" by TMPGEnc (not in the preview window). I already have DivX5 installed so I suppose it should take over then.

If xvid.dll is not removed, TMPGEnc shows that the clip is 360x56 and 24fps. It can be fixed by correcting the values manually but I think that's just an annoying workaround to the problem;)

It works both ways in VDubMod, however.

[HarryM]

Sh0dan: About audio processing in Avisynth. Can you add into avisynth any function for boosting of audio?
E.g. based on LigH formula or HeadAC3he algorithms.

Similar to 'TFM audio filter'. This is great for listening... :D

[Marc FD]

hi ^^

i'm doing "layer" now.
i've analysed the whole thing and... it needs total rewrite.
i'll macroize the good stuff and add YV12 support.

[Marc FD]

YUY2 stuff cleaned. wow, 340 lines less !

i added Sub/Abs operations, first does like avisynth Subtract() and second was asked by someone to do masks if i remember well.

BTW, i'll need some Layer() fans to check functionnnality in YUY2/RGB32/YV12 when it would be finished.

[ErMaC]

Is there any chance we can get track matte support in Layer? Since YUV doesn't have an Alpha Channel, it'd be nice to be able to supply another AVI clip as an Alpha Channel (i.e. as a track matte) so that we don't need to convert to RGB to make use of Alpha Channels.

[Marc FD]

>Is there any chance we can get track matte support in Layer? Since YUV
>doesn't have an Alpha Channel, it'd be nice to be able to supply another
>AVI clip as an Alpha Channel (i.e. as a track matte) so that we don't
>need to convert to RGB to make use of Alpha Channels.

yes, sho0dan already suggested that, and i'll code it for YV12.
i think i can implement it in YUY2 too. the code will even be shorter, because i'll condensate it even more ^^

BTW, in RGB, you have an alpha channel per pixel. in YV12, you'll have 3 alpha channel for each Y,U or V channels

[ErMaC]

Well, really that's probably unnecessary since you probably don't need to blend the planes different amount. ^_^ I assume you'll allow a single clip to be applied as an alpha channel to all the planes?

[Didée]

Originally posted by Marc FD
...i added Sub/Abs operations, first does like avisynth Subtract() and second was asked by someone to do masks if i remember well.
...
Yep, that was me.
I'm glad you actually remembered my suggestion - and by the time you make something available, I will test as much as I can
(though my situation makes this pretty slow: The fastest possibilities for me are from one day to the next ... no chances for quick reports :( )

[Marc FD]

>Well, really that's probably unnecessary since you probably don't
>need to blend the planes different amount. ^_^ I assume you'll allow a
>single clip to be applied as an alpha channel to all the planes?

it'ld be an external function, like UnifyAlphaYV12, because it wouldn't really be faster to downsample the Y plane internally anyway.

if i add this functionnality, it's because it's easier to code, and almost the same speedwise.

>Yep, that was me.
>I'm glad you actually remembered my suggestion - and by the time you
>make something available, I will test as much as I can
>(though my situation makes this pretty slow: The fastest possibilities
>for me are from one day to the next ... no chances for quick reports )

no problem. if you and ErMaC are okay to test/check what i do, i'll feel better. i never used layer, and first time i tested it ("add" op) after i cleaned the code, i thought it was my fault if the chroma was weird. and it wasn't ^__^

[Boulder]

Originally posted by Boulder
If I rename xvid.dll to xvid.bak, the script produces an error "Floating decimal point is divided by 0" by TMPGEnc (not in the preview window). I already have DivX5 installed so I suppose it should take over then.


I noticed this thing also when trying to load an DivX file. TMPGEnc stated the same error message and when I went to the source range screen, it showed the Avisynth error "Unrecognized exception" which pointed to the line where I resized the clip.

So, if I resize this clip to 336x272 and add 8 pixel borders on each side and get 352x288, it doesn't work in TMPGEnc.

If I resize to 320x544 and add 16 pixel borders on each side and get a CVD resolution, 352x576, it works just fine.

Both do work in VDubMod.

[sh0dan]

OK - I'm back.

I did get to work on some features in the weekend. 2.5 beta is close.

Changes:
* Added: ColorYUV parameter "analyze" can be true or false. This will print out frame color and luma statistics.
* Added: ColorYUV parameter "autowhite" can be true or false. This will automatically adjust U/V offsets for each frame, so that color will be normalized for each frame. This is useful for recorded material, where whitebalance has been set wrong.
* Added ColorYUV parameter: "autogain". This will adjust luma to have maximum luma range for each frame. This function is also known as "autolevels" in some programs. This can be useful for recordings with bad light conditions, but it might make images flicker.
* MMX/ISSE optimized BitBlt function. This gives a reallife performance increase of ~15%.
* Added dissolve YV12. This also corrects FadeIn/Out.
* Separatefields now seems to work.
* MMX optimized YV12 merge functions.


@Marc: How's work going on Layer / Compare / Subtract?

@All: I'll try to catch up with the forum later today.

[frank]

@shodan
Vobsub doesn't work because it is YUY2 format.
But why does Avisynth 2.5 crash when I set it after the ConvertToYUY2 command?

...
ConvertToYUY2
VobSub(...)
return

A bug in ConvertToYUY2?
Any way to use Vobsub in Avisynth 2.5?

[sh0dan]

If Vobsub is an 2.0 filter, it doesn't work with 2.5 - filters are not compatible between these versions

[Boulder]

@frank and sh0dan

See Gabest's answer to my question here:

http://forum.doom9.org/showthread.php?s=&threadid=39204

[Marc FD]

>@Marc: How's work going on Layer / Compare / Subtract?

well, i take my time, but i finished to clean Layer YUY2/RGB32 code, it's about 500-600 lines less long. i'll do YV12 of Layer/Compare this week i think. I already converted Subtract a while ago, and Layer will have the same functionnality (in MMX)

[JohnMK]

btw, you guys are doing something right, because I'm getting between 50-80 fps avg. per pass on my P4 3.06GHz @ 3.34GHz, DivX 5.02 + B-frames, 2-pass.

[sh0dan]

New updated version (internal changes).


* AviSynth now attempts to get handle from AviSynthpluginInit2 when loading plugins.
* "internal.h" can now be left out of plugin development.
* Added license exemption to avisynth.h


What this means is that plugin writers should ASAP change AviSynthPluginInit to AviSynthPluginInit2. Older 2.5 filters will still work for a short transition period, but when AviSynth 2.5 hits beta older plugins will no longer be accepted.

This is to make pre-2.5 versions reject 2.5 plugins, to avoid crashes and user confusion.

The speed increase is good - even better than I dared to hope for - nice to see this :)

[MaTTeR]

sh0dan,

Great work as always! TemporalSoften seems to work very well and is very fast.

I've been fighting an odd problem lately trying to deinterlace or IVTC some movies. It seems when I add a smoother filter such as Flux, C3D or tiya3dd before resizing I get garbage frames after the first one. Putting the filters after the resize line fixes the issue. Using the AVS built-in TemporalSoften before resizing does not cause any problems though:confused: The problem seems to only happen when I rip with D2A NOT using the ForceFilm option(ie. No Field Operation). I've tried using different builds of D2A, cropping in different multiples and various MOD-4 and MOD-8 resolutions. As a last resort I've also tried the last 2 AVS builds(16th and 17th) and am using MPEG2Dec3 0.94.

This doesn't seem to be a filter related problem so I thought I'd throw it out here and see if anyone else is seeing the problem or if I'm doing something silly. Sample script-
mpeg2source("D:\test\fwood.d2v",idct=3)
TomsMoComp(1,5,1)
Lumafilter(-1)
crop(16,4,688,472)
tiya3dd(0,6,6,28)
#FluxSmooth(4,2)
#Convolution3D(0,1,6,3,4,2.6,0)
BicubicResize(496,384,0.333,0.333)
Undot()
Limiter() I commented out the last 2 lines and still seeing the same problem. FWIW, various Decomb settings are giving the same result (garbage frames) as using TomsMoComp. I can post a picture if needed. TIA

[sh0dan]

I've been fighting an odd problem lately trying to deinterlace or IVTC some movies. It seems when I add a smoother filter such as Flux, C3D or tiya3dd before resizing I get garbage frames after the first one.

@Marc FD: Would you check, that you always return a valid frame 0, even if you are requested to deliver frame <0 ???

This could give the problem you describe. (temporal soften actually checks if a (frame<0) is requested).

[SansGrip]

Originally posted by sh0dan
(temporal soften actually checks if a (frame<0) is requested). Should all filters do this? Why would a negative frame number be requested in the first place?

[Marc FD]

>@Marc FD: Would you check, that you always return a valid frame 0, even
>if you are requested to deliver frame <0 ???

all my temporal filters where fixed against this a while ago.
i always check. simply to avoid crashes.

but MPEG2Dec3 doesn't check, _like MPEG2Dec_ , so if a filters asks for a bad frame, results are unpredicable. i'll fix that in v0.95

[trbarry]

It is easy to check for a valid frame number but what do we really want to return if it is bad? Is there a standard guidline?

- Tom

[SansGrip]

Originally posted by trbarry
It is easy to check for a valid frame number but what do we really want to return if it is bad? Just what I was thinking. Such special-case code tends to hide bugs rather than eliminate them.

[sh0dan]

In general I think we should hide errors like this - I know it isn't the best practice, but it'll help a lot of users with bad filters. First/last frames are special cases - I don't think this would hurt. (and it's actually a common error - seems like Flux, C3D or tiya3dd might have the bug.

An easy solution would be for the cache to handle these errors, so that it will automatically map invalid frames to the last valid one - making this the default mode of operation. How does that sound? (I really cannot see any downside to this).

[MaTTeR]

Originally posted by sh0dan
(and it's actually a common error - seems like Flux, C3D or tiya3dd might have the bug. I apologize but I mispoke in my previous post. The latest release build of Convolution3D does NOT give me the garbage frames. FWIW, TemporalCleaner_YV12 does not give garbage frames either.

Many thx for working on this guys!

Edit- No problems with Undot either:)

[trbarry]

An easy solution would be for the cache to handle these errors, so that it will automatically map invalid frames to the last valid one

That might give the simplest and most consistant results, and off hand I don't see any downside.

But what about the general case where my GetFrame() couldn't get a frame for any reason. What is really recommended here? Can I return 0? Or am I supposed to do a ThrowError?

- Tom

[SansGrip]

Originally posted by sh0dan
and it's actually a common error - seems like Flux, C3D or tiya3dd might have the bug. Flux shouldn't:


PVideoFrame f = child->GetFrame(n, env);
assert(f);
if(n == 0 || n == vi.num_frames - 1)
return f;
How does that sound? (I really cannot see any downside to this). Sounds good. The only downside would be that, again, we're only doing it to compensate for one or more filters that are faulty. It could perhaps be on by default but with the option to disable it in the interests of debugging...?

[sh0dan]

@Sansgrip: No, flux shouldn't. I don't know if flux is a temporal filter, but if it is it should ensure that it never requests frames below 0 and above nframes-1.

@trbarry: I would throw an error. Seems only fair enough if you haven't done anything wrong :)

[Guest]

Decomb uses a macro to access GetFrame(). The macro maps all requests below 0 to 0, and all requests above max frame to max frame. That way I do not have to explicitly code these tests everywhere. It also ensures that I can't forget to do it.

[SansGrip]

Originally posted by sh0dan
@Sansgrip: No, flux shouldn't. I don't know if flux is a temporal filter, but if it is it should ensure that it never requests frames below 0 and above nframes-1. It's temporal and spatial. That code I posted should prevent it from accessing out-of-range frames, right?

[Guest]

Originally posted by SansGrip
It's temporal and spatial. That code I posted should prevent it from accessing out-of-range frames, right? If n is out of range, you call GetFrame() with it. Looks wrong to me.

[SansGrip]

Originally posted by neuron2
If n is out of range, you call GetFrame() with it. Looks wrong to me. But I don't try to request a frame < 0 or >= num_frames during my own processing. Admittedly I don't stop another filter from doing that, but that wouldn't be my bug... :D

[Guest]

Originally posted by SansGrip
But I don't try to request a frame < 0 or >= num_frames during my own processing. Admittedly I don't stop another filter from doing that, but that wouldn't be my bug... :D Perhaps, but that isn't demonstrated by the code you posted. :)

[SansGrip]

Originally posted by neuron2
Perhaps, but that isn't demonstrated by the code you posted. :) I thought it was. If I'm doing an immediate return frame; if n == 0 or n == num_frames - 1, then presumably my actual processing code will never request out-of-range frames. Perhaps I should have mentioned that it only ever uses a temporal radius of 1? ;)

Or maybe I'm missing something... :scared:

[Guest]

Originally posted by SansGrip
...presumably... As I said, it isn't demonstrated by the code you posted.

[Guest]

Originally posted by SansGrip
But I don't try to request a frame < 0 or >= num_frames during my own processing. Admittedly I don't stop another filter from doing that, but that wouldn't be my bug... :D If they pass n out of range to you and you pass that along to GetFrame(), it is now your bug, because you could have caught it and did something reasonable with it.

[sh0dan]

To avoid this confusion - making the cache check the ranges would make everyone happy. Donalds solution is of course the most graceful, but putting in the checks, we probably avoid many hard-to-track bugs.

Until now I have personally always seen this as something the source filter should check, but now it isn't.

[MaTTeR]

SansGrip,

FWIW, the problem doesn't occur if I put FluxSmooth after resizing. Also, I noticed the problem doesn't occur if I setup Convolution3D _after_ FluxSmooth but both are inserted before resizing. Soon as I comment out C3D, the garbage frames return(except for first frame).

I can't be certain but I'm only seeing problems on true interlaced sources such as a live concert DVD. Hybrid or progressive material isn't giving me a problem at all so far. Hope this helps a bit.

[SansGrip]

Originally posted by MaTTeR
FWIW, the problem doesn't occur if I put FluxSmooth after resizing. Strange. Well, let's take this over to the Flux thread and we'll try to narrow down the possibilities :).

[sh0dan]

Just a quick note: Added (detailed) ColorYUV description at avisynth.org
I hope most of it is understandable, so you all can enjoy this very useful filter.

[sh0dan]

I have updates the alpha during the day.

Jan. 10. compile features:

* General crashbug fixed due to too old cache code used for compilation.
* Optimized limiter for mod8 resolutions.
* Subtract now works in YV12 mode.
* Added Fliphorizontal.
* FlipVertical now work in all colorspaces.


Other important updates that have happened recently:

* Fixed crashbug in resize.
* Fixed bug in temporalsoften, if any threshold was 0. (KP)
* YUY2 mode now uses the new temporalsoften algorithm. (KP)
* Fixed bug in Mergechannels() (KP)
* Fixed "file not found" crash in AviSource. (RB)
* Tweak now works in YV12 (RB)
* Fixed bug in StackVertical (RB)
* Fixed bug in some non-mod-16 resolutions.

Same place (http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html) as always!

Enjoy!