AVS Developers: AviSynth 2.5 alpha

[sh0dan]

As you might have noticed, there has been some talks of a new AviSynth, including YV12 support, float samples and multiple channels.

Now the time has come for a complete proposal for the revised framework. There are some radical changes. Sample handling has changed a lot, and YV12 support has also required some changes.
At the same time it has the intention to create a more extensible framework, so adding new features in the future shouldn't require too many changes.

Now, I call all the filter and core developers for feedback. This is not an enduser alpha test, because it is not ready for that yet!

I have created an alpha page, at http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html where you can read about the changes, and download the new avisynth.h, the complete source and a binary. I've created extensive documentation for developers.

Virtual Dub doesn't handle YV12 natively, so you need an YV12 decompressor. On my system it uses DivX 5.02. If your system doesn't support this, end your script with converttoyuy2(). This is also an issue that should be handled.

Until now, there isn't any speed improvement. The binary is a debug build, and will probably remain so some time. Speed is not an issue yet. Making it work has been the top priority.

So if you want to get working with planar YV12, test away!

[Wilbert]

Very nice Sh0dan, MarcFD and others!

Two dumb questions:

1) How do you make avi's in YV12? Did you make a function ConvertToYV12?

2) Is YV12 also supported by DivX4 or Xvid, or do I have to install DivX5?

Thx,

[sh0dan]

The easiest way to get YV12 is to use DirectShowSource, since it'll most often decode to YV12. Then you can use any DivX/Xvid file as source.
AviSource also decodes to yv12 on my computer, but that probably depends on your configuration.

I'll do a converttoyv12 soon - at least to get from yuy2 -> yv12 conversion.

Edit: If you compile your own version, AviSource will show which colorspace it's decoding to in debug mode.
(Late night edit): You can also force AviSource to decompress using YV12, by specifying it as parameter.

[HarryM]

Originally posted by Wilbert
Very nice Sh0dan, MarcFD and others!

Two dumb questions:

1) How do you make avi's in YV12? Did you make a function ConvertToYV12?

2) Is YV12 also supported by DivX4 or Xvid, or do I have to install DivX5?

Thx,


What I know...

All videocodecs work in YV12 natively. When you use YUY2's instruments (e.g. Avisynth v1.0x or 2.0x) actually, you must convert >>>

YV12 (e.g. MPEG-2 format) -> YUY2 (e.g. Avisynth) -> YV12 (e.g. XviD)

You must convert twice:
1. YV12 to YUY2
2. YUY2 to YV12

With Avisynth 2.5x you don't need conversion, additional YV12's videoprocessing routines are little quicker than YUY2's too.

[Wilbert]

@Sh0dan,

AviSource also decodes to yv12 on my computer, but that probably depends on your configuration.

Ok, thanks.

@HarryM,

All videocodecs work in YV12 natively

Ok, I didn't know this. Maybe MarcFD could add an additional argument to his MPEG2DEC3 which outputs to YUY2, YV12 or RGB32. (Maybe he's already working on this ...)

[Richard Berg]

I think we've talked about this before, but there should be an option we can pass to source filters to specify preferred format. In general, pointing to an encoded stream and telling the system (AviFile or DirectShow) "decode this" isn't deterministic the way users probably want.

Some other ideas we may want to support in the future and should thus at least make room for:
-Multiple streams per file. The most obvious case is having soundtracks in >1 language, but the AVI format actually supports up to INT_MAX audio and video streams in a single container file.
-More powerful scripting. Things like conditional primitives come to mind, as well as greater exposure of internal state to the scripting environment e.g. through reserved variables.
-Add your brainstorms here...if we're gonna be changing the interface in a non-compatible way, we should do it *once*.

Also, now that we got Ben's permission, we may as well use the occasion to revise the license statement at the top of avisynth.h to allow the creation of closed-source plugins, or perhaps just release it to the public domain.

[sh0dan]

@HarryM: Correct, but the problem is, that VDub cannot handle YV12 internal, and it therefore requests a codec to return the data as YUY2 or RGB.

So what happends is:
AviSource -> AviSynth -> Vdub -> Compressor
[YV12] [YV12] [YUY2] [YV12]
So what happends is a conversion, since Vdub cannot forward the data as YV12.
I'm pretty sure (although not 100%) that this is true for "fast recompress" (this is what i can see from the code). So until Vdub is modded for passing YV12 in "fast recompress", we cannot make the process 100% YV12.

