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

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 23rd October 2016, 22:19   #2481  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by Sparktank View Post
YUVA, fancy.

I feel like I just walked into the same building that just got revonations.
Let's call it face-lift.
pinterf is offline  
Old 24th October 2016, 06:45   #2482  |  Link
vcmohan
Registered User
 
Join Date: Jul 2003
Location: India
Posts: 890
Many thanks for this. I still need few clarifications. Sorry to bother you. For the 10 t0 14 bit depth formats is it correct to assume that avs+ provides to the plugin 16 bit values with the MSB s filled in with appropriate number of zeroes.
I also infer that packed RGB formats support only 8bit or 16 bit per color .
In case of float U and V values, vapoursynth uses -0.5 to + 0.5.range. Any reason for this departure by AVS+? Which of these are standard?
__________________
mohan
my plugins are now hosted here
vcmohan is offline  
Old 24th October 2016, 08:11   #2483  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by vcmohan View Post
Many thanks for this. I still need few clarifications. Sorry to bother you. For the 10 t0 14 bit depth formats is it correct to assume that avs+ provides to the plugin 16 bit values with the MSB s filled in with appropriate number of zeroes.
Yes, the internal filters (and the external ones in the future) are responsible to properly clamp the values to the 0..max_pixel_value range.
There are places in the core filters however where I had to make extra checkings for the valid values, mostly in functions that use lookup, to avoid overindexing a 10 bit lut table with a falsely presented higher pixel value.
Or in Histogram. But for most of other filters there is no pre-check, that would slow down the processing.

Quote:
Originally Posted by vcmohan View Post
I also infer that packed RGB formats support only 8bit or 16 bit per color .
In case of float U and V values, vapoursynth uses -0.5 to + 0.5.range. Any reason for this departure by AVS+? Which of these are standard?
No reason, for most of the internal filters it was much easier not to deal with the range shift, UToY, VToY works transparently, did not have to make special cases for differently handling U and V just for float, etc. And this three months timeframe was clearly not enough to look at all these problems and questions from an independent, external overview.

Last edited by pinterf; 24th October 2016 at 08:17.
pinterf is offline  
Old 24th October 2016, 10:50   #2484  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Avisynth Plus Quick reference guide

Color spaces

Greyscale (Y only)
  • 8 bit: Y8
  • 10, 12, 14, 16 bits: Y10, Y12, Y14, Y16
  • 32 bits (float): Y32 (yes, Y32 instead of YS)
Check: IsY (instead of IsY8 which is 8 bit only)
ComponentCount() for greyscale formats returns 1

YUV: planar format with a luma (Y) and two chroma (U, V) channels
  • 8 bits: YV12, YV16, YV24, YV411
    for filters requiring colorspace name YUV420/YUV422/YUV444 or YUV420P8/YUV422P8/YUV444P8 is also accepted
  • 10 bit: YUV420P10, YUV422P10, YUV444P10
  • 12 bit: YUV420P12, YUV422P12, YUV444P12
  • 14 bit: YUV420P14, YUV422P14, YUV444P14
  • 16 bit: YUV420P16, YUV422P16, YUV444P16
  • 32 bit (float/Single precision): YUV420PS, YUV422PS, YUV444PS
YV411 has no high bit depth variant

Check#1: Is420, Is422, Is444 (instead of IsYV12/IsYV16/IsYV24 which are for 8 bits only)
Check#2: IsYUV
for compatibility reasons, IsYUV returns true for YUY2 and Y also
For strict checking one can check IsPlanar (for distinct from YUY2) and ComponentCount==3 (for distinct from greyscale)

YUVA: planar format with a luma (Y), two chroma (U, V), and one Alpha (A) channels
  • 8 bit: YUVA420/YUVA422/YUVA444 or YUVA420P8/YUVA422P8/YUVA444P8
  • 10, 12, 14, 16, 32 bits: see corresponding YUV name and use YUVA
Check#1: Is420, Is422, Is444
Check#2: IsYUVA
ComponentCount for YUVA returns 4
Note: YUVA is a separate color space family, in order to handle YUV and YUVA clips, you have to check for YUVA separately.

Packed RGB
8 bits: RGB24, RGB32 (BGR and BGRA internally)
16 bits: RGB48, RGB64

