Avisynth+

[yup]

Originally Posted by Groucho2004

Define "after install". After installing r2022 or after copying over the r2069 files? Which version(s) do you want to install? What OS?

After install Your package r2022, Windows 10 64.

[Groucho2004]

Originally Posted by yup

After install Your package r2022, Windows 10 64.

Did you install the latest runtimes (14.0.23506)?

[yup]

Originally Posted by Groucho2004

Did you install the latest runtimes (14.0.23506)?

No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.

[Groucho2004]

Originally Posted by yup

No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.

"14.0.24210" is indeed the latest, my mistake. As for your problem, I have no idea, try cleaning up the auto-load directory so you have only the DLLs installed with AVS+.

[ultim]

I fixed a false positive in the diagnostic messages and pulled pinterf's latest high bit-depth work in r2076.

[burfadel]

14.0.24210 is known to be buggy though in some scenarios.

[ultim]

Originally Posted by yup

No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.

just did a clean install of avs+ using official installer from website, then replaced it with newest build from avs-plus.net/builds. works as expected.

i doubt it is the runtimes, probably some plugin. if you have a plugin from jpsdr, mysteryx or chikuzen, you will need a recent build of them to not crash. also make sure when you copy a new build of avs+, you also copy the plugin dlls that come with it into the correct folders.

[pinterf]

Today's Avisynth Plus news:

• Blur and Sharpen ported to 16 bit/float.

P.S. is there anybody who runs avisynth plus on a non SSE2 capable processor?

For me the 32 bit version with compile option SSE2 instead of SSE yielded almost 10% gain. Maybe because this script uses high bitdepth routines that are mostly in C?

lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
Spline64Resize(400,340)
orig = last
x8=orig.Blur(1.0,1.5).Info()
x8d=orig.Sharpen(1.0, 1.0).Info()
x16=orig.ConvertTo16bit().Blur(1.0, 1.0).Info()
x16d=orig.ConvertTo16bit().Sharpen(1.0, 1.0).Info()
x32=orig.ConvertToFloat().Blur(1.0, 1.0).Info()
x32d=orig.ConvertToFloat().Sharpen(1.0, 1.0).Info()
StackHorizontal(\
StackVertical(x8.ConvertTo8bit(),x16.ConvertTo8bit(),x32.ConvertTo8bit()),\
StackVertical(x8d.ConvertTo8bit(),x16d.ConvertTo8bit(),x32d.ConvertTo8bit())\
)
ConvertTo8bit()

[TheFluff]

Originally Posted by pinterf

P.S. is there anybody who runs avisynth plus on a non SSE2 capable processor?

I dunno about avs+ specifically but if there's anywhere you can find people who actually own functioning non-SSE2 CPU's in 2016, it's doom9. This guy turned up in the FFMS2 thread a few months ago, for example.

Still, SSE2 was introduced fifteen years ago so I think it's pretty reasonable to expect people who do CPU-intensive tasks like video encoding to have it. The only CPU that was even remotely popular that didn't have SSE2 after 2001 was the Athlon XP, and those things really aren't too common anymore.

[tedkunich]

Originally Posted by TheFluff

snip...The only CPU that was even remotely popular that didn't have SSE2 after 2001 was the Athlon XP, and those things really aren't too common anymore.

I retired mine about 5 years ago....

[ryrynz]

Originally Posted by ultim

Hopefuly I will also find why Prefetch(1) is the same as Prefetch(0) and fix it.

Was this ever resolved?

[MysteryX]

Is there some documentation about the new 16-bit functions? What functions are supported, how to convert between formats, etc.

For example, how can I convert to 16-bit and then convert from Rec601 to Rec709, if that's supported?

Also several of the existing plugins will have to support 16-bit input and output in addition to lsb_in_out; shouldn't be hard to do when they already handle 16-bit but it just needs to be done.

[pinterf]

At the present state only YUV color spaces have high bit-depth support: 16 bit and float (32 bit).

In the last five weeks from the project start, we had no time for RGB48/64 and 10-12-14 bit support, but they will be done of course soon. At least defining the constants, names, and the basic conversions to and from. In order to let the filter authors play with them also.

Color space naming conventions:
8 bit:

• Y8, YV12, YV16, YV24

16 bit:

• Y16, YUV420P16, YUV422P16, YUV444P16

float:

• Y32, YUV420PS, YUV422PS, YUV444PS

Bit-depth conversions (no dithering, no range conversion, etc...)

• ConvertTo8bit()
• ConvertTo16bit()
• ConvertToFloat()

Color-space conversions within same bit-depths (also works for 8 bit)

• ConvertToY()
• ConvertToYUV420()
• ConvertToYUV422()
• ConvertToYUV444()

Their parameters are the same as at their 8 bit counterparts:

• ConvertToY8(), ConvertToYV12(), ConvertToYV16(), ConvertToYV24()

Compatibility conversions for existing 16 bit hacked formats:

• ConvertFromStacked()
• ConvertToStacked()
• ConvertFromDoubleWidth()
• ConvertToDoubleWidth()

Plane swap

• UToY(), VToY()
• UToY8(), VToY8()
• YToUV()

The UToY8 and VToY8 naming is still illogical at the moment, because it makes Y8 Y16 or Y32 clip depending on the source.
But with removing the '8' specifier from the name, it would collide with UToY and VToY

Internal filters.
I made a list from here where I saw Y8 or YUV support.

See the functions below that have NO 16bit/float port yet.

Color conversion and adjustment filters

• ColorYUV
• Invert
• Levels
• Limiter
• MergeARGB / MergeRGB

