AviSynth 2.5.6 CVS Pre-Releases. [September 25th]

[IanB]

Dear all,

Here is the start of my review and refactor work on Avisynth 2.5.5.

I will be making CVS checkpoint compiled Avisynth.dll available here Sept 25th, 2004 Avisynth.dll (http://avisynth2.sourceforge.net/25Sep2004/avisynth.dll), these are intended for direct replacement of the avisynth.dll from the released 2.5.5 package. The various Version functions and strings report it as version 2.5.6! Please note this is pre-alpha software!

I hope to review all the current code base in time. Bug listed on the Source Forge Bug Tracker (http://sourceforge.net/tracker/?atid=482673&group_id=57023&func=browse) with sample scripts clearly demonstrating the problem will have influence on the order I review the modules.

Whats being done.

Focus.cpp
Full review and refactor of Blur/Sharpen code
Fixed YV12 width<=16 fatal crash
YV12 H MMX code no longer double blurs every 8th pixel
Edge boundaries now processed
Now MMX, not just SSE restricted
Some MMX versions faster
Most 2^n MMX width restrictions gone
When H or V blur==0 now skips that pass

Layer.cpp
Fixed BGR - GBR typo

Convert.cpp
Review and refactor in progress
Many 2^n MMX width restrictions gone
Fast MMX RGB24 -> RGB32 convertion
Legacy C++ RGB32 -> RGB24 reinstated
RGB Greyscale(matrix="rec709") support for Rec.709 luma weightings.
MMX YUY2 Greyscale()

Please report bugs in these reviewed modules in this thread.

Please post your script!

Regards
IanB

[sh0dan]

Really great, Ian!

I just uploaded an installable version at Sourceforge (as the TCPDeliver plugin also had an update).

Further changes are:

- Static Images no longer flipped in ImageSource.
- PlaneDifference was not reporting exactly 0, if the planes were the same.
- Fixed big bug in compressed YV12 TCPSource/TcpClient.
- Docs updated.

[Fizick]

The various Version functions and strings report it as version 2.5.6! Please note this is pre-alpha software!
I think, pre-alpha must be named alpha. :)
Why you do not use fourth version digit (as Manao did :) ),
similar to 2.5.5.1 ?
I see now is mostly bug-fixed release.

[malkion]

IanB, I get an unrecognized exception with,

lanczosresize(626,352)

Something more mod4 friendly works, as usual.

[Boulder]

Has the Crop weirdness been fixed?

With AVS 2.5.5 and interlaced 720x576 MPEG-2 source:

mpeg2source("c:\temp\captures\test.d2v")
Crop(16,4,-12,-4,align=true)

produces
http://www.saunalahti.fi/sam08/crop_buggy.jpg

and this one

mpeg2source("c:\temp\captures\test.d2v")
Crop(16,4,-8,-4,align=true)

produces
http://www.saunalahti.fi/sam08/crop_notbuggy.jpg

Both are cropped mod-4 so that should not be a problem. If I convert to YUY2 before cropping, both work fine.

[Manao]

Boulder : it's a bug of XviD, not of avisynth : put a converttoyuy2 after cropping, you'll see chroma is aligned. XviD is used to decode YV12 raw input in VirtualDub.

[Boulder]

Originally posted by Manao
Boulder : it's a bug of XviD, not of avisynth : put a converttoyuy2 after cropping, you'll see chroma is aligned. XviD is used to decode YV12 raw input in VirtualDub.

Oh, I see. That means it could be fixed by editing the registry so that some other codec is used for decoding YV12 - that is, DivX5 or ffvfw?

[Manao]

I don't know if it's possible. Anyway, you shouldn't encode something which is mod4 only, so it's not a big issue.

[Boulder]

The cropped input would be resized to mod-16 resolution anyway so it would be important to be able to crop by any mod-4 amount;) I suppose that the filters don't like the look of those weird colors. I'll have to do some tests then..

[Wilbert]

That means it could be fixed by editing the registry so that some other codec is used for decoding YV12 - that is, DivX5 or ffvfw?
Yes, that's possible: vidc.yv12=divx.dll or ffvfw.dll (forgot the name of the dll). You know ... See yv12 faq.

[IanB]

@Sh0dan,

Thanks for making the full release, so far this is only bug fixes. I'm not geared up to build all the frilly bits needed for a full release. I hope to average a CVS commit weekly but some parts are bigger than others and many modules will not need any fixing during a review so there may be some dry spells and releases with only a single change.

