AviSynth 2.6.0 Alpha3 [May 25th, 2011]

[Wilbert]

I was looking at the color conversions (for the documentation), and my head is spinning a bit Are the following statements correct:

* ChromaPlacement and ChromaResample options are only available for the 'planar conversion parts' of a conversion
** example1: YV16 -> RGB goes as follows: YV16->YV24 (options above are used); YV24->RGB
** example2: YV411 - > YV12
* YUV planar -> RGB via YV24
* YUV planar (except "YV12 and options disabled") -> YUY2 via YV16
* Both for C++ and the ASM code ConvertToRGB the missing chroma samples are interpolated (using a [1 1] kernel) [C++ sampling was different in previous versions]
* RGB -> YUV planar via YV24
* YUY2 -> YUV planar via YV16
* conversions to and from YUV9 are not implemented yet

[IanB]

@Wilbert,

Yes, what you have said looks right. Expressing it another way :-

There are the 2.5 core conversions, these are still in place when they are the most direct path.
* YV12 -> YUY2 (Interlaced option)
* YUY2 -> YV12 (Interlaced option)
* YUY2 -> RGB {0,1,0}/{1,0,1} Kernels (Matrix option)
* RGB -> YUY2 ConvertToYUY2 {0,1,1} Kernel (Matrix option)
* RGB -> YUY2 ConvertBackToYUY2 {0,1,0} Kernel (Matrix option)

For 2.6 there are new core conversions.
* YUY2 -> YV16 (lossless)
* YV16 -> YUY2 (lossless)
* Planar -> Planar (Uses resizer core on UV planes, ChromaPlacement, ChromaResample options, Interlaced option)
* YV24 -> RGB (Matrix option)
* RGB -> YV24 (Matrix option)

As for YUV9, YV411, etc I will probably bury these in a user generic planar umbrella where the user can specify the desired chroma subsampling.

So the explicit core formats will be Y8, YV12, YV16, YV24, YUY2, RGB24 and RGB32. Everything else will be User Generic YUV Planar with 1,2 or 4, H and V subsampling. Thorts?

[XhmikosR]

Has anyone compiled AviSynth 2.60 from CVS with Windows SDK v7.0? I found out that I get the errors posted in my previous post if I use the Windows 7 SDK. If I use SDK v6.0A which ships with MSVS 2008 then AviSynth 2.6 compiles fine. Here are the rest of the warnings I get with /W3 and _CRT_SECURE_NO_WARNINGS. And here is a fresh build of AviSynth 2.60 with a full installer for anyone interested.
BTW, I thought the MT was included in AviSynth 2.6, but apparently it's not.

[tin3tin]

And here is a fresh build of AviSynth 2.60 with a full installer for anyone interested.

Thanks

[BTW. it is still installing in a folder called '2.5' - but you properly already know this, for the purpose of overwriting the old version.]

[kemuri-_9]

Originally Posted by XhmikosR

BTW, I thought the MT was included in AviSynth 2.6, but apparently it's not.

iirc it's only in the avs 2.6 branch as of yet, from not yet having merged its way to the main/head branch

[XhmikosR]

Originally Posted by tin3tin

Thanks

[BTW. it is still installing in a folder called '2.5' - but you properly already know this, for the purpose of overwriting the old version.]

Everything is as it is in the CVS. But I suppose that's the reason.

Originally Posted by kemuri-_9

iirc it's only in the avs 2.6 branch as of yet, from not yet having merged its way to the main/head branch

I'm sorry but I cannot find any 2.6 branch.

[Wilbert]

I'm sorry but I cannot find any 2.6 branch.

http://avisynth2.cvs.sourceforge.net...v=avisynth_2_6

[XhmikosR]

Thanks a lot Wilbert. Is there any particular reason why it hasn't been merged in the head branch?

[Wilbert]

Thanks a lot Wilbert. Is there any particular reason why it hasn't been merged in the head branch?

Two reasons:
* I think IanB wants to add this functionality in some other way.
* Other things (like the new plugin api) are also needed to be done before going beta.

I'm sure he responds if above is not correct.

[Wilbert]

@IanB and others,

* YUV planar (except "YV12 and options disabled") -> YUY2 via YV16

To get some consistency, perhaps it's good to change this to:

* YUV planar (always) -> YUY2 via YV16

So the explicit core formats will be Y8, YV12, YV16, YV24, YUY2, RGB24 and RGB32. Everything else will be User Generic YUV Planar with 1,2 or 4, H and V subsampling. Thorts?