My initial performance tests seems to confirm this. Although some filters most probably will work faster in YV12 mode, there isn't a big speed gain in YV12 (yet!). It does however work very nice with zoomplayer for instance, with very fast overlay, so using AviSynth for postprocessing is much better now!
Coding for planar is however a great thing, and we should also have a look at the ffdshow filters at one point.

[hakko504]

Has anyone tried to contact Avery Lee to see if he could implement YV12 support in VD?

[HarryM]

Originally posted by hakko504
Has anyone tried to contact Avery Lee to see if he could implement YV12 support in VD?

VirtualdubAVS could implement 'direct YV12 support' in future.

[sh0dan]

Originally posted by Richard Berg
I think we've talked about this before, but there should be an option we can pass to source filters to specify preferred format. In general, pointing to an encoded stream and telling the system (AviFile or DirectShow) "decode this" isn't deterministic the way users probably want.

I'm not sure I'm with you here - could you give an example?


-Multiple streams per file. The most obvious case is having soundtracks in >1 language, but the AVI format actually supports up to INT_MAX audio and video streams in a single container file.

Interesting. Could it be done by extending the return() statement, so it could do: return(video_lang_uk,video_lang_dk,video_lang_de). Is this supported by any software?

I have no idea how this would end up in main.cpp - so you'll have to help there.


-More powerful scripting. Things like conditional primitives come to mind, as well as greater exposure of internal state to the scripting environment e.g. through reserved variables.

I have no personal oponion on this - it would be great, but you'll have to kick in there as well - I'm not the best on this area.

I have actually complete forgot to mention the one feature, that isn't implemented yet, which is better support for GUI's, making an optional function to GenericVideoFilter, that returned information about the filter.


Also, now that we got Ben's permission, we may as well use the occasion to revise the license statement at the top of avisynth.h to allow the creation of closed-source plugins, or perhaps just release it to the public domain.
Agree! If you have the text, just commit it to the 2_1 branch.

[sh0dan]

Originally posted by HarryM
VirtualdubAVS could implement 'direct YV12 support' in future.
Yes - There are someone who has been playing with a modified Vdub (http://forum.doom9.org/showthread.php?s=&threadid=33586) that support MPEG2 input, decodes it to YV12 and passes it directly to the codec. It does however seem to be completely broken for Avi input.

I don't think it would be a very big modification, from what I can judge, but it'll probably still need some coding.

[Belgabor]

Originally posted by HarryM


VirtualdubAVS could implement 'direct YV12 support' in future.

This is certainly something for the planned combined project since this is surely (atm at least) beyond my coding ability.

Belgabor

[sh0dan]

I'm looking at yuvcodec.cpp - but I'm not sure how it interfaces with the rest of AviSynth. It does seem to be a passthrough filter, that only does minimal work of itself, besides forwarding compressor commands to the decompressor.

Maybe it no YV12 decompressor can be found, preview will be disabled, but I'll have to look much further into that. First of all I'll have to

[hakko504]

Originally posted by sh0dan
I'm looking at yuvcodec.cpp - but I'm not sure how it interfaces with the rest of AviSynth. It does seem to be a passthrough filter, that only does minimal work of itself, besides forwarding compressor commands to the decompressor.

Maybe it no YV12 decompressor can be found, preview will be disabled, but I'll have to look much further into that. First of all I'll have to press the right button? :D :cool: :D

[sh0dan]

... get some more time perhaps? ;)

I think I meant, I'll have to make it compile, it seems to be missing some ogg stuff (ogg.h). Strangely enough I can't really see where to put it.

Edit: Just tested on a plain Vdub, and it seems like it's more Dub.cpp that's the interesting one. It does seem to require some tweaking, for which I don't have the time now - making the inputsource on fast repack accept YV12 isn't enough.

[vlad59]

@Sh0dan

At first : great work, thanks a lot for this huge work !!!!

Next, I think I would be interesting to add to your "alpha buil page" some info about the YV12 format especially that horizontal size must be mod 4 (IIRC ???), vertical size mod 2 or 4, .....

Just my 2 cents

[sh0dan]

You're right - I probably should. But to sum it up:

In YV12:
- Width must be mod 2 (as YUY2)
- Height must be mod 2.

The image data is divided into three planes. One luma, and two chroma planes. You operate on these planes seperately.
The two luma planes are half the size of the luma planes (in width and height).
That means you have three different pointers you operate on. In principle your filter can operate independant on the three planes.