Check: IsRGB ; note: IsRGB now true for planar RGB(A) color spaces.
Check2: IsRGB24, IsRGB32, IsRGB48, IsRGB64

Planar RGB, RGBA: RGB family with 3 or 4 planes of colors
Plane order is GBR and GBRA internally

8 bits: RGBP, RGBAP or RGBP8, RGBAP8
10, 12, 14, 16 bits: RGBP10..RGBP16, RGBAP10..RGBAP16
32 bits (float/Single precision): RGBPS, RGBAPS

Check: IsPlanarRGB or IsPlanarRGBA respectively
Check#2: generally IsRGB is also true

Colorspace conversions
  • ConvertToY for all bit depths (8 bit only: ConvertToY8)
  • ConvertToYUV420 for all bit depths (8 bit only: ConvertToYV12)
  • ConvertToYUV422 for all bit depths (8 bit only: ConvertToYV16)
  • ConvertToYUV444 for all bit depths (8 bit only: ConvertToYV24)
  • ConvertToYUV411 (this is 8 bit only: same as ConvertToYV411)
All parameters are the same as in their old 8 bit-only counterparts

YUV420: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s
Greyscale: c[matrix]s
others: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s
  • ConvertToPlanarRGB
  • ConvertToPlanarRGBA
    ConvertToPlanarRGBA will copy the Alpha channel of a packed RGB32 or RGB64 format
  • ConvertToRGB24
  • ConvertToRGB32
  • ConvertToRGB48
  • ConvertToRGB64
Conversions to either packed or planar RGB targets have the same parameters as in their old 8 bit-only counterparts
(c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s)

matrix parameter can have a new value
  • rec601
  • rec709
  • PC.601/PC709
  • PC.709/PC709
  • AVERAGE
  • rec2020 (new)

Colorspace conversions are working within the same bit depth:
e.g. you cannot convert a 10 bit YUV420P10 to RGB64.
  • AddAlphaPlane([mask=default_alpha_value])
    YUV->YUVA, RGBP -> RGBAP, RGB24->RGB32, RGB48->RGB64
    If optional mask parameter is supplied, the alpha plane is set to this value.
    Default: maximum pixel value of current bit depth (255/1023/4095/16383/65535/1.0)

    If the current video format already has alpha channel and mask is provided, then the alpha plane will be overwritten with the new mask value.
  • RemoveAlphaPlane
    YUVA->YUV, RGBAP->RGBP, RGB32->RGB24, RGB64->RGB48