Sounds fine. I guess we need two generic planar formats: YUV and PRGB. Also:

the conversions:

ConvertToPRGB(sample_bits=8/16/32, dither=true/false)
ConvertToYUV(sample_bits=8/16/32, h_subs=1/2/4, v_subs=1/2/4, dither=true/false)

and the functions:

IsPRGB(sample_bits=8/16/32)
IsYUV(sample_bits=8/16/32)

When doing a conversion from RGB to YUV (vice versa likewise):
(1) interleaved RGB -> planar RGB (if source is interleaved);
(2) planar RGB -> planar YUV (sample_bits constant)
(3) planar YUV -> planar YUV (dithering to the target sample_bits if necessary)
(4) planar YUV -> planar YUV (subsampling if necessary)
(5) planar YUV -> interleaved YUV (if target is interleaved)

What do you think about this? Or do you want to leave this for v2.61? I can take a stab at the functions above. I got planar RGB (just 3x8 bit) already working (also in BlankClip for example).

I also asked Tom about his dithering filter: Dither16to8Bit(): http://forum.doom9.org/showthread.ph...34#post1023134 . Hopefully he will respond and we can use that.

There were discussions in the past about whether it should be 15bit, 16bit signed, 16bit unsigned. I don't think there was an agreement on something. Thoughts, anyone?

[IanB]

Why has fracking vBulletin® stopped nesting quoted replies again

Originally Posted by Wilbert

To get some consistency, perhaps it's good to change this to:

* YUV planar (always) -> YUY2 via YV16

Except that would change the existing YV12<->YUY2 behaviour.

Maybe we should announce the legacy conversions will retire in say 2.6.2

Sounds fine. I guess we need two generic planar formats: YUV and PRGB. Also:

the conversions:

ConvertToPRGB(sample_bits=8/16/32, dither=true/false)
ConvertToYUV(sample_bits=8/16/32, h_subs=1/2/4, v_subs=1/2/4, dither=true/false)

and the functions:

IsPRGB(sample_bits=8/16/32)
IsYUV(sample_bits=8/16/32)

I haven't really thought to much about script presentation yet. My thrust is to have consistent usage of bits in the Pixel_type so you get IsRGB(), IsYUV(), IsPlanar(), IsInterleaved(), Is8Bit(), Is16Bit(), etc then build higher concepts like IsRGB32() and IsYUY2().

There were discussions in the past about whether it should be 15bit, 16bit signed, 16bit unsigned. I don't think there was an agreement on something. Thoughts, anyone?

At the moment it doesn't matter until we actually have map between pixel formats. The API currently just chucks 8, 16 or 32 bit chunks at you, what they mean is mostly undefined. We assume if it is 8 bit RGB then all 0 is black and all 255 is white and for 8 bit YUV then black is 16, white is 235 and chroma is [-112, +112], except when someone plays with PC levels. The interpretation can depend on the pixel type, not sure it is a great idea to actually do it this way but ...

Likewise while in deep thought mode, what about 32bit pixels. Are they float, int32 or uint32. Is black 0.0 or 16.0 or another value. Is white 1.0, 235.0 or another value.

Also in 16 and 32 bit pixel formats do we undo gamma and make the values linear. My personal opinion is a very strong yes. Currently almost every avisynth filter will average 64 and 192 to get 128 and this is visually acceptable most of the time, but in a purely linear intensity case it should be around 119. Sometimes it matters sometime it does not, e.g. when doing antialiasing there is a vary significant improvement when including gamma in the calculations.

Thorts!

[Didée]

Thorts!

Sir! Yes, Sir!

Also in 16 and 32 bit pixel formats do we undo gamma and make the values linear. My personal opinion is a very strong yes.

If so, there should be some sort of boolean switch for that. Not all clips' data represent actual image data. Some clips might be masks or difference-maps or whatnot, and ...

Currently almost every avisynth filter will average 64 and 192 to get 128 and this is visually acceptable most of the time, but in a purely linear intensity case it should be around 119.

... especially when working with differences, it's usually preferable that (64+192)/2 gives 128, not 119.

[IanB]

Originally Posted by Didée

If so, there should be some sort of boolean switch for that. Not all clips' data represent actual image data. Some clips might be masks or difference-maps or whatnot, and ...

Yes, there is an implied assumption that there will be some script control over the gamma value used, i.e. ConvertToYV96(Gamma=2.2)

... especially when working with differences, it's usually preferable that (64+192)/2 gives 128, not 119.

