AviSynth+ thread Vol.2

[VoodooFX]

One script had me scratching my head for half an hour because it was producing unexpected, weird effects, all due to a missing dot...

Why this doesn't produce error, it ignores everything on the line after missing dot and outputs RGB:
BlankClip()
m=BlankClip().trim(0,-1)ConvertToY8
m

This produce error:
m=BlankClip().trim(0,-1)ConvertToY8
m

This outputs Y8:
BlankClip().trim(0,-1)ConvertToY8

[wonkey_monkey]

IIRC, if the parser runs into something that otherwise be unexpected, it assumes it's the start of a new statement.

So your first code is equivalent to:

BlankClip() # implicit last
m=BlankClip().trim(0,-1)
ConvertToY8 # this converts the implicit last cliip
m

The second is equivalent to:

m=BlankClip().trim(0,-1)
ConvertToY8 # no implicit last; error
m

And the third is equivalent to:

BlankClip().trim(0,-1)
ConvertToY8

It also means stuff like the following is valid:

a=1b=2
foo=3bar=10foo
a=1a2a

[FranceBB]

Happy 25th birthday, Avisynth! :D
(May 19th 2000 - May 19th 2025)

https://i.imgur.com/Eky4zyc.jpeg

[Gavino]

IIRC, if the parser runs into something that otherwise be unexpected, it assumes it's the start of a new statement.
That's correct.
To clarify, 'unexpected' here means a character that cannot legally continue the current statement.
It also means stuff like the following is valid:
a=1b=2
foo=3bar=10foo
a=1a2a
That produces the error 'I don't know what "a2a" means'.

[Jamaika]

Has avisynth been permanently removed from ffmpeg?
https://github.com/FFmpeg/FFmpeg/commit/4f7bc62c6644420557d02b3de65b75147eac79ec

[ryrynz]

How is "Move avisynth and dvdvideo under external libraries group" removal exactly?

[Jamaika]

Hmm... Only I was adding statically to ffmpeg and was counting on plugin modifications in this twenty-fifth anniversary. Now it looks like two separate projects.

[LigH]

In my scope you are the only person trying to link AviSynth statically into ffmpeg...

[Jamaika]

In my scope you are the only person trying to link AviSynth statically into ffmpeg...
I am surprised that the l-smash add-on for avisynth is static with ffmpeg
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases/


https://github.com/HomeOfAviSynthPlusEvolution/FFmpeg/tree/c54f59fbc13a57c168e5b7389976b7a4ec60b850
Modified ffmpeg? Probably yes.

[DTL]

Some sad information for Personal Computer users with current AVS+ filters and frame cache design. I asked a question at stackoverflow https://stackoverflow.com/questions/79633556/ the answer is: We still can not use all 32/64bit address space for software design if we need high performance computing. The only usable with best performance is address space of the size of CPU cache. It is only about 10 MBs of 10ths of MBs typically on top consumer CPUs (except Xeon MAX with HBM RAM onboard).

As answers shows - there still no standard way for software to skip data writing to RAM after generation inside the CPU core. (maybe some hacks with cache coherency control still exist ?) . Even if it is temporal data exchange in between AVS filters and no more consumer of this data exists in the future. It is the use case of a simple filter chain (without splitting of output to several consuming filters).

This causes the main performance impact: Each frame in AVS cache has its own virtual address space range. This means total address space used by AVS is much larger than CPU cache size if we process SD frames totally cacheable even with several threads running. If we only have 1 source buffer and 1 dest buffer to process in between all filters in a chain (of unlimited length).

But if each frame buffer of each intermediate frame in AVS+ cache has its own buffer and number of frames is Nxthreads_number for each connection between filters - this causes the total amount of virtual address space used to be much larger than the CPU cache size.

And with cycling processing of all frame buffers CPU produces data for each buffer and stores it first in some levels of fast cache. But production rate may be much higher than the cachelines storage rate to RAM via slow bus. This causes a quick exhausting of free cache lines and total CPU stall doing nothing and waiting for old frames to be downloaded from cache to RAM. CPUs do not have the right to overwrite still not saved to RAM cache lines with different virtual address data. This will cause data loss for later reading from these addresses.

