r30.AC2

updated to upstream f2d8f825.

r30.AC

Upstream r30.

r29.AC "It Is the Piece of a Smile Everyone Acquires."

upstream r29 (requires api4 VS) + custom kernel support.

For example, a silly way to implement bilinear using custom kernel support is:

scaled = core.fmtc.resample(src, scale=2, custom=lambda x: max(0, 1-abs(x)), support=1) # bilinear upscale

Added parameters: custom/support, custom_h/support_h, custom_v/support_v. They should behave as the rest of fmtconv parameters (including specifying different custom kernel for horizontal/vertical scaling and/or each plane.)

Also note that fmtconv will apply an additional anti-aliasing low-pass filter for downscales (easy to compensate in your custom kernel though)

r28.A "Tremble in Fear"

Compared to upstream r28 release, this release introduces custom kernel support.

For example, a silly way to implement bilinear using custom kernel support is:

scaled = core.fmtc.resample(src, scale=2, custom=lambda x: max(0, 1-abs(x)), support=1) # bilinear upscale

Added parameters: custom/support, custom_h/support_h, custom_v/support_v. They should behave as the rest of fmtconv parameters (including specifying different custom kernel for horizontal/vertical scaling and/or each plane.)

Also note that fmtconv will apply an additional anti-aliasing low-pass filter for downscales (easy to compensate in your custom kernel though)

r24 pre-release for better compatibility with VS api4

.github/workflows/build.yaml: update build artifact paths

Signed-off-by: akarin <[email protected]>

r23.A

Despite the version number, note that this release correspond to the master branch EleonoreMizo@cc076e1.

Try, try again.

This applies another fix at #1, which aims to fix the underlying VC codegen bug: by moving the singleton instance from function scope (static variable) to file scope, we are hoping to persuade VC to call its constructor at DLL load time, instead of at the first use.

It seems with AVSTP disabled, VC link time optimization is able to fully initialize the singleton at link time, so the result is even better: the underlying data race is completely avoided now.

Bugfix release: racing with AvstpWrapper singleton constructor induced crashes

This release fixes #1 by completely disabling avstp support (does it even help in the VapourSynth environment?)

Github action build test release

This should be the same as upstream r22 + a few insignificant patches on master since the release.

Unfortunately, concurrent data race on AvstpWrapper constructor still exists even when built with Visual Studio 2019.
(Perhaps it's a limitation of the SDK the build it's using?)