[Marc FD]

too dumb ^^
i just start to be _very_ used to work in YUY2 now.
it doesn't make me any problem anymore to do SIMD on YUY2.
even vertically ^^ (msoften use a SIMD 2d average blur)

i think i would keep YUY2 until we have YV12 support in VDub.

then i would add YV12 support in MPEG2Dec3 and release my SIMD verion of distortion_measure (thx marco ^^) who works in YV12

BTW, keep in mind handling interlacing in YV12 is really hard ^_^

Cheers,
MarcFD

[Richard Berg]

That was more or less my intuition -- filters like CNR2 can probably be sped up greatly, but something like Decomb will require a lot of work and possibly more processing time to boot.

Replies to sh0dan forthcoming, got a lot on my plate ATM...

[stickboy]

Originally posted by sh0dan
I'm not sure I'm with you here - could you give an example?I think Richard is referring to the pixel_type argument added to AVISource and its ilk in version 2.05... based on your "late night edit", though, I assume you've already taken care of that.

[sh0dan]

Originally posted by Marc FD
BTW, keep in mind handling interlacing in YV12 is really hard ^_^


Unless I'm mistaking, it's much easier in YV12. Every second line in the Y plane is interlaced, just as YUY2. The chroma planes cannot be interlaced, so no special code there.

Is it more complicated than that?
i just start to be _very_ used to work in YUY2 now.
If I recall correctly, you were the one pushing very hard for YV12 support?!!?

[trbarry]

There are design issues to be worked out but I think deinterlacing is probably easier in YV12. And probably at least 25% faster.

- Tom

[Marc FD]

>here are design issues to be worked out but I think deinterlacing is
>probably easier in YV12. And probably at least 25% faster.

of course, everything would be theorically 25% faster in YV12 ^^
but i though the vertical upsampling would make deinterlacing harder.
BTW, you and don are the deinterlacing gurus here. if you say it's easier, it's good news ^_^

>Unless I'm mistaking, it's much easier in YV12. Every second line in the
>Y plane is interlaced, just as YUY2. The chroma planes cannot be
>interlaced, so no special code there.
>Is it more complicated than that?

chroma _is_ interlaced, from what i understood.
and it's why i though it's going to be more difficult to handle :(

>If I recall correctly, you were the one pushing very hard for YV12
>support?!!?

of course :) . i never say i was against. i just slowly got used to YUY2 and now i'll need to learn how to use YV12 correctly :D

keep the good work :)

Cheers,
MarcFD

[sh0dan]

Originally posted by Marc FD

chroma _is_ interlaced, from what i understood.
and it's why i though it's going to be more difficult to handle :(


Do you have ANY information about this, since my implementation of YV12 separatefields, weave and doubleweave assume the opposite. Many Nic, Koepi or other XVID devels can help here?!?

Interlacing isn't a big issue in AviSynth, due to the methods mentioned above. No filters really deal with interlacing, except the ones actually designed to modify interlacing (decomb, mocomp). All other filters doesn't really care about interlacing, even though some probably should (resize, smoothers, etc), but doesn't have to because the user can use separatefields/weave.

So even if interlacing isn't simple, it won't affect that many filters, if they are seperated correctly.

[SansGrip]

sh0dan: VDub cannot handle YV12 internal

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

[-h]

Do you have ANY information about this, since my implementation of YV12 separatefields, weave and doubleweave assume the opposite. Many Nic, Koepi or other XVID devels can help here?!?

I can only comment on interlacing behaviour in MPEG-4.

edit: which I misunderstood anyway :)

-h

[trbarry]

-h

I'm not sure that is completely correct. First, I don't think you have to divide by 2 because you already have the fractions, .25,.75.

But the idea is, like with resizing, you don't want to blend the values from even and odd fields which may be from different points in time, because you would get interlace artifacts.

So it is just a weighted average of lines 0 & 2 and and a weighted average of lines 1 & 3. The weights follow easily from knowing what sample points the YV12 chroma values are supposed to represent.

This is often done wrong, causing the various DVD player "chroma bugs" and I harp on it a bit. ;)

But see DVD Benchmark - Special Report - The Chroma Upsampling Error in DVD Players - April, 2001 (http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html) by Stacy Spears, who is even more obsessed with the idea than me. (and understands it better) ;)