@Fizick,

Yes, I guess this first issue is really a 2.5.5.1 but given time these won't be just that. E.g. I am sticking Rec.709 (HDTV colour space) thoughout Convert.cpp, currently Greyscale() is the tip of the iceberg. And I am sure some checkpoints will be more than a little stuffed. The naked avisynth.dll's are just a courtesy to those who cannot compile directly from the CVS tree, and give me mini reference versions.

@Malkion,

Yes that damn "unrecognized exception" is really starting to hurt. I have tried to develope some defensive code to work around the problem but fundamentally GPF's during Exception Handling are pretty fatal. As part of the review I check the generated assembler for this problem, but it is tedious. Maybe I'll get lucky and nail it soon.

@Boulder,

As Manao points out the problem is non-mod 4 chroma (i.e mod 8 luma) into XVID. DivX also has problems with non-mod 4 chroma, it truncates (black bar) the right hand edge. We could enforce mod 8 YV12 width on output but that would be unfair to the codecs that correctly handle non-mod 4 chroma width.

You could put a null function (no processing cost) into an .avsi that checks and asserts defined width and height modulus and call it as the last line of a script.Function Validate(Clip clip) {
Assert((Width(Clip) % 8 == 0), "Width must be a multiple of 8")
Assert((Height(Clip) % 4 == 0), "Height must be a multiple of 4")
return Clip
}
----------------------------------------
mpeg2source("c:\temp\captures\test.d2v")
Crop(16,4,-12,-4,align=true)
Validate()Regards
IanB

[madness]

I went and download the 2.5.6 alpha and saw the filename for the installer has sh0dan time traveled a month ahead of us?? :p

[scharfis_brain]

mergechroma() does not properly handle the weight parameter.

it either copies the chroma, or ignores it.
no matter what the weight is set to...

I found this error, while creating a fast YV12-blending function:

function blend(clip i, clip j, float "w")
{w=default(w,0.5)
i.mergechroma(j,w).mergeluma(j,w)}

the chroma doesn't gets weighted properly, while the chroma does.

btw.: is it possible, to code this blend() function hard to AVISynth?
layer, overlay and yv12layer are either:
to slow (overlay), restricted to one colorspace (YUY2=layer, YV12=YV12layer)

but blend() fits all needs and is fast...

[esby]

mmm

Could it be possible to put some dummy file in the cvs,
or even not used / called methods in avisynth cvs to ease the maintaining of dsynth.

Technically it is affecting 10 files for now...

2 files are 'new' and specific to dsynth...
(they defines the specific direct streaming internal filters)

src\filters\directStream.cpp
src\filters\directStream.h

So adding these two files would not affect avisynth stability in any way...
Maybe I should just redefine the filters defined there to call the initial filter method to avoid duplication of code. (And I will probably do it when I'll have the time).

And in the same order of idea, if it was possible to add blank method linked to dsynth in avisynth.h ...

esby

[swinokur]

Hi,
This might be a foolish question, but I thought I'd ask anyway:

What are the chances of avisynth becoming SMP aware? Would external plugins (e.g. mpeg2dec) need to be separately coded to be SMP aware as well, or would avisynth be able to take care of that?

thanks!

[esby]

What are the chances of avisynth becoming SMP aware?

I'am not expert on this field, but if I ain't wrong... very small...
I think you can use the search function and search for SMP related threads...
I think one possibility was doing some filtering in avs, encoding with vdub... and have the filter on one cpu and the codec on the other.
There was a thread about that... search a bit and you'll find it.

esby

[hartford]

I have a dualie. I usually see 60% CPU utilisation when using
Avisynth and Virtualdub, or Avisynth and CCE. So that's 20%
over a single CPU.

I read a while ago a thread on Usenet where the head programmer
of Adobe Photoshop was trying to explain to owners of HT's why
the program didn't run much faster than "plain vanilla" P4's.
Talking to a wall would have been more productive.

Anyway, it's simply the "nature" of what is being done to the data,
taking into consideration the architecture of the PC, that precludes
any gain in making Avisynth SMP-aware.

If you reeeeelly want speed, then you need dedicated hardware, similar
to that used by broadcast companies (special effects).

That's my "take" on this.

There is one filter that is SMP-aware but I forget what it is. I'm
certain that a search will find it.

[swinokur]

esby,
I did find the thread on trying to force processor affinity while using avisynth with CCE. I tried the tips but it didn't make any appreciable differene in the speed of encoding.

The other idea in the thread (which I havent tried yet) is to run avisynth/cce under WINE -- someone reported better threading performance while doing that.



Originally posted by esby
I'am not expert on this field, but if I ain't wrong... very small...
I think you can use the search function and search for SMP related threads...
I think one possibility was doing some filtering in avs, encoding with vdub... and have the filter on one cpu and the codec on the other.
There was a thread about that... search a bit and you'll find it.

esby

[esby]

There is another very 'basic' idea...
Split the encode in two...
Encode the two at the same time...
And assemble them together back after...

Of course, it is a workaround...
but it works well when you have two computers and that you are in a hurry... which happened to me once :)