Overlay and Mask filters

• MaskHS
• Overlay
• Subtract

Geometric deformation filters

• SkewRows (do we need it? affects only Y8?)

Debug filters

• ColorBars / ColorBarsHD
• Compare
• Histogram

Output
See Chikuzen's avs2pipe mod

I hope I have not missed important points, so please test, comment, (ask for features), and as ultim had said, treat it as a beta.

And remember that introducing high bit-depth into Avisynth+ was a must have but is not enough. Writing supporting filters and porting the old ones is very important. If you are not a programmer you can still force the otherwise boring authors

[vcmohan]

In this newer version of AVS+ how can a plugin know the bits per channel (apart from the unweildy names)? can any of the following calls

int     (VideoInfo::*BitsPerPixel)() const;
int     (VideoInfo::*BytesPerChannelSample)() const;

used to get info? Can one ask if it is planar and then bits pr channel? Presume that like vapoursynth 10,12,14 bit depth channels will be expanded to 16 bit and presented to the plugin to process.

[pinterf]

Originally Posted by vcmohan

In this newer version of AVS+ how can a plugin know the bits per channel (apart from the unweildy names)? can any of the following calls

int     (VideoInfo::*BitsPerPixel)() const;
int     (VideoInfo::*BytesPerChannelSample)() const;

used to get info? Can one ask if it is planar and then bits pr channel? Presume that like vapoursynth 10,12,14 bit depth channels will be expanded to 16 bit and presented to the plugin to process.

VideoInfo has a new function: ComponentSize() which tells you how many bytes needed for a pixel sample.
1, 2 and 4 means: byte, uint16_t, and float pixel type, respectively.

The 10-12-14 bit versions are not implemented yet, but the ComponentSize() function for such colorspaces will return 2 bytes in the future.
Avisynth internal filters also use this function for deciding whether 8 bit / 16 bit / float processing should be done.
Alternatively (for YUV only) BytesFromPixels(1) will tell you the same.

Warning: using these functions of course will fail on classic avisynth or earlier avs+ builds.

So there will be a yet-to-be-named function for requesting the internal bit depth format of the specific color space.

What you wrote:
BitsPerPixel has other purposes, and cannot be used in a globally logical way, e.g. it returns 32 for RGB32, 24 for RGB24, etc.
BytesPerChannelSample is for audio.

One can of course make magic directly from the bitmap of pixel_type property, currently its the layout is under revision (but will remain compatible with the old things)

[ultim]

Originally Posted by pinterf

VideoInfo has a new function: ComponentSize() which tells you how many bytes needed for a pixel sample.
1, 2 and 4 means: byte, uint16_t, and float pixel type, respectively.

The 10-12-14 bit versions are not implemented yet, but the ComponentSize() function for such colorspaces will return 2 bytes in the future.
Avisynth internal filters also use this function for deciding whether 8 bit / 16 bit / float processing should be done.
Alternatively (for YUV only) BytesFromPixels(1) will tell you the same.

Warning: using these functions of course will fail on classic avisynth or earlier avs+ builds.

So there will be a yet-to-be-named function for requesting the internal bit depth format of the specific color space.

What you wrote:
BitsPerPixel has other purposes, and cannot be used in a globally logical way, e.g. it returns 32 for RGB32, 24 for RGB24, etc.
BytesPerChannelSample is for audio.

One can of course make magic directly from the bitmap of pixel_type property, currently its the layout is under revision (but will remain compatible with the old things)

When 10/12/14 get added, will BitsPerPixel() return the number of useful bits, or the number of bits used for storage? So for example, for 10bit video, should BitsPerPixel() return 10*NumComponents(), or 8*ComponentSize()*NumComponents() ?

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.

[ultim]

Originally Posted by ryrynz

Was this ever resolved?

Not yet. I'm planning to have a sweep at the thread pools and it might turn something up, but the issue you mentioned was never important enough or had any direct consequences for the user for me to have look at.

[Chikuzen]

Originally Posted by ultim

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.

10bit and 14bit will have the great difference for many filters which using SIMD.

[pinterf]

Originally Posted by ultim

When 10/12/14 get added, will BitsPerPixel() return the number of useful bits, or the number of bits used for storage? So for example, for 10bit video, should BitsPerPixel() return 10*NumComponents(), or 8*ComponentSize()*NumComponents() ?

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.

In the core BitsPerPixel is used mostly in the RGB part, for calculating the byte size of a whole interleaved pixel (24>>8 = 3 bytes, 32>>8 = 4 bytes). I don't know how external plugins use it.
The 10-12-14 bit is mostly important for export/import. Although many basic external filters still do not support even the basic 8 bit color spaces, have issues at 64 bit environment, making them work at 16 bits is a dream. But let's don't cut the possibility if a filter is modern and can distinguish between 10-12-14 bits. Before we met, I had just looked at KNLMeansCL, and it used this bit count properly at its VapourSynth part.

Chikuzen, can you tell examples?
What I guess, smaller bit size can really have advantages, for 10 bits xy luts can work. At 14 bits we can use signed 16 bits in SIMD, unsigned 16 bit data sometimes requires SSE 4.2 or workarounds at SSE2. These are not frequent cases though, but when someone explicitely prepares his plugin for these bitdepth, he may really need them.

[tormento]

Originally Posted by ultim

I fixed a false positive in the diagnostic messages and pulled pinterf's latest high bit-depth work in r2076.

mmm... video decoder errors with DGNV.

Can somebody please upload the previous version?

EDIT: confirmed... with r2043 (the only other in mirror) it works. Please upload r2069 back