That page graphically displays the layout and explains the common problems that we shouldn't make. There is also code in MPEG2DEC2 or DVD2AVI that does this in what I hope is a correct fashion when converting to YUY2.

I think the book "Video Demystified" also explains it well. Don't know if that is online.

- Tom

edit: In the DVD2AVI source for instance ( www.trbarry.com/DVD2AVIT3.zip ) in member filters.cpp function conv420to422() converts 4:2:0 planar to 4:2:2 planar. It does it differently for interlaced vs frame pictures, and does the top and bottom fields separately for field pictures.

edit2: It looks like we are going to be relying more on the "frame based" and "field based" Avisynth values, so IVTC or deinterlace functions should set this to frame when done. Mine don't. ;)

edit3: It looks like when vertically cropping interlaced YV12 it should maybe be done in multiples of 4, not 2. I don't think anyone honors this anywhere. Somebody correct me if I'm wrong here but I was just staring at Stacy's pictures and worrying. I'm not sure I'm right about this.

edit4: These are some of the things I brushed off as "design considerations". ;)

[-h]

I'm not sure that is completely correct. First, I don't think you have to divide by 2 because you already have the fractions, .25,.75.

Ha! Good points, I probably wouldn't have noticed the division and field-blending errors until I tried implementing it.

edit3: It looks like when vertically cropping interlaced YV12 it should maybe be done in multiples of 4, not 2. I don't think anyone honors this anywhere. Somebody correct me if I'm wrong here but I was just staring at Stacy's pictures and worrying. I'm not sure I'm right about this.

Yes. Heights being a multiple of 4 is enforced for field-based video in MoMuSys, and now I see why. Otherwise the top and bottom fields would have differing amounts of chroma information.

-h

[Wilbert]

@Sh0dan,

I downloaded v2.5, but I can't install it (I mean I can install it but it doesn't work). I changed the dll's, run the reg file, rebooted a couple of times, removed every entry in my registry file about AviSynth manually and reinstalled. Every time I try to play the avs with "version" or with "AviSource("C:\clip.avi")" it says

Cannot open 'F:\version.avs'
Please verify that the path and filename are
correct and try again.

Win98SE + Athlon, let me know if you need more info.

edit: I also noticed that the file size is eight times bigger.

[sh0dan]

If AviSynth is already installed, you should just overwrite the .dll and do nothing more.

The size of the dll is because it is a debug build, so it contains debug information.

I have it running on both Win2k, WinXP and Win98SE. Is Virtual Dub giving you these errors?

[Wilbert]

If AviSynth is already installed, you should just overwrite the .dll and do nothing more.
I also tried that a couple of times.

Is Virtual Dub giving you these errors?
WMP6.4 did. I forgot to try it with Virtual Dub.

[sh0dan]

So what happends in VDub?

[sh0dan]

Another issue:
- I would really much like to make YV12 mod 4 on width/height.

It seems like there isn't much of an option on making it mod 4 in height, because interlaced processing requires this.

Making mod4 restriction on width is for speed reasons. I'd very much like this to be mod8 (so chroma can work on 32 bits at the time) - but I'm afraid you'd all cry out in anger. :(

Another way for this could be to make sure that pitch is always at least mod 8 or 16. That way filters could be allowed to process beyond the rowsize without causing distortions.

So how about YV12 has mod 4 restrictions, and AviSynth must always deliver a pitch that is at least mod16?

[Wilbert]

Sorry I'm at work now. But I also installed it here (Win98SE PIII). When I try WMP6.4 it says the same. Opening in Virtual Dub gives "Cannot determine file type of "C:\Temp\test.avs"".

The avs file contains "AviSource(some DV file)", also tried it with "version".

(Overwriting v2.05 works fine.)

[vlad59]

Originally posted by sh0dan
So how about YV12 has mod 4 restrictions, and AviSynth must always deliver a pitch that is at least mod16?

I agree

[sh0dan]

Originally posted by Wilbert
(Overwriting v2.05 works fine.)
So.... does the alpha work, when you install 2.05 first, or does it work, when overwriting the alpha with 2.05? :confused: :confused:

[-h]

So how about YV12 has mod 4 restrictions, and AviSynth must always deliver a pitch that is at least mod16?

I would be happy so long as the pitch is mod16 and the image itself is allocated with 16-byte memory alignment.

-h

[Richard Berg]

Ditto to -h's request.

[dividee]