Bit depth conversion
ConvertBits(bits[,truerange,dither)

Old versions: ConvertTo8bit, ConvertTo16bit(bits), ConvertToFloat
I recommend that you use the ConvertBits format.

For Y, U and V channels the conversion is a simple bit-shift.
For R, G, B and A channels the pixel values are "streched" in order to have 0..255 to be mapped to 0..65535
At the moment you cannot choose this behaviour as a parameter.

parameters:
  • bits
    target bit depth: 8, 10, 12, 14, 16, 32
  • truerange
    default: true
    Choose this if you want to convert 10-16 bit formats without re-scaling underlying pixel data. E.g.
    clip10bit.ConvertBits(16, truerange=false) will leave pixel data in the 0..1023 range, but will change the video format from YUVxxxP10 to YUVxxxP16
  • dither
    optional, at the moment works for 10-16 bits->8 bit conversions
    Valid values:
    -1: no dither (default)
    0: ordered dither

    of course, more methods will come later


Compatibility conversions
Conversions for hacked 16 bit formats.
For filters that use 16 bit video data in a fake 8 bit colorspace. Avisynth plus provides built-in conversions for your convenience until more plugins supporting high bit depth appear.
  • ConvertToStacked
  • ConvertFromStacked([bits=b])
  • ConvertToDoubleWidth
  • ConvertFromDoubleWidth([bits=b])

Misc. video info properties
  • ComponentSize
    8 bit: 1 (bytes)
    10-16 bit: 2 (bytes)
    32 bit float: 4 (bytes)
  • BitsPerComponent
    8, 10, 12, 14, 16, 32
  • ComponentCount
    1 for greyscale
    3 for YUV, Planar RGB, RGB24 and RGB48
    4 for YUVA, Planar RGBA, RGB32 and RGB64

Last edited by pinterf; 24th October 2016 at 11:36.
pinterf is offline  
Old 24th October 2016, 12:16   #2485  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,547
What's the AVERAGE matrix good for? Is this an odd attempt at naming YCgCo or something else?
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline  
Old 26th October 2016, 15:31   #2486  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Hello,

I always used to add a logo on my videos using this command :


Now in avisynth r2290 x64 it returns me this :
[IMG]https://s14.postimg.org/unu51lwc1/22317820161026153618crcr.png
[/IMG]

I read the previous post about references and tried with ConvertToYUV420() instead of ConvertToYV12() but the result is the same as last picture.
If i leave the ConvertToYV12() where it is the result is always messed up, if i move it at the end of the script it works.

Don't know if i understand everything correctly or missing something, i'm a bit lost in this now.

If anyone have a clue about this please, thanks a lot for the help.

Last edited by Yanak; 23rd January 2018 at 00:21.
Yanak is offline  
Old 26th October 2016, 16:39   #2487  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by Yanak View Post
Hello,

I always used to add a logo on my videos using this command :

Now in avisynth r2290 x64 it returns me this :

I read the previous post about references and tried with ConvertToYUV420() instead of ConvertToYV12() but the result is the same as last picture.
If i leave the ConvertToYV12() where it is the result is always messed up, if i move it at the end of the script it works.

Don't know if i understand everything correctly or missing something, i'm a bit lost in this now.

If anyone have a clue about this please, thanks a lot for the help.
Thanks for the report. Looking into the fix right now.
pinterf is offline  
Old 26th October 2016, 16:42   #2488  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
So it's a bug then, was not really sure about it,

Take your time and thanks for the hard work on this
Yanak is offline  
Old 26th October 2016, 18:47   #2489  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Expected sooner, but the first bug was reported. Big thanks for it, really.

The fix is available:

Avisynth Plus r2294MT

Avisynth Plus r2294-MT
Date: 20161026
- Fix: Overlay 8 bit YV12 and possibly YUY2
- New: DirectShowSource and AviSource
16-bit RGB input support (BGR[48], BRA[64])

The addition came from our new contributor, ignus2.

Changed files compared to the r2290 release:
avisynth.dll and directshowsource.dll
pinterf is offline  
Old 26th October 2016, 19:42   #2490  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Thanks a lot for the dedicated work and quick fix,

Have a nice day.

Ps : tested and yes it works as before, thanks again

Last edited by Yanak; 26th October 2016 at 19:53.
Yanak is offline  
Old 26th October 2016, 21:45   #2491  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
Should converting between linear/gamma be handled by internal filters somehow?
ajp_anton is offline  
Old 27th October 2016, 13:33   #2492  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,297
Is something like this still working with all these new format/size, or should i do otherwise ?
Code:
const int src_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width);
If otherwise, what should i do ?

jpsdr is offline  
Old 27th October 2016, 14:32   #2493  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Whats wrong with this ?
Code:
const int src_width = src->GetRowSize(PLANAR_Y)
vi.width is width in pixels, GetRowSize(PLANAR_Y) gets row size in bytes of Y if Planar and also works ok with YUY2 / RGB.

I should not imagine that anything has changed in AVS+
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline  
Old 27th October 2016, 14:34   #2494  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by jpsdr View Post
Is something like this still working with all these new format/size, or should i do otherwise ?
Code:
const int src_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width);
If otherwise, what should i do ?

It depends, what do you want to do with it?

For non-planar sources BytesFromPixels(1) will return
RGB24: 3
RGB32: 4
RGB48: 6
RGB64: 8
YUY2: 2

If you want to get the byte size of a row (within one plane for planar or the whole packed line for old RGB formats), by using BytesFromPixels(width) you will get the occupied bytes of one row.

I suppose you use it in resampler, this is how it is used there:
int work_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width) / pixelsize
where pixelsize is vi.ComponentSize() (1 for 8 bits, 2 for 10-16 bits, 4 for float)
pinterf is offline  
Old 27th October 2016, 15:11   #2495  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,297
Ok, thanks.
jpsdr is offline  
Old 27th October 2016, 18:01   #2496  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
About 16-bit RGB support:
I'd like to have some opinions here.