esby

[Wilbert]

Something is wrong with Overlay(lighten and softlight mode).

rgb -> lighten and softlight (I guess darken etc too, but didn't check those)
yuv -> softlight

Scripts:

#BlankClip(color=$d7c838)
#Overlay(BlankClip(color=$d7c838), BlankClip(color=$d7c838), mode="softlight")
#Overlay(BlankClip(color=$d7c838), BlankClip(color=$d7c838), mode="lighten")
#ConvertToYUY2()
#ColorYUV(analyze=true)

# source: Y=178, U=62, V=145
# Overlay_lighten: Y=188, U=55, V=145 (should be the same as source)
# Overlay_softlight: Y=196, U=150, V=156 (should also be the same as source ???)

#BlankClip(pixel_type="YUY2",color_yuv=$b23e91)
#Overlay(BlankClip(pixel_type="YUY2",color_yuv=$b23e91), BlankClip(pixel_type="YUY2",color_yuv=$b23e91), mode="lighten")
Overlay(BlankClip(pixel_type="YUY2",color_yuv=$b23e91), BlankClip(pixel_type="YUY2",color_yuv=$b23e91), mode="softlight")
ColorYUV(analyze=true)

# source: Y=178, U=62, V=145
# Overlay_lighten: Y=178, U=62, V=145 (is the same as source)
# Overlay_softlight: Y=229, U=253, V=163 (should be the same as source ???)

[sh0dan]

I have fixed a chroma overflow in Softlight/Hardligt - but it's only in CVS right now. I'll check lighten.

[Wilbert]

I checked softlight again with latest CVS. It's still not correct:

#BlankClip(color=$d7c838)
#Overlay(BlankClip(color=$d7c838), BlankClip(color=$d7c838), mode="lighten")
Overlay(BlankClip(color=$d7c838), BlankClip(color=$d7c838), mode="softlight")
ConvertToYUY2()
ColorYUV(analyze=true)

# source: Y=178, U=62, V=145
# Overlay_lighten: Y=188, U=55, V=145 (should be the same as source)
# Overlay_softlight: Y=210, U=16, V=146

#BlankClip(pixel_type="YUY2",color_yuv=$b23e91)
#Overlay(BlankClip(pixel_type="YUY2",color_yuv=$b23e91), BlankClip(pixel_type="YUY2",color_yuv=$b23e91), mode="lighten")
#Overlay(BlankClip(pixel_type="YUY2",color_yuv=$b23e91), BlankClip(pixel_type="YUY2",color_yuv=$b23e91), mode="softlight")
#ColorYUV(analyze=true)

# source: Y=178, U=62, V=145
# Overlay_lighten: Y=178, U=62, V=145 (is the same as source)
# Overlay_softlight: Y=229, U=0, V=163

[Wilbert]

Hmm, I'm looking in OF_softhardlight.cpp:


if (opacity == 256) {
for (int y = 0; y < h; y++) {
for (int x = 0; x < w; x++) {
int Y = (int)baseY[x] + (int)ovY[x] - 127;
int U = baseU[x] + ovU[x] - 127;
int V = baseV[x] + ovV[x] - 127;


I guess the values above are correct (ie Y=178, U=62, V=145 -> Y=229, U=0, V=163).

This will lighten or darken the base clip, based on the light level of the overlay clip. If the overlay is darker than luma = 128, the base image will be darker. If the overlay is lighter than luma=128, the base image will be lighter.
What exactly is SoftLight and Lighten supposed to do? What's "light information"?

[sh0dan]

The Soft/Hardlight-terms is lifted directly from Photoshop/After Effects. It allows you to draw a shadow/lightmap for your frame and apply it.

It is quite useful for logos, when you need to both lighten and darken your logo.