It would be nice if 16-byte alignment was guaranteed, but then Crop would (usually) need to do a memcopy, because nobody would like to be constrained to crop on mod16 boundaries only.

[-h]

It would be nice if 16-byte alignment was guaranteed, but then Crop would (usually) need to do a memcopy, because nobody would like to be constrained to crop on mod16 boundaries only.

A good point!

Perhaps the script handler could be smart enough to determine where the image should be allocated, such that after cropping the top-left pixel will be 16-byte aligned. I assume there are other complications I'm not aware of.

-h

[trbarry]

I think mod 16 alignment is important enough that it is worthwhile to ensure it even if crop had to be complicated to do a copy in the non-mod-16 cases. This is true for RGB and YUY2 also.

It would simplify programming and probably still give a performance boost in the average case even if it slowed down crop sometimes.

- Tom

[trbarry]

If multi-channel of ac3 is working, would it make sense now to have DVD2AVI/MPEG2DEC (optionally) also return that along with the video to the MPEG2SOURCE function?

Maybe it would help with some sync problems, or at least make it possible to fix them more easily.

- Tom

[WarpEnterprises]

This would be really great since creating the WAV is not really elegant.
But then the DVD2AVI downmix/dynamic range control would be useful IN AviSynth.

[sh0dan]

@All:

This is how I've tried to implement it:

How it is in 2.0x: When you request the rowsize, you get the width of the actual image in bytes. This may, or may not be the same value as the image pitch.

How it works in the alpha: When you request the rowsize, you can add the parameter "PLANAR_Y_ALIGNED" or "PLANAR_U_ALIGNED"/"PLANAR_V_ALIGNED". This will give you the width of the image, rounded up to nearest mod16 (or if already mod16, just rowsize as usual).

When a planar image is allocated, it is FORCED to have mod16 pitch. For source filters that may not wish to comply with that I've created a filter "AlignPlanar" which must be called with a clip argument. This will align (and copy is necessary) the pitch to mod 16.(See here (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/source.cpp.diff?r1=1.17.2.12&r2=1.17.2.13&only_with_tag=avisynth_2_1&sortby=date) how to use it.)

Also env->NewVideoFrame(vi,[align]) has changed, so pitch is rounded up to 16 for all images, and align is only forced, if align is negative (-4 = 4 align forced).

Please ask, if you have any questions - this explanation is a bit technical I know.

Other YV12 changed include:
- *Resize now works vertically.
- VerticallyReduceby2() works
- Added converttoyv12()
- Added experimental plugin info function.
- Greyscale() now works.
- (Edit) MMX optimized ConverttoRGB24() (don't ask why - it's faster though)

New alpha will be up later today. I still have some stuff to debug.

[Wilbert]

So.... does the alpha work, when you install 2.05 first, or does it work, when overwriting the alpha with 2.05?
Sorry for my bad english. I meant: alpha doesn't work (win98se athlon + pIII).

[sh0dan]

The AviSynth alpha page (http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html) has been updated with a new alpha.

[Wilbert]

You mean this one "Download : Binary [21-10-2002]"? The link to that file is broken.

[sh0dan]

Refresh the page - it's here :)

[Wilbert]

Replaced the dll, rebooted. I still got the same error messages.

[sh0dan]

Try this Release build (http://cultact-server.novi.dk/kpo/avisynth/avisynth_release.zip). It shouldn't be any different from 2.06.

Alternatively try creating the reistry 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).

Btw, rebooting shouldn't be necessary at any time. This is a very frustrating thing to hunt down - we don't seem to get anywhere :(

[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?

[lighty]

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

Hrm- well that is realy a question of taste- I like to preserve my encodes on as high resolutions as I can even if a have to do some blending or interpolation. Same goes for my vidcaps - I always grab at fulll or double resolution and then deinterlace. It maybe is odd but when I got it back to TV via TV out I got sharper image. :p

@Sh0dan

Eh- as I already explained I rather blend or interpolate then reduce size by 2. There are also films that are telecined and that I wish to treat- but I still wait for YV12 port of Decomb... :(
But I am a patient person so I can wait as long as possible--NOT!;)

lighty

[int 21h]

Decomb is GPL'd, maybe if some YV12 guru has time they can port it quick and save Donald some grief.

[trbarry]

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.

Yikes! I am getting beat up all over the place today about being tardy with TomsMoComp.

But maybe rightly so. ;)

I hereby vow not to get sidetracked with other interesting ideas (or anything else) until it's done. Expect a release tonight, or maybe tomorrow at the latest.

I can't help you with Decomb. But, FWIW, DVD2AVI/MPEG2DECx Force Film should already work for properly telecined stuff in YV12. Anybody know?

- Tom

[MaTTeR]

Originally posted by trbarry
Expect a release tonight, or maybe tomorrow at the latest.

I can't help you with Decomb. But, FWIW, DVD2AVI/MPEG2DECx Force Film should already work for properly telecined stuff in YV12. Anybody know?
Very cool to hear about the release of TMC, just got a concert Interlaced DVD today that I can use for testing:)