The fourccs I added to AviSource/DirectShowSource was based on what ffmpeg defined for them (bgr48le: BGR0 ie. BGR[48], bgra64le: BRA@ ie. BRA[64]):
https://github.com/FFmpeg/FFmpeg/blo...bavcodec/raw.c

Bottom-first vs Top-first
Currently, afaik, packed RGB (both 8/16-bit) is always stored inside avs+ upside down (bottom-first). This is OK (doesn't matter), the question is how to handle 16-bit RGB data when it enters/exits avs+. We all know for DIB formats inside avi/vfw/dshow the sign of the height matters: negative height means top-first, positive height means bottom-first.
BGR0 and BRA@ are basically the 16-bit equivalents of BI_RGB 24/32 bit, however it is unclear whether they should be treated as DIB or not (meaning: should the sign of the height matter or not).
We had a long discussion with shekh about this on how to interpret it, and we think these formats don't qualify for the DIB rule, so the sign of the height shouldn't matter (as they are separate fccs), or should it?
^Opinions needed here.

The reason fcc:BI_RGB with bits:64 doesn't work (when coming from a codec for example) is that it makes dshow croak. I believe it is because dshow tries to match to a mediasubtype, and there is none for BI_RGB 64bit, so it fails. So the only option is to use some fourcc, for which the only one existing is defined in ffmpeg (the fact that ffmpeg however cannot read back AVIs written by itself containing BGR0/BRA@ fourcc is another story).

Y8 as DIB
Avs+ AviSource/DirectShowSource treats Y8 as DIB meaning the sign of the height matters and also expects 4-byte boundary padding. Why is that (source)?

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline  
Old 27th October 2016, 18:07   #2497  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,547
Quote:
Originally Posted by Ignus2 View Post
About 16-bit RGB support:
...

Y8 as DIB
Avs+ AviSource/DirectShowSource treats Y8 as DIB meaning the sign of the height matters and also expects 4-byte boundary padding. Why is that (source)?

Greets,
I.
This is simple. Planar formats aren't aligned to 4 bytes. What's a packed format? Formats with only one plane. Y8 has only one plane and thus follows this rule. Note that partially packed formats like NV12 with its two planes aren't packed. This is common wisdom and you'll notice corrupted output everywhere once you stop following it. See AVFS bugs, and probably some ancient vdub blog posts and the avisynth vfw code. That part has nothing to do with DIB btw.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet

Last edited by Myrsloik; 27th October 2016 at 18:10.
Myrsloik is offline  
Old 27th October 2016, 18:24   #2498  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by Myrsloik View Post
This is simple. Planar formats aren't aligned to 4 bytes. What's a packed format? Formats with only one plane. Y8 has only one plane and thus follows this rule. Note that partially packed formats like NV12 with its two planes aren't packed. This is common wisdom and you'll notice corrupted output everywhere once you stop following it. See AVFS bugs, and probably some ancient vdub blog posts and the avisynth vfw code. That part has nothing to do with DIB btw.
Thanks, now I'm wiser
EDIT: And why does Y8 take the sign of the height into account (in AviSource)? Is it also something common I'm not yet aware of?

Any thoughts on 16-bit packed RGBA (the other question)?
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 27th October 2016 at 18:40.
Ignus2 is offline  
Old 27th October 2016, 23:00   #2499  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
This may be strange, but why we don't has hex colors (aka Web colors)?

I think it will be useful in Motion Analyze
__________________
See My Avisynth Stuff
real.finder is offline  
Old 27th October 2016, 23:20   #2500  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
I've no idea how you would want the hex colors arranged (if more than 8 bits per channel),
but maybe some of the scripting here could be persuaded to provide whatever you require.

http://forum.doom9.org/showthread.ph...si#post1711065



EDIT: Colors are from Avisynth provided colors_rgb.avsi in plugins folder.

Quote:
Originally Posted by StainlessS View Post
The diligent amongst you might notice two copies of "color_palegoldenrod" in the mp4,
this is a duplicate in colors_rgb.avsi as installed by v2.6RC1, you might like to delete duplicate from your copy,
reported in RC1 devs thread.
The duplicate color in colors_rgb_avsi should have been fixed in v2.6, but not in above GIF.

EDIT: And see here:- http://avisynth.nl/index.php/Color_presets
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 27th October 2016 at 23:49.
StainlessS is offline  
Closed Thread

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 03:07.


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