The only legal way to increase performance in such host design - to send overwrite instructions to the same virtual addresses. This will legally update data in cache at the full write cache performance and do not cause CPU stall of the execution. The rest of data may be slowly downloaded into slow host RAM if time slots on the host RAM bus are present. Typically it is temporal data in between filters and no need for anyone more so can be skipped completely after the sink filter reads it all from cache.

This means general ideas to AVS filters and core design:
1. Use in-place transform filter design if possible (non-resizing and non-spatial non-temporal filters like Levels/Tweak/ColorYUV).
2. Stop using many frames cache (make an option for script writers ?) in between chained filters if possible and reuse a low number of allocated buffers (better only 2 buffers - source and dest and reassign at the next filter call for 1 input and 1 output filter or send pointer to trans in place filter). Need to test in debugger what happens if we set Prefetch(N,1) or even Prefetch(N,0) and make a script with a sequence of transform in place filters.
3. Make transform in place copies of filters where possible and instruct the filter manager of AVS core to use these filters with a single virtual address space allocated buffer in all filter chain while possible.

Also if there will be no usable (hacky) solution it looks we need to send request to intel and AMD for new instruction extension at least for SIMD like _mXX_loadu_invd(addr) of simply load data from addr and invalidate cache line with this addr. Though it is easy to do only for cache line aligned loads and if load full cache line only (so usable for AVX512 with 64bytes load and from L1D only with 64 byte cache line size).

I still hope some general solution exists like high-level operation of free(addr) or free_invd(addr) with also invalidating all cachelines containing addresses from memory-allocated area (with page-size granularity of 4KB). Though it may be natural if user of high-level language calls free() all data is now can be skipped and every free() call may also invalidate cache and save CPU from store not yet saved data from that memory region virtual addresses. This performance issue is really OS-design level with memory services to applications. It is strange if there is no solution yet.

[FranceBB]

Can I ask which version of SoundTouch was linked to TimeStretch when it was compiled?
SoundTouch version 2.4.0 was released on April 6th 2025 while Avisynth 3.7.5 was released on Apr 21st 2025, so I expected it to be using that one, however I'm getting some weird results, so I'm worried that version 2.3.3 from March 29th 2024 might have been used instead. It would make sense, given that Avisynth 3.7.5 is just a "tiny" update from Avisynth 3.7.4 which was released on Mar 24th 2025, so before the SoundTouch 2.4.0 official release.
If that's the case, if someone has a bit of time and everything setup already, can you recompile TimeStretch against SoundTouch 2.4.0? Otherwise I'll try to do it when I'm back later next week.

[qyot27]

git-9ef8458d85, HEAD as of 2025-02-27 15:25:09

The only commit after that which makes a difference to current HEAD is the one that was merged literally one week ago, on the 16th.

[pinterf]

Happy 25th birthday, Avisynth! :D
(May 19th 2000 - May 19th 2025)

In case we're still around to read the next round of birthday greetings (50th), we should definitely plan a BBQ somewhere halfway between our homes. Good wine will surely help the celebration—while my grandchildren will probably have to help me get to the party spot. :)

[hello_hello]

Is it by design that when you specify a chroma placement for a resizer and it differs from the chroma location in frame properties, the frame property isn't updated to reflect the chroma placement used for resizing? It's the same for ResampleMT when using the placement argument. For example:

# Frame property chroma = "left"
Spline36Resize(960,540, placement="center")
# Frame property chroma = "left"

Also, I just want to confirm...
As it's not possible to change the chroma location with the Avisynth resizers, is this a legit way to do it (for a YV12 source)?

ConvertToYV12(ChromaInPlacement="top_left", ChromaOutPlacement="center")

[pinterf]

Is it by design that when you specify a chroma placement for a resizer and it differs from the chroma location in frame properties, the frame property isn't updated to reflect the chroma placement used for resizing? It's the same for ResampleMT when using the placement argument.
Yes, by design.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

Section:
placement

[v0lt]

I did some tests of Unicode string support.
I use Avisynth+ 3.7.5 and save scripts in UTF-8.

FFVideoSource("Утка_Πάπια_오리.mkv")
It works!
FFVideoSource("Утка_Πάπια_오리.mkv")
Subtitle("Утка_Πάπια_오리")
The text is not displayed correctly.
FFVideoSource("Утка_Πάπια_오리.mkv")
Subtitle("Утка_Πάπια_오리", utf8=true)
Strange, but the Subtitle function, unlike FFVideoSource, requires additional specification of UTF-8 encoding.
MessageClip("Утка_Πάπια_오리")
The text is not displayed correctly. And it seems there is no way to use MessageClip with Unicode strings.