Yep, D2A/MPEG2DEC3 works fine using Force Film on Telecined movies and YV12 encoding. I've tested this with about 5-6 movies over the past few weeks.

[trbarry]

Maybe a cross post, but I just released a YV12 TomsMoComp test version. See this thread (http://forum.doom9.org/showthread.php?s=&threadid=37915).

- Tom

[neuron2]

Originally posted by int 21h
Decomb is GPL'd, maybe if some YV12 guru has time they can port it quick and save Donald some grief. No need. I am working on it.

Believe me, noone can do it quick. :)

[trbarry]

Believe me, noone can do it quick

I don't know about that. Marc FD and sh0dan are some pretty fast coders. ;) :devil: :devil: :devil: ...

- Tom

[Marc FD]

>No need. I am working on it.

great to hear don.

TomsMoComp is my favourite for DVD playback with BSplayer (becuause it's damn fast), but for encodes, decomb rules ^^

BTW, tom and don, i've some question about deinterlacing. i'll read a bit more the sources of TomsMoComp and decomb and then i may ask you some questions :)

[Krajensky]

Originally posted by trbarry
But, FWIW, DVD2AVI/MPEG2DECx Force Film should already work for properly telecined stuff in YV12. Anybody know?

ATSC isn't often properly done, it lacks the repeated field flags...

Though, as I think about it more (for anything over 480i), you could toss one field and simply use Decimate (should be simple to port just Decimate, I'll take a look later today).

Krajensky

[Didée]

There's one feature I am missing very often in AviSynth 2.0x, and since 2.5 is under development anyway ...

It's about "subtract". In its current form, it is very usable to see differences between frames.

But what if you want to work with these differences, e.g. make a mask out of it?

(Motivation: e.g.
- noise masking
- edge detection by gaussian blurring
- etc. )

In this case, the current "deviation image" with its "attractor" at Y=128 is not very usable.
I often need some kind of "absolut error" image, to use it proper as a mask. As for now, I'm taking the to halves [0,128] + [128,255] and re-build what is needed. But this is really Sissiphus' Work (and SLOW), since all calculations are done internally by "subtract" anyway, but simply get put out in the actual manner.

Would it be a big hassle to either

a) give "subtract" a new "mode" feature, or
b) introduce a new filter: "difference"

This would really be of great help, propably not only for me ...
Perhaps, while someone is working on implementing "Layer" in v2.5, he could do that by-the-way?

Thanks for listening

Didée

[Marc FD]

okay i'll add an abssubtract when i would add the subtract YV12 code.

[neuron2]

