Avisynth+

[Reel.Deel]

Thank you pinterf and qyot27. Awesome job!

[pinterf]

Originally Posted by StainlessS

Nearly

Blankclip(width=120,height=120,Color=$808080)
/*
Text "cs[x]f[y]f[first_frame]i[last_frame]i[font]s[size]f[text_color]i[halo_color]i[align]i[spc]i[lsp]i[font_width]f[font_angle]f[interlaced]b[font_filename]s[utf8]b"
*/

Text("Hello\nWorld",lsp=0,align=5)

You are so right. I'm getting old. Seems that I have really done it

[pinterf]

Originally Posted by poisondeathray

pinterf's test version had fixed the errors in this post with the internal avs conversion
https://forum.doom9.org/showthread.php?p=1897686

pinterf test version
https://forum.doom9.org/showthread.php?p=1898860

But using the recent 3.5, r3043 , some differences are back. 12bits again "fixes" it

avsresize/zimg/zlib works using 10bits with either version

I can see the same small differences which are normal I think. The big differences are over.

[poisondeathray]

Originally Posted by pinterf

I can see the same small differences which are normal I think. The big differences are over.

It's an improvement, but it should be lossless

PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

infinity with vapoursynth / avsresize / zlib/zimg
PSNR r:inf g:inf b:inf average:inf min:inf max:inf

[StainlessS]

Originally Posted by pinterf

You are so right. I'm getting old. Seems that I have really done it

Good memory you did really do it.

class SimpleText : public GenericVideoFilter
  /**
    * SimpleText creation class
   **/
{
public:
  SimpleText(PClip _child, const char _text[], int _x, int _y, int _firstframe, int _lastframe,
    const char _fontname[], int _size, int _textcolor, int _halocolor, int _align,
    int _spc, bool _multiline, int _lsp, int _font_width, int _font_angle, bool _interlaced, const char _font_filename[], const bool _utf8, IScriptEnvironment* env);
  virtual ~SimpleText(void);
  PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);

  static AVSValue __cdecl Create(AVSValue args, void*, IScriptEnvironment* env);

  int __stdcall SetCacheHints(int cachehints, int frame_range) override {
    AVS_UNUSED(frame_range);
    return cachehints == CACHE_GET_MTMODE ? MT_NICE_FILTER : 0;
  }

private:
  const int x, y, firstframe, lastframe;
  const int size; // n/a
  const int lsp;
  const int font_width, font_angle; // n/a
  const bool multiline;
  const bool interlaced; // n/a
  const int textcolor, halocolor, align;
  const int spc; // n/a
  const int halocolor_orig;
  const char* const fontname; // n/a
  const char* const text;
  const char* const font_filename; // n/a
  const bool utf8;
};

Only the names were changed to protect the innocent

[pinterf]

Originally Posted by poisondeathray

It's an improvement, but it should be lossless

PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

infinity with vapoursynth / avsresize / zlib/zimg
PSNR r:inf g:inf b:inf average:inf min:inf max:inf

The algorithm has no more flaws I think. I have to check the coefficient accuracy.

[poisondeathray]

Originally Posted by pinterf

The algorithm has no more flaws I think. I have to check the coefficient accuracy.

PSNR (according to ffmpeg psnr) it's actually the same value with r2944 test version or r3043 (neither were lossless) ; so I was wrong , it wasn't "fixed" with that test version

pre r2944
[Parsed_psnr_4 @ 000000f905391940] PSNR r:59.321403 g:87.953516 b:73.777761 average:63.933949 min:63.933949 max:63.933949

r2944, r3043 - improved
[Parsed_psnr_4 @ 00000049feda2dc0] PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

It's "inf" with vapoursynth or avsresize in all cases
[Parsed_psnr_4 @ 00000014ab642a00] PSNR r:inf g:inf b:inf average:inf min:inf max:inf

Results do not change if I test a written out bmp, or pipe into ffmpeg




Historically, ffmpeg swscale had many issues in the past with YUV/RGB conversions; but even it gets this 8bit RGB => 10bit YUV444 => 8bit RGB conversion correct now (at least with this test image)

ffmpeg -i yuv_exprm_02_bird.png -vf scale=out_color_matrix=bt709,format=yuv444p10le,scale=in_color_matrix=bt709,format=gbrp ffmpeg_swscale.bmp

ffmpeg -r 24 -i ffmpeg_swscale.bmp -r 24 -i yuv_exprm_02_bird.png -lavfi  "[0:v]settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]psnr="stats_file=ff_psnr_ffmpeg_swscale.log"" -f null -

[Parsed_psnr_4 @ 00000098089e2140] PSNR r:inf g:inf b:inf average:inf min:inf max:inf



Thanks for your work pinterf and qyot27