1. Is it possible to make any string parameters interpreted as UTF-8 strings? So that users don't have to write "utf8=true" for UTF-8 scripts.

2. Will the MessageClip function support UTF-8 in the future?

[qyot27]

AviSynth+ (and classic AviSynth, for that matter) are dependent on the system codepage/locale. Some plugins (and with utf8=true, internal functions) allow for converting between UTF8 and other string formats, but it's not automatic. Largely, it's handled outside of AviSynth+:

A) Set the Windows codepage to UTF-8. By far the easiest way to accomplish it, but some users get scared away from the 'Beta' language that the option uses in the config dialog. I can't remember if Win11 changed this to more neutral wording or even enables it by default now.

B) Set the client application to UTF-8 using that app manifest thing, whereby AviSynth(+) should probably inherit the changed locale. AFAIK, libraries can't have those manifests attached to them, only application binaries can. This is not something I've really tested, since I just went with A) about 6 or 7 years ago on Windows 10 and never looked back.


Just relying on the system setting is also why it can happily ingest/display UTF8 characters on all the non-Windows OSes, which all do default to UTF-8 and have for like, the last 20 years or so. Something to point out, though, is that you need to use a font that contains the Unicode characters as well.

On Windows, MessageClip uses Arial, which should then select Arial Unicode and display them (when talking about the system/application being set on UTF8, I mean). Everywhere else, MessageClip defaults to Terminus, which unfortunately does not contain all of the Unicode characters (from the example, it contains just Cyrillic and Greek, but not Hangul - and probably not the other CJK sets either); Subtitle/Text can load external fonts, so you could see it work if you give it GNU Unifont (https://www.unifoundry.com/unifont/index.html), for example. That one has all the glyphs, and it displays correctly for Text(), just with much wider spacing. MessageClip should probably have the font_filename option added to it as well.

This is one reason why there needs to be a Freetype2 backend, as that would allow for using Fontconfig to select TrueType and OpenType fonts that have the full range of glyphs and not be limited to bitmapped fonts with specific sizes.


Local tests below

MessageClip() per example:
https://i.imgur.com/CiOAkwq.png

Text() and Version(), with Text being provided an external BDF font file to provide the correct glyphs:
https://i.imgur.com/XSFuCBd.png

Ditto, but in VirtualDub2:
https://i.imgur.com/LXo6cff.png

[StvG]

Some plugins (and with utf8=true, internal functions) allow for converting between UTF8 and other string formats, but it's not automatic. Largely, it's handled outside of AviSynth+:

But some of the plugins are doing it automatically (e.g., the unofficial ffms2).

[pinterf]

@qyot27

1.) "if you give it GNU Unifont, for example. That one has all the glyphs, and it displays correctly for Text(), just with much wider spacing. MessageClip should probably have the font_filename option added to it as well."
Regarding the wider spacing: I suppose that BDF rendering rule implemention is missing something. I did not implement all features.

EDIT: (reason for visual gap found)
Regarding the wider spacing in Unifont, this is due to how FONTBOUNDINGBOX is interpreted during rendering. In Unifont's BDF header, FONTBOUNDINGBOX is set to 16 pixels wide. This causes all glyphs, regardless of their actual width, to be rendered with 16 pixel spacing in Avisynth's Text() function, resulting in visible gaps for narrower characters. While Unifont is conceptually monospaced, it technically includes variable-width glyphs. Many Latin characters have DWIDTH 8, but others (like U+007F or CJK characters) use DWIDTH 16. Thus the global FONTBOUNDINGBOX must be 16 pixels wide.

In a fully BDF-compliant renderer, the per-character DWIDTH and BBX values can override the global bounding box for spacing and alignment. However, Avisynth's BDF renderer does not implement this override behavior. It uses the global FONTBOUNDINGBOX width as a constant for the whole rendered text line.

So far I’ve only encountered BDF fonts where FONTBOUNDINGBOX, DWIDTH, and BBX were consistent across all glyphs. Unifont breaks this assumption, which in turn revealed a limitation in my implementation.

2.) The (C) (Copyright) character is missing on your system, why?