Originally posted by Krajensky
...simply use Decimate (should be simple to port just Decimate, I'll take a look later today).
I said I'm working on it. :angry:

Are you trying to irritate me or just get me to close my sources?

[trbarry]

BTW, tom and don, i've some question about deinterlacing. i'll read a bit more the sources of TomsMoComp and decomb and then i may ask you some questions

Marc -

Of course.

ATSC isn't often properly done, it lacks the repeated field flags...

Krajensky -

I've noticed that here on some stations, especially WB.

But MPEG2DECx will still decimate somehow, just not as accurately. I haven't looked to see how it does it yet.

Instead of porting a YV12 GreedyHMA I'm thinking of trying to build one into MPEG2DEC2 so it could use the flag info when present. But it is not at the top of my list now that Marc's version is working for YV12. (except maybe for cropping)

- Tom

[sh0dan]

FYI, All XVID colorspace conversions have now been included in AviSynth. They all seem to require mod8, but fixing that should be quite easy. Perhaps I'll even have time for it today.

@developers:
no - this doesn't make AviSynth require NASM. I converted the assembly routines, so that VC6 will compile them just fine.

[trbarry]

sh0dan -

I'm porting SimpleResize today and I notice the chroma planes seem to have only mod 8 pitches. Is that what you finally decided on? I remember some discussion on this, somewhere.

I can work around it but SimpleResize has P4 sse2 code that would be disabled in that case since things would not be 16 byte aligned.

Can we get 16?

- Tom

[scmccarthy]

Tom,

The lines are modded (it that a word?) so you can work on 8 bytes at a time. Or is it eight pixels. Let me put it in a way I know is right.

The UV planes lines are half as long as the Y planes. The Y plane lines are mod 16 and each UV plane line is mod 8. So when you process all the Y samples you can at one time, you are supposed to only need to work on half that amount for each U and V sample.

A work around for this problem would be to convert the frame to NV12 internal to your filter. Never mine what I mean by that. What that does mean is you could try sticking the UV samples you are processing in the same array or in the same register or let them be pointed to by the same pointer. That way the number of samples in each array (substitute register of pointer if you will) is the same for luma and chroma. Combining two mod 8 chorma lines will give you a mod 16 line to work with that matches the luma line in length. It could either be interpolated uvuvuv... which is exactly like NV12, or or start the v samples at the halfway point.

Doing it this way lets you process Y, U, and V in the same loop too. Or process the Y plane separetely and the U anc V planes together. It sounds like you were planning to do each plane separetely. Otherwise this is no problem since then you do have to grab half as many U and V samples as Y samples as you go.

Stephen

[trbarry]

Okay, this is very strange. I see no reply button on posts now. I just clicked where it used to be to reply here. ???? :rolleyes:

Stephen -

Thanks, I think I understand all that. But for a small amount of memory usage P4's could run much faster just by increasing the pitch (not width) of the chroma planes to 16 bytes. Then they could have all lines start on 16 byte alignment. I thought we had already agreed to do that.

- Tom

[scmccarthy]

Tom -

I recently reread the whole avs 2.5 mpeg3dec (sic) thread and I remember the idea was the Y plane gets mod 16 line lengths and the UV planes get mod 8. There are so many ways that it can be done. You could even interleave each line using the same chroma samples for every two luma lines and use a luma mask again. Of course, then one comes to realize that planes are easier than interleaved files once you get used to them.

What I am saying is if you process the three planes concurently in the same loop, you will not need the UV planes to be mod 16 if the Y plane is only mod 16, because there are half as many samples in the UV plane per line. And lets say every time you stuff an mmx register with Y data, it you like you could stuff the next mmx register with interpolated UV data. That way you hit the end of each line at the same time. Or every time you fill an int64 with Y data fill half an int64 with U data and the other half with V data. Not nesessarily interpolation like uvuvuv.. but uuuuuuu then vvvvvvvv.

I am glancing at the SmartResize.cpp file, but I can't read mmx code yet.

Stephen

[trbarry]

Whatever.

I'm making a version of YV12 SimpleResize that just uses SSE2 instructions on every other line on the chroma planes. On the odd lines it will fall back to SSE. But it seems a shame.

- Tom

[-h]

FYI, All XVID colorspace conversions have now been included in AviSynth. They all seem to require mod8, but fixing that should be quite easy. Perhaps I'll even have time for it today.

I believe that Pete recently amended the colorspace code to support any mod2 resolutions, or mod4 in the case of field-based video.

Also, XviD's functions which work to or from RGB values are suboptimal, and even buggy in some cases.

-h

[sh0dan]

@-h:
I made them mod2 capable, by using a combination of the forced mod16 alignment, and using addborders/crop before and after resize, if the image wasn't mod8. Fairly hacky, but it works nicely.

YV12 -> YUY2 actually uses SeparateFields / Weave, when resizing Fieldbased material.

I've found that YV12 -> RGB24 has chroma noise on the leftmost pixel - I was going to ask if it was a known XVID problem, but I guess it is. RGB32 is fine though.

Anyway, replacing the routines with updated ones are trivial - I kept them completely separate, and haven't changed anything major.

@trbarry: Yes - chroma is only mod8, but there is a 50/50 chance it will be mod16 ;) You _could_ do a mod8 -> mod16 unpack - it's mainly a matter of a few BitBlt's - don't know if it's faster though.

[Koepi]

Shodan:

the YUV->RGB stuff is a known bug for nearly a year now :) Isibaar said the MMX routines are causing this, pure-C should work flawless.

Regards
Koepi

[scmccarthy]

