Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th February 2010, 16:18   #81  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,329
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
Wilbert is offline   Reply With Quote
Old 28th February 2010, 07:16   #82  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
@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?
IanB is offline   Reply With Quote
Old 28th February 2010, 19:57   #83  |  Link
XhmikosR
Registered User
 
Join Date: Mar 2007
Location: Hellas (Greece)
Posts: 543
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.
__________________
My Specs

Last edited by XhmikosR; 14th March 2010 at 19:14.
XhmikosR is offline   Reply With Quote
Old 1st March 2010, 09:05   #84  |  Link
tin3tin
Registered User
 
tin3tin's Avatar
 
Join Date: Mar 2005
Posts: 365
Quote:
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.]
__________________
DVD slideshow GUI(Freeware).
tin3tin is offline   Reply With Quote
Old 1st March 2010, 12:50   #85  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by XhmikosR View Post
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
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 1st March 2010, 13:47   #86  |  Link
XhmikosR
Registered User
 
Join Date: Mar 2007
Location: Hellas (Greece)
Posts: 543
Quote:
Originally Posted by tin3tin View Post
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.

Quote:
Originally Posted by kemuri-_9 View Post
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.
__________________
My Specs
XhmikosR is offline   Reply With Quote
Old 1st March 2010, 14:58   #87  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,329
Quote:
I'm sorry but I cannot find any 2.6 branch.
http://avisynth2.cvs.sourceforge.net...v=avisynth_2_6
Wilbert is offline   Reply With Quote
Old 1st March 2010, 15:05   #88  |  Link
XhmikosR
Registered User
 
Join Date: Mar 2007
Location: Hellas (Greece)
Posts: 543
Thanks a lot Wilbert. Is there any particular reason why it hasn't been merged in the head branch?
__________________
My Specs
XhmikosR is offline   Reply With Quote
Old 1st March 2010, 21:34   #89  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,329
Quote:
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 is offline   Reply With Quote
Old 14th March 2010, 17:22   #90  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,329
@IanB and others,

Quote:
* 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

Quote:
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?
Wilbert is offline   Reply With Quote
Old 14th March 2010, 21:39   #91  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
Why has fracking vBulletin® stopped nesting quoted replies again
Quote:
Originally Posted by Wilbert View Post
Quote:
* 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
Except that would change the existing YV12<->YUY2 behaviour.

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


Quote:
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().

Quote:
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!
IanB is offline   Reply With Quote
Old 14th March 2010, 22:26   #92  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,390
Quote:
Thorts!
Sir! Yes, Sir!

Quote:
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 ...
Quote:
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.
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 15th March 2010, 21:42   #93  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
Quote:
Originally Posted by Didée View Post
Quote:
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 ...
Yes, there is an implied assumption that there will be some script control over the gamma value used, i.e. ConvertToYV96(Gamma=2.2)

Quote:
Quote:
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.
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 is offline   Reply With Quote
Old 19th March 2010, 03:01   #94  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
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.
IanB is offline   Reply With Quote
Old 11th April 2010, 01:00   #95  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
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*
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 11th April 2010, 03:31   #96  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
@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.
IanB is offline   Reply With Quote
Old 11th April 2010, 04:20   #97  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by IanB View Post
@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)

Quote:
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...

Quote:
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?

Quote:
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?
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 17th April 2010, 12:24   #98  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,329
@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)
Wilbert is offline   Reply With Quote
Old 17th April 2010, 14:50   #99  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
@Wilbert,

Yes I saw that. I just checked in a fix and a tune. SF is back online at last.
IanB is offline   Reply With Quote
Old 25th April 2010, 07:54   #100  |  Link
Frank K Abbott
Registered User
 
Join Date: Mar 2010
Posts: 69
How does this function with MT and setmtmode whose dll is only out for 2.5.8 so far?
Frank K Abbott is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:17.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.