[frencher]

Hi all,

I search for works my two plugins x86 HDR_AGC and svpflow

With only HDR it's works
With only svpflow works
With both HDR_AGC and svpflow WMP crash

How fix it

Thank's for all

Plugins is
HDR > https://github.com/Anime4000/IFME/wi...nth--HDR-Video
SVP > https://www.svp-team.com/forum/viewt...d=57410#p57410

[LigH]

Originally Posted by pinterf

All I can say that Midnight Commander rulez

For Windows, the Far manager is my choice.

[pinterf]

Originally Posted by poisondeathray

PSNR (according to ffmpeg psnr) it's actually the same value with r2944 test version or r3043 (neither were lossless) ; so I was wrong , it wasn't "fixed" with that test version

pre r2944
[Parsed_psnr_4 @ 000000f905391940] PSNR r:59.321403 g:87.953516 b:73.777761 average:63.933949 min:63.933949 max:63.933949

r2944, r3043 - improved
[Parsed_psnr_4 @ 00000049feda2dc0] PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

VapourSynth and avsresize is using the same library, they have to have the same results.

Avsresize has the advantage that it can convert _directly_ from 8 bit rgb to 10 bit YUV. I suppose that there is no 10 bit intermediate rgb result.

Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless

a
ConvertToPlanarRGB()
ConvertBits(10) # Z advantage: single step 8 bit rgb 10 bit yuv
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP10")
ConvertToRGB24()
z1=last #RGBP10 step before RGB24 works

And finally: avsresize is possibly using float arithmetic internally.

There are several types of converters, their usage depends on bit depth and processor capability.

One method (SSE2) is using the usual 15 bit integer arithmetic. I'm using it for 10-14 bit targets.

The other is converting the pixels to float, do the matrix multiplication and then converts the result back to the integer domain. Now I'm using it only for 16 bit case because the first method's SIMD intrinsics support only signed data without any tricks (16 bit is unsigned).

Test2:
So I built a test version, where I was using the 32 bit float way for 10 bit data instead of the above mentioned integer arithmetics. Result: I only looked at the difference clips and visually (looking at rare dot distribution showing the non-losslessness) it had the same output as z_ConvertXXX (latter with the 10 bit input in order to compare apples to apples)

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

But Avisynth resizer is not capable to chain bit depth conversion with rgb->yuv conversion so I'd say it'll never give such losslessness.

[pinterf]

Originally Posted by frencher

With only HDR it's works
With only svpflow works
With both HDR_AGC and svpflow WMP crash

How fix it

Possibly HDRAGC source code is needed which is unfortunately not available (never published)

[TheFluff]

Originally Posted by pinterf

Avsresize has the advantage that it can convert _directly_ from 8 bit rgb to 10 bit YUV. I suppose that there is no 10 bit intermediate rgb result.

I don't think that's true, but this is:

Originally Posted by pinterf

And finally: avsresize is possibly using float arithmetic internally.

As far as I know zimg (avsresize) has no special direct conversions between any formats at all. Bitdepth changes, colorspace changes and resolution changes are separate filters internally and it builds a filter graph automatically to do the conversion you want. Depending on what you're doing, the graph builder may decide to start the processing by increasing the bitdepth, to reduce intermediate losses. Converting colorspace is one such case - if you do that, the first thing it'll do is convert the pixel type to float, then upscale the chroma if necessary, and only then proceed to convert to whatever target format and resolution you want.

See https://github.com/sekrit-twc/zimg/b...ilder.cpp#L669 for details, it has comments describing the process of building a filter chain for doing arbitrary conversions.

[poisondeathray]

Originally Posted by pinterf

VapourSynth and avsresize is using the same library, they have to have the same results.

I have seen implementation differences between vapoursynth's resize, ffmpeg -vf zscale, and avsresize. Despite being based the same library. It might be that the "snapshot" was based on different build or commits, I didn't look too closely. But this occurs for certain.

Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless

And ConvertBits(12) was NOT enough to "fix" it, yet 12bits is "enough" for internal resizer (for amplified visual differences, I didn't check PSNR). It doesn't entirely make sense, could something else be going on there?

Test2:
So I built a test version, where I was using the 32 bit float way for 10 bit data instead of the above mentioned integer arithmetics. Result: I only looked at the difference clips and visually (looking at rare dot distribution showing the non-losslessness) it had the same output as z_ConvertXXX (latter with the 10 bit input in order to compare apples to apples)

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

But Avisynth resizer is not capable to chain bit depth conversion with rgb->yuv conversion so I'd say it'll never give such losslessness.

Thanks for taking the time to investigate this

Does that imply ffmpeg swscale is using float internally too? I'd imagine that it didn't for speed purposes

My memory is a bit rusty, but once upon a time, I recall someone did some matlab calculations and +2 bits was supposedly enough to cover this conversion (just like 12bit YUV444 was sufficient to cover 10bit RGB), but I should have looked into the details more thoroughly

[poisondeathray]

Originally Posted by pinterf

Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless

Actually, double checking this with PSNR, Z1 was not lossless to begin with .

[Parsed_psnr_4 @ 00000062fb042cc0] PSNR r:inf g:inf b:92.591089 average:97.362301 min:97.362301 max:97.362301

a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP10")
ConvertToRGB24()
z1=last

Z2 was lossless
[Parsed_psnr_4 @ 0000005dfa5d2cc0] PSNR r:inf g:inf b:inf average:inf min:inf max:inf

a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP")
ConvertToRGB24()
z2=last

If you add ConvertBits(10) after ConvertToPlanarRGB(), it's no longer lossless either

[zeropc]

Originally Posted by qyot27

AviSynth+ 3.5.0 has been released.

The big, shiny new feature this time around: native support for Linux, macOS, and BSD. Full list of changes:

New: Native macOS support.

Nice ... Where can I get the macOS version?

There are build instructions here and a separate thread in this subforum for cross-platform support.

[pinterf]

Originally Posted by TheFluff

As far as I know zimg (avsresize) has no special direct conversions between any formats at all. Bitdepth changes, colorspace changes and resolution changes are separate filters internally and it builds a filter graph automatically to do the conversion you want.

Thanks, I see. So the advantage there is simply not having an integer (e.g. 10 bit) intermediate result but rather a 32 bit float one?

[pinterf]

Originally Posted by pinterf

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

Anyway, there are some RGBP->YUV444 enhancements in my development branch:
- Internal calculation method is changed to use floats for 10-14 bits as well (16 bit was already working like this) for greater precision
- much quicker AVX2 implementation for 10-16 bits (was: SSE2/SSE4)

[StainlessS]

BugRep:

From here[EDIT: LINK FIXED]:- https://forum.doom9.org/showthread.p...55#post1728455

Originally Posted by StainlessS

@Martin53,

For your version StrReplace,

    s=StrReplace("abc","","1")

ie replace "" with "1",
Causes silent crash due to stack exhaustion.
(Problem due to FindStr("abc","") returning result 1 [bit of a daft result, 0 not found would perhaps be more sensible]).
Should return source string s where StrLen(find)==0

Same here for Avs+ ReplaceStr().

Colorbars
S=ReplaceStr("hello","","1")
Subtitle(s)

EDIT: Script fix for StrReplace()

Function StrReplace(string base, string sought, string rep) { # http://avisynth.nl/index.php/HDColorBars
	pos = FindStr(base, sought)
	return (sought=="")||(pos==0)?base:StrReplace(LeftStr(base,pos-1)+rep+MidStr(base,pos+StrLen(sought)),sought,rep)
}

EDIT: Maybe this line on Wiki could stand some attention [meaning is inverted]:- http://avisynth.nl/index.php/Interna...ons#ReplaceStr

sig if false (the default), search is case-sensitive; if true, search is not case-sensitive.

EDIT: By the way, RT_Stats RT_StrReplace has default Sig=True, but of course choice is yours.

[StainlessS]

New types.h prevents plugin compile on older versions of visual studio [missing header files].
Mine is VS 2008 Express with Windows SDK 7.0.

Previous Types.h

#ifndef AVS_TYPES_H
#define AVS_TYPES_H

// Define all types necessary for interfacing with avisynth.dll

#ifdef __cplusplus
  #include <cstddef>
#else
  #include <stddef.h>
#endif

// Raster types used by VirtualDub & Avisynth
typedef unsigned int    Pixel32;
typedef unsigned char   BYTE;

// Audio Sample information
typedef float SFLOAT;

#ifdef __GNUC__
typedef long long int INT64;
#else
typedef __int64 INT64;
#endif

#endif //AVS_TYPES_H

New one

#ifndef AVS_TYPES_H
#define AVS_TYPES_H

// Define all types necessary for interfacing with avisynth.dll
#include <stdint.h>
#include <stdbool.h>
#ifdef __cplusplus
  #include <cstddef>
#else
  #include <stddef.h>
#endif

// Raster types used by VirtualDub & Avisynth
typedef uint32_t Pixel32;
typedef uint8_t  BYTE;

// Audio Sample information
typedef float SFLOAT;

#endif //AVS_TYPES_H

What is minimum compiler/SDK required for plugin builds for Avs+ and avs Std v2.60 using avs+ headers.

(You can probably get headers from eg VS 2017 community)

EDIT: stdint.h on github:- https://github.com/glfw/glfw/blob/ma...s2008/stdint.h