@Koepi

MMX routines should work flawlessly too. I had the silly notion that MMX is so difficult to read that no one knows how these routines work. But that can't be right, Color Space conversions are pretty straight forward.:)

[sh0dan]

[wtf - it made a double post - I must have hit back - well anything to boost my post count :sly: ]

[sh0dan]

Well - as much as I'd like to rewrite them from scratch (I did do the ConvertRGB32toYUY2, and it was a real "pleasure"), I feel we get much further by using them. Right now I don't care much about the RGB24 stuff - if people would like flawless operation I can map the conversion to do a YV12 -> RGB32 -> RGB24. It'll be slow, but it'll give the correct result.

(oh - oh - this will give me an excuse to use my newly mmx-optimized RGB32 -> RGB24 routine - done a night I was really bored ;)

[neuron2]

Originally posted by neuron2
Are you trying to irritate me or just get me to close my sources? Oh, there I go being thin-skinned and rude again. Please accept my apologies, Krajensky.

[Wilbert]

Right now I don't care much about the RGB24 stuff - if people would like flawless operation I can map the conversion to do a YV12 -> RGB32 -> RGB24. It'll be slow, but it'll give the correct result.

I think that TMPGEnc users would appreciate it if there will be a fast YV12 -> RGB24 conversion :) What about the conversions that Marc FD made (in his mpeg2dec3.dll) are they the same as yours?

[Marc FD]

>What about the conversions that Marc FD made (in his mpeg2dec3.dll) are
>they the same as yours?

no.

first, i didn't made them. it's jackei's code.

it works well and it's mmx optimised, i recommend it for YV12->RGB24 direct (specially interlaced) convertion.

[trbarry]

If anyone is interested I also have fast SSE2 color conversions routines as part of a package someone sent me for DVD2AVI. But that didn't seem to be the bottlenect so I never put them in and they are still (by me) untested.

- Tom

[sh0dan]

Originally posted by Wilbert
I think that TMPGEnc users would appreciate it if there will be a fast YV12 -> RGB24 conversion :) What about the conversions that Marc FD made (in his mpeg2dec3.dll) are they the same as yours?

That's why I optimized the RGB32 -> RGB24 code. Anyway, I'll look into it - the current code is _very_ fast - I don't think you'll notice the RGB32 -> RGB24 conversion actually.

@neuron: Nice to see, that we have a mature moderator, capable of admitting his own faults! Respect!

[Wilbert]

That's why I optimized the RGB32 -> RGB24 code. Anyway, I'll look into it - the current code is _very_ fast - I don't think you'll notice the RGB32 -> RGB24 conversion actually.
Ok. I guess ConvertToRGB24 on a YV12 source results in an error?

At the end we have to convince this Japanese guy to add an option "fast recompress like in Virtualdub" in TMPGEnc such that there are no conversions inside TMPGEnc :)

[sh0dan]

Originally posted by Wilbert
Ok. I guess ConvertToRGB24 on a YV12 source results in an error?

At the end we have to convince this Japanese guy to add an option "fast recompress like in Virtualdub" in TMPGEnc such that there are no conversions inside TMPGEnc :)

No, no - it performs the conversion internally, just use converttotgb24() - I'm pretty sure it wont affect you encoding speed at all.

[Wilbert]

Sorry for asking dumb questions. You said somewhere:

"I've found that YV12 -> RGB24 has chroma noise on the leftmost pixel - I was going to ask if it was a known XVID problem, but I guess it is. RGB32 is fine though."

Koepi responded "the YUV->RGB stuff is a known bug for nearly a year now".

You responded "Right now I don't care much about the RGB24 stuff - if people would like flawless operation I can map the conversion to do a YV12 -> RGB32 -> RGB24. It'll be slow, but it'll give the correct result."

What should people do: "YV12 --> RGB24" resulting in a small error most people won't notice, or "YV12 --> RGB32 --> RGB24" which would be correct. But if there is (almost) no difference in speed, why not advise the latter conversion.

[sh0dan]

Because this is what AviSynth does! :)

When you enter converttorgb24(), and AviSynth detects that the source is YV12, it will internally do what is the same as converttorgb32() / converttorgb24() - so whatever you enter you get the same speed and the same result :)

[neuron2]

Originally posted by sh0dan
@neuron: Nice to see, that we have a mature moderator, capable of admitting his own faults! Respect! Who said I have faults?! :angry:


;)