I am not saying (64+192)/2 ever gives 119, but that we assume the value 192 represents a pixel that is visually 3 times brighter than the value 64. Well more like 30000 versus 10000, I hope you get the idea ....

In gamma=2.2, 8 bit space, 192 represents 87.7% brightness, 128 represents 73.0%, 119 represents 70.6% and 64 represents 53.2%

[IanB]

CVS Maintenance

I had a little spare time today so I started folding the "avisynth_2_6" branch back into the the main branch. The docs are all done, as is most of the main code (a few core elements are still pending). The 3 plugins are still to be done.

[kemuri-_9]

what's the status on how avisynth_c.h is going to be handled for 2.6?

Asking because this is going to be necessary for x264's purposes in the relatively near future.

for the time being I've edited the current avisynth_c.h to recognize the new colorspaces with new inline functions which is the bare minimum that i require atm.
but this is the exact opposite of what happened to avisynth.h, where the code behind that wandered off to interface.cpp (since there's been a move to prevent baking code in)

I'm guessing the end result of the moved interface code is to
A) export the classes/functions via __declspec and require an import lib for plugin writers
or
B) add new exported functions(s) to the avisynth.dll that will return a struct or something along these lines that will have the functions contained within.

and the C interface would likely be handled similarly whatever the case ends up being...
*ramble* *ramble*

[IanB]

@kemuri-_9,

If one bakes 2.6 code into an external module, then it's one's problem when we change the API and users fall out of the sky.

All the baked things declared "AVSC_INLINE" become proper "AVSC_API" with matching new C entry point for the real code. Some duplicates go away or get a legacy #define.

Choice of using avisynth.lib for static linkage like now or new "AVSC_NO_DECLSPEC" for dynamic linkage. That name may change.

The ""AVSC_INLINE AVS_Library * avs_load_library" and "AVSC_INLINE void avs_free_library(AVS_Library *library)" need some more thought so that every module that #include <avisynth_c.h> does not get a duplicate copy of that code. I just parked the code as contributed so it would not be forgotten.

Also I want to try to support both __cdecl and __stdcall calling conventions, i.e. export 2 sets of entry points, __stdcall keeps the existing names, __cdecl gets some prefix and/or suffix.

[kemuri-_9]

Originally Posted by IanB

@kemuri-_9,

If one bakes 2.6 code into an external module, then it's one's problem when we change the API and users fall out of the sky.

Yes, this is correct so i could technically continue with my new baked API (that i stole/adapted from interface.cpp) but I'd rather not do that when there's something else in the works that's going to be the correct/supported way.
though i will need the baked API in a way so we maintain avs 2.5 support in x264. (but that's a different situation that I'll pursue at the necessary time)

All the baked things declared "AVSC_INLINE" become proper "AVSC_API" with matching new C entry point for the real code. Some duplicates go away or get a legacy #define.

which baked functions from avisynth_c.h are going to be made into API?

IMO all the "avs_is_yv12, avs_is_yuy2", and etc are fluff as all of these are just convenience methods that are already achievable via avs_is_colorspace.
Though avs_is_colorspace depends on the enums for each of the colorspaces being properly defined and unlikely to change...
But with how the csp enums are setup now with the current scheme of things, it doesn't look like they'll need to be changed...

Choice of using avisynth.lib for static linkage like now or new "AVSC_NO_DECLSPEC" for dynamic linkage. That name may change.

The ""AVSC_INLINE AVS_Library * avs_load_library" and "AVSC_INLINE void avs_free_library(AVS_Library *library)" need some more thought so that every module that #include <avisynth_c.h> does not get a duplicate copy of that code. I just parked the code as contributed so it would not be forgotten.

Yes, I had noticed you committed this eventually after my original request for the feature....
what were your ideas on changing it to?

Also I want to try to support both __cdecl and __stdcall calling conventions, i.e. export 2 sets of entry points, __stdcall keeps the existing names, __cdecl gets some prefix and/or suffix

the only point i see for __cdecl is for explicit declaration for functions using varargs (since they are __cdecl already).

generally the stdcall form is more preferred on windows due to it cleaning the stack by the callee rather than by the caller.
so what would be the exact reason to have __cdecl varieties of the __stdcall methods?

[Wilbert]

@IanB,

Apparently there is a bug in the rgb resizers (2.58/2.6): http://forum.doom9.org/showthread.ph...61#post1392361 (thanks to JoshyD)

[IanB]

@Wilbert,

Yes I saw that. I just checked in a fix and a tune. SF is back online at last.

[Frank K Abbott]

How does this function with MT and setmtmode whose dll is only out for 2.5.8 so far?