[qyot27]

2.) The (C) (Copyright) character is missing on your system, why?
That's the one side-effect I've encountered in the AviSynth+ core of switching the system codepage to UTF-8. On Ubuntu it displays the Copyright symbol just fine, but because Windows has to take a far more convoluted path to get there, that's probably where the issue lies.

[pinterf]

That's the one side-effect I've encountered in the AviSynth+ core of switching the system codepage to UTF-8. On Ubuntu it displays the Copyright symbol just fine, but because Windows has to take a far more convoluted path to get there, that's probably where the issue lies.
It's because on non-Posix builds this string is used:
#define AVS_COPYRIGHT "\n\xA9 2000-2015 Ben Rudiak-Gould, et al.\nhttp://avisynth.nl\n\xA9 2013-2025 AviSynth+ Project"

Which contains (C) symbol as xA9 but it's an invalid code sequence in UTF8 and is has problems on Hebrew or Arabic code pages as well. I'm gonna figure it out.

EDIT: and we returned to the problematic non-utf8 aware MessageClip

return Create_MessageClip(
#ifdef AVS_POSIX
AVS_FULLVERSION AVS_DEVELOPMENT_BUILD AVS_DEVELOPMENT_BUILD_GIT AVS_COPYRIGHT_UTF8
#else
AVS_FULLVERSION AVS_DEVELOPMENT_BUILD AVS_DEVELOPMENT_BUILD_GIT AVS_COPYRIGHT
#endif
, w, h, i_pixel_type, shrink, textcolor, halocolor, bgcolor, fps_numerator, fps_denominator, num_frames, env);

EDIT2:
Which in turn is using the non-changeable env->ApplyMessage, which has no utf8 parameter, and cannot even have one, without breaking the IScriptInterface.

EDIT3:
Version (C) symbol now works when Windows codepage is utf8, MessageClip utf8 bool parameter added; env->ApplyMessageEx added as a new v12 interface function. Now it needs a code cleanup, but before it I'd like to implement the Unifont 8-16 pixel fixed-variable :) width feature.

[StainlessS]

All of that there weird UTF8, Unicode, code pages etc, terrifies and fills me with despair.
I blame foreigners, hangin's too good for them.
Everybody should use English, if its good enough for God, it should be good enough for them
:)

[pinterf]

All of that there weird UTF8, Unicode, code pages etc, terrifies and fills me with despair.
I blame foreigners, hangin's too good for them.
Everybody should use English, if its good enough for God, it should be good enough for them
:)
You are right, but that's still way too modern. Let's ditch traditional English, and go full retro, I propose cuneiform on clay tablets, no more encoding issues, more fun. No exotic keyboard layouts, just have a good stylus. proper C++ support is questionable though, we'd have to step back a bit. :)

[jpsdr]

@pinterf
Is the AVX2 resample code in the current branch ok, or are you still working on it ?
Just to avoid to implement the new code in my ResampleMT and re-doing things later if it's for changing later.
No big deal, i am absolutely not in hurry.

[jpsdr]

@pinterf
I have a different result with my pure "C" 8bits and yours for the vertical part, and i don't see what's wrong...:(
Is it possible that there is something wrong in your pure "C" vertical ? :confused:

[DTL]

In June 2025 there were another big update on resampling engines (SIMD) and possible new resample function (H+V for each plane with single temp buf) for planar formats. But to the end of June there were no news from pinterf and what of the suggested updates will be transfered to main AVS+ branch is unknown. You can see latest news and commits about resamplers at this pull request - https://github.com/AviSynth/AviSynthPlus/pull/440 . Though some may be treated as performance tech demos and may be not safe for end of line and even end of buffer memory access.
For AVX512 many resizers somehow done too (at least all verticals ?) and only left 8 and 16bit H-resizers. Also you can see some performance optimization updates for AVX2 (mostly float32 resizers).

Also main new design idea on H-resizers (transposition of H-resize task to V and process with SIMD-friendly V-fma) cause possibility to design several more faster processing functions but limited to the filter support size (kernel size). This may make performance benefit for small-kernel resizers like Bilinear/Bicubic(?)/some small support Gauss and may be some others (like sinc-based with taps=2) but solution is not one for all H-resize function as exist in 3.7.5 AVS+ and before.
Also different SIMD architectures supports different size load and transposition with better performance (AVX512 is best as expected). This makes resampling engine more complex (and more complex to maintain) and may be not accepted by current very limited amount of developers resources. Though some more simple optimizations may be included.

[wonkey_monkey]

The examples for env->invoke with multiple parameters are all of this form:

AVSValue up_args[3] = { child, 384, 288 };
PClip resized = env->Invoke(upsizerString, AVSValue(up_args,3)).AsClip(); // up_args is AVSValue[1], but is effectively also AVSValue*(?)


But what if I don't have a fixed number of parameters? I'm trying to do an equivalent of this:

std::vector<AVSValue> up_args;
up_args.push_back(clip);
up_args.push_back(384);
up_args.push_back(288);
PClip resized = env->Invoke(upsizerString, AVSValue(up_args.data(), up_args.size())).AsClip(); // up_args.data() is AVSValue*


But it throws an exception about invalid arguments.

Is there any way to do what I'm trying to do? Or do I have to use a fixed size array allocated on the stack?

------------------

Also, I'm trying to catch any exceptions from call to invoke. But I can't work out what type is thrown. I can catch generally with (...) but AvisynthError and std::exception don't work.

[jpsdr]

@pinterf
Hi.

Now that i have updated to the new SSE code, i have a crash i didnt' have before.
I happens in resize_v_sse2_planar on the following line:

if (notMod2)
{ // do last odd row
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff[sizeMod2])); // 0|co|0|co|0|co|0|co

[DTL]

Current AVS+ repository lists for void resize_v_sse2_planar() https://github.com/AviSynth/AviSynthPlus/blob/91fc40819f63d5d6194507114ea5ff430481104e/avs_core/filters/intel/resample_sse.cpp#L231C1-L231C27

https://github.com/AviSynth/AviSynthPlus/blob/91fc40819f63d5d6194507114ea5ff430481104e/avs_core/filters/intel/resample_sse.cpp#L296
// Process the last odd row if needed
if (notMod2) {
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff + i)); // 0|co|0|co|0|co|0|co

May you got wrong text somewhere ?

Also you change function somehow - i counter used in loop and as pointer to the last index:
int i = 0;
for (; i < kernel_size_mod2; i += 2) {}
- after loop exit i+=2 always and
if (notMod2) {
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff + i)); // 0|co|0|co|0|co|0|co - reads last coef indexed by i from current_coef array (vector)

In your text you use
if (notMod2)
{ // do last odd row
// Load a single coefficients as a single packed value and broadcast
__m128i coeff = _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff[sizeMod2])); // 0|co|0|co|0|co|0|co

sizeMod2 may be not equal in all cases to i+=2 in the AVS+ current core version ?

[jpsdr]

SetMaxCPU("SSE2")
ColorBars(720,480).KillAudio()
Spline36ResizeMT(1280,720,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)
DeSpline36ResizeMT(720,480,src_left=17.2,src_width=680,src_top=-8.7,src_height=440,accuracy=0,order=0)


The error message is the typical @00000000 cryptic one a unaligned acces can generate.

Edit:
Script edited...

[DTL]

_mm_set1_epi16() is a macro for C-compiler - https://www.laruence.com/sse/#text=_mm_set1_epi16&expand=4938 . It is up to compiler how to use aligned-safe read instructions and it is expected to work without alignment requirements.

[jpsdr]

It is up to compiler...
Even if i understand perfectly all the benefits of intrinsic, it's one of the reasons i'm not using them and still using ASM.

[DTL]

Have you check disassembly at the crash point ? Is it memory read instruction ?

Can you try non-modified function from AVS+ https://github.com/AviSynth/AviSynthPlus/blob/91fc40819f63d5d6194507114ea5ff430481104e/avs_core/filters/intel/resample_sse.cpp#L231C1-L231C27 ? Is it crash too ?

Script

SetMaxCPU("SSE2")
ColorBars(720,480).KillAudio()
Spline36Resize(1280,720,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)
Spline36Resize(720,480,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)


Work with AVS 3.7.5 without crash. It is better to move discussion to ResampleMT thread ?

[jpsdr]

I can't test the not-modified as it doesn't fit with my code, but... I didn't check enough, i forgot this is a line i've modified, so maybe indeed it's my fault.
I will check better.

[jpsdr]

I don't see any issue with the modified version.
I don't know what function to use, and how playing with the parameters will trig the "notmod2" code path with standard functions... :(

Edit:
I see my stupid noob level mistake...! :angry:
current_coeff[sizeMod2] return the value in the tab, when i need the address of ptr, so current_coeff+sizeMod2.
I've been tricked by the mmx version just up... :p
Sorry, it was indeed misplaced...

[DTL]

It looks you still have same issue in more places -
https://github.com/jpsdr/ResampleMT/blob/7a14f3b51534d2f67fa96c978f932b602c038e6b/ResampleMT/resample_sse.cpp#L173
https://github.com/jpsdr/ResampleMT/blob/7a14f3b51534d2f67fa96c978f932b602c038e6b/ResampleMT/resample_sse.cpp#L638

" one of the reasons i'm not using them and still using ASM."

Intrinsics allows to do universal x86 and x64 compilable program text and also a good compiler can do best job on registers usage and instructions placement for some known hardware architectures. Also programs can be compiled for future CPUs by future compilers without redesign.

The very sad thing happened after x86 programmer's used x86 ASM inlines in C AVS plugins text and after the era of x86 CPUs ended and also lots of freeware programmers left. The residuals of users left with unusable program text for new x64 CPUs. And the only possible way is to wait when (if ever) the AI compilers can redesign such plugins for x64 compilable program text. Many users and programmers in the beginning of 200x hoped the civilization would not die too fast and we always will have lots of free programmers doing program text redesign for any current CPU cores. But things went quickly in a sad way and we lost about all free programmers only about +20 years later.

Usage of intrinsics may help to last usable program texts a bit more I hope.

[jpsdr]

These 2 lines are good, _mm_set1_epi16 request directly the value to be broadcasted, so in the case of these 2 lines it's good, and it was like this in the original code.
Where i made the mistake, it was _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff[sizeMod2])) it needs the pointer, so the proper in that case is _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff+sizeMod2)) because current_coeff[sizeMod2] is the value, where current_coeff+sizeMod2 is the address of the value.
I think _mm_set1_epi16(current_coeff[sizeMod2]) would probably work, like on the others two lines you linked as current_coeff is a const short*. I don't understand why it's like this here, and differently on the other places, but i left it the way it is.

[DTL]

" I don't understand why it's like this here, and differently on the other places, but i left it the way it is."

The main resampling engine function definition is equal for all supported data types (8,9-16 and 32 bits)
void resizer_*(BYTE* dst8, const BYTE* src8, int dst_pitch, int src_pitch, ResamplingProgram* program, int width, int height, int bits_per_pixel);

and coeff buffer also have different types (integers and floats). So programmers need to convert single incoming pointers to function arguments into different pointer types inside each function implementation. So many functions were designed differently by different programmers.

With about 1/4 century of development AVS collects many different sets of resampling functions from different programmers and it is hard to make them all in the same style with low programmers resources of today.
Each set of resampling functions for each SIMD family from MMX to AVX512 contains at least:
1. 3 data types H-resamplers
2. 3 data types V-resamplers

The V-resamplers are typically simple and universal. Single function supports all kernel size and all resize ratios and can not be more optimized for performance.
The H-resamples are typically more complex (and slower) and with more and more large SIMD family it is possible to make some higher performance H-resamplers for some limited combinations of kernel size and resize ratios. This cause number of possible H-resamplers for big SIMD families like AVX2 and AVX512 even much more in count.

[jpsdr]

No, what i meant is why specificaly here there is in original code _mm_set1_epi16(*reinterpret_cast<const short*>(current_coeff+i)) when there is on other places _mm_set1_epi16(current_coeff[i]) (still in original code) with current_coeff being const short* always.

[vcmohan]

Since a couple of days whenever I try to access avisynth development or usage subforums, getting a message that it is forbidden. However I am able to view vaporsynth forum. Has anything changed for this ?

[StvG]

Since a couple of days whenever I try to access avisynth development or usage subforums, getting a message that it is forbidden. However I am able to view vaporsynth forum. Has anything changed for this ?

I have same problem. Refreshing few times the main forum page (https://forum.doom9.org) fix it.

[vcmohan]

thanks

[LigH]

This may happen when an element in the user account related cookie gets misinterpreted. Sometimes due to a board software update. Also quite regularly when Daylight Saving time toggles.

Clearing the cookies of this domain and logging in anew helps for a longer period of time.

[StvG]

This may happen when an element in the user account related cookie gets misinterpreted. Sometimes due to a board software update. Also quite regularly when Daylight Saving time toggles.

Clearing the cookies of this domain and logging in anew helps for a longer period of time.

It happens when browsing the forum without login.
Here at browser exit everything is cleared. Opening it and navigating to the forum, and accessing the Avisynth Usage and/or Avisynth Development subforums for the very first time (no cookies saved) - 403 Forbidden access.
I think there was forum update some time ago - now there is blue icon (d9) next to the page title. From this moment I started have this problem.

[jpsdr]

There is something i'm not able to find out... Where in resample pixel_offset is ajusted to be sure src+pixel_offset[x] is always aligned... (for horizontal resampling) :confused:

Edit:
I suddenly had a hunch...
Then checked the AVX2 code.... OMFG...!!! :eek:
If i understand properly the intrinsic the src read are unaligned...
I understand now why i can't find where the pixel_offset is adjusted aligned...

[manolito]

Please forgive me my ignorance, I have not followed this thread for a long time (due to a stroke about 4 years ago).

I am still using AVS+ 3.5.1, mainly because I had other things to do, and it "just worked". Now I figured I should probably upgrade to a current version of AVS+, and I did get some problems...

Updating to the last stable version worked fine, the installer did a good job, and at first it looked like there were no problems. But this changed when I executed a script which needed FineSharp by Didée. It crashed at this script line:
shrpD = mt_lutxy(c,b,"x y - abs "+LSTR+" / 1 "+PSTR+" / ^ "+SSTR+" * x y - x y - abs 0.001 + / * x y - 2 ^ x y - 2 ^ "+LDMP+" + / * 128 +")


I checked earlier versions of AVS+, and the latest working version is v 3.7.0. I do not really understand the code in this line, so there is no chance I could fix this myself. What are my options?

1. Ask Didée (not too smart, this code worked before, it should be fixed in AVS+)

2. Ask PinterF to fix it in AVS+

3. Do not use current AVS+ versions (possible, but not really what I want)

4. Use FFmpeg instead. Their SmartBlur filter comes pretty close to FineSharp.
smartblur=1.5:-0.35:-3.5:0.65:0.25:2.0



I would be really interested to know if I am the only one having this problem with FineSharp. Could it be my old ThinkPad with its CORE i5 CPU?


Any ideas?


Cheers
manolito

[Boulder]

Could it be my old ThinkPad with its CORE i5 CPU?


You could try using SetMaxCPU to see if there are any instruction set conflicts for some reason. However, I highly doubt that is the case.

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_internal_functions_global_options.html#setmaxcpu

[wonkey_monkey]

It worked okay for me (3.7.4 x64 on an i5). Is your MaskTools up to date? What are the properties (resolution, colourspace) of the source?

[DTL]

There is something i'm not able to find out... Where in resample pixel_offset is ajusted to be sure src+pixel_offset[x] is always aligned... (for horizontal resampling)

pixel_offset[] can not be aligned because it greatly depends on the resample ratio and source samples positions for current output sample convolution and resample ratio can be any real number. So it always (in most cases) need unaligned read from memory to SIMD. Some aligned positions are possible in the resampling program for a row but checking logic overhead may be much more in comparison with usage of unaligned loads always.

One possible way to use aligned reads and non-aligned pixel_offset[] sampling from the read part of a row is use aligned load of part of a row into SIMD register and use some permutation or shifting or any other existing data shuffling instructions inside SIMD register file.

In AVX2 H-resizer we have unaligned load from src+pixel_offset[] address https://github.com/DTL2020/AviSynthPlus/blob/034a47e2c91ad9d84ad24492d37a18f99b58d996/avs_core/filters/intel/resample_avx2.cpp#L101

[manolito]

It worked okay for me (3.7.4 x64 on an i5). Is your MaskTools up to date? What are the properties (resolution, colourspace) of the source?

My MaskTools version is mt_masktools-26.dll, this is what Didée recommends. My usual sources are half HD (1280x720), YUV 4:2:0, nothing special.

I only use AVS+ x32, I do not want to clutter my workflow with a mix of 32bit und 64bit plugins. This shoult not matter for an avsi plugin though.