AviSynth+ thread Vol.2 [Archive] - Page 15

StainlessS

9th November 2020, 05:44

Bug in either Avisynth+ 3.6.2 r3320 or VDub2 build 44282 (latest), not sure which but suspect Avs+.

Below plays in PotPlayer OK, but grey frame error in VD2.

Error reading source frame 0: Error decompressing video frame 0: Cannot decompress video frame: the video data is too short(4084800 bytes, should be 5446400).

Looks like VD expecting alpha plane but aint getting it from AVS+. [ 4084800 * 4/3 = 5446400 ]

Demo bug

FIXBUG = False
BITS=16

ColorBars.KillAudio

ConvertToPlanarRGBA
# ConvertToYV24.AddAlphaPlane # Alternative error Src with Alpha

#ConvertBits(Bits=BITS) # Optional to error [errors at all depths]

Info # Show Src Colorspace = RGBA or YUVA444 [RGB or YUV with Alpha]

ConvertToYUV444 # We want 8 bit Planar YUV444 : EDIT: ConvertToYUV444 with alpha sources, converts to YUVA444.
(FIXBUG && HasAlpha) ? RemoveAlphaPlane : NOP # Avoid RGBAP/YUVA444P8 error in VirtualDub2 (OK in PotPlayer but grey screen in VD2 if YUVA)
ConvertBits(Bits=8)

EDIT: Oops, corrected use of BITS, corrected in my test script but forgot to update post.

Intent of last 3 lines above is to convert all colorspaces to 8 bit YUV444 or YUVA444. [RemoveAlphaPlane is just to fix above VD2 Alpha bug]

EDIT: Post prompting the bugrep:- https://forum.doom9.org/showthread.php?p=1927855#post1927855

EDIT: Above Avs+ version was v3.6.2 test2 [r3320], same bug exists with v3.6.2 test3 [r3325].

EDIT:
Lil bit of inconsistancy, there exists ConvertToPlanarRGB and ConvertToPlanarRGBA without and with target alpha channel,
irrespective of source alpha. But ConvertToYUV444 copies alpha if exists in source colorspace.
Should they not work in the same way [ie should there not also be a ConvertToYUVA444 and ConvertToYUV444 without target alpha].

VoodooFX

11th November 2020, 10:58

@pinterf when you'll have a time could you look at bug with Prefetch and Overlay -> https://forum.doom9.org/showthread.php?p=1927882#post1927882

pinterf

11th November 2020, 19:25

Bug in either Avisynth+ 3.6.2 r3320 or VDub2 build 44282 (latest), not sure which but suspect Avs+.

Below plays in PotPlayer OK, but grey frame error in VD2.

For VD it all depends on the negotiated fourCC codes over VfW.

I found that YUVA444P8 is not covered by the format negotiations.
YUVA444P10, P12 and P14 is converted to YUVA444P16 and are negotiated as "Y416" fourcc code.
There are additional formats which are not covered, either because I could not find fourcc codes for them, or could not test it.
A source code comment in main.cpp: // fixme: YUVA420P8, grey 10+ bits such as Y16 are not covered

ConvertToxxxx inconsistencies: yes, there are some. Perhaps historically ConvertToYUV444 was the first one which replaced ConvertToYV24 for all bit depths.
Then came planar RGB, and since there was already an explicite ConvertTo converters for both non-alpha RGB24 and alpha RGB32, I kept that for planar RGB as well.

pinterf

12th November 2020, 12:21

StainlessS

12th November 2020, 13:29

Thanx P, tastes good.

FranceBB

12th November 2020, 16:18

AviSynth+ 3.6.2-test4 (https://drive.google.com/uc?export=download&id=1L6dC0JdSIM5uSOUsuZOI6UcpfPycG0VK)
20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case

Wow, thanks for that!
This is probably the first time in 16 years that something I suggest gets implemented in the official master.
It feels like a kinda special moment. :D

https://revpacman.files.wordpress.com/2013/06/celebration-time.jpg

VoodooFX

12th November 2020, 18:04

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment

Perfect, no more borked frames.

gispos

12th November 2020, 20:13

Wow, thanks for that!
This is probably the first time in 16 years that something I suggest gets implemented in the official master.
It feels like a kinda special moment. :D

https://revpacman.files.wordpress.com/2013/06/celebration-time.jpg
Nice. Man should never give up hope. :D

StainlessS

12th November 2020, 23:00

Its like I often hear others say, " That FranceBB, he's 'special' ". :)

manolito

29th November 2020, 08:50

This is a follow-up to this previous post:
https://forum.doom9.org/showthread.php?p=1925852#post1925852

I have to correct myself, the different AVS+ test versions have nothing to do with the random crashes I was experiencing. The magic cure to avoid such crashes is "RequestLinear". I did many many tests, and I can always reproduce these findings.

The source filters are the first filters which need the RequestLinear call (all of them, be it DSS2Mod, FFVideoSource or LWLibavVideoSource). If you experience such random crashes, just put the RequestLinear call right after the source filter.

Other AVS filters also need this. Just the other day I had a source which badly needed an AntiAliasing filter. I used daa3mod.avsi (which uses FFT3DFilter), and this caused reproduceable crashes with MT enabled. Placing a RequestLinear call right after the AntiAliasing filter fixed it for me.

Of course this will slow down the conversion speed quite a bit. But the overall speed was still faster than turning off MT altogether.

BTW I always use "RequestLinear(rlim=50, clim=50)" which was proposed by Almosely a while ago. No idea if this makes a difference.

Cheers
manolito

real.finder

29th November 2020, 09:31

Other AVS filters also need this. Just the other day I had a source which badly needed an AntiAliasing filter. I used daa3mod.avsi (which uses FFT3DFilter), and this caused reproduceable crashes with MT enabled. Placing a RequestLinear call right after the AntiAliasing filter fixed it for me.

you mean mcdaa3() in daa3mod.avsi not daa3mod() in daa3mod.avsi? since daa3mod() don't use FFT3DFilter

anyway

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="FFT3DFilter(Sigma=(adSigma+1.0)/f)")
Prefetch(4)

https://i.postimg.cc/0z3GNGvn/Annotation-2020-11-29-112844.png (https://postimg.cc/0z3GNGvn)

so yes, FFT3DFilter has problem in mt that already fixed in neo_fft3d but neo_fft3d has it own bugs that not fixed yet, so we need pinterf fix it in old FFT3DFilter since MeteorRain seems no longer active in avs development

edit: dfttest was had same problem, it was fixed by pinterf back then https://github.com/pinterf/dfttest/commit/ebd41672b88addaff4fd2a20956cb6767ae54fb4

pinterf

30th November 2020, 10:10

you mean mcdaa3() in daa3mod.avsi not daa3mod() in daa3mod.avsi? since daa3mod() don't use FFT3DFilter

anyway

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="FFT3DFilter(Sigma=(adSigma+1.0)/f)")
Prefetch(4)

https://i.postimg.cc/0z3GNGvn/Annotation-2020-11-29-112844.png (https://postimg.cc/0z3GNGvn)

so yes, FFT3DFilter has problem in mt that already fixed in neo_fft3d but neo_fft3d has it own bugs that not fixed yet, so we need pinterf fix it in old FFT3DFilter since MeteorRain seems no longer active in avs development

edit: dfttest was had same problem, it was fixed by pinterf back then https://github.com/pinterf/dfttest/commit/ebd41672b88addaff4fd2a20956cb6767ae54fb4
Try this one, please:
https://github.com/pinterf/fft3dfilter/releases/tag/v2.7

real.finder

30th November 2020, 11:56

Try this one, please:
https://github.com/pinterf/fft3dfilter/releases/tag/v2.7

seems work now, thanks! lets see if manolito problem fixed too

manolito

30th November 2020, 12:43

No, it is not fixed...

The new version refuses to work on my ancient WinXP computer, and this means that I will not even try it on my newer Win7 machines. I simply do not want to maintain different plugin versions on my different computers. If it does not work on my oldest WinXP machine then I refuse to use it on my newer computers. Least common denominator, and this is it for me,

If this means that when I use the old Fizick build on one of my newer Win7 machines under the the latest AVS+ version in MT mode and I need to use RequestLinear right afterwards, so be it. FFT3DFilter is slow anyways, and if using RequestLinear makes it even a little bit slower, so what...

pinterf

30th November 2020, 12:57

No, it is not fixed...

The new version refuses to work on my ancient WinXP computer, and this means that I will not even try it on my newer Win7 machines.
Too bad, it was built with the usual XP-friendly settings, I cannot do more precaution for you.

Nuihc88

30th November 2020, 12:58

The magic cure to avoid such crashes is "RequestLinear". [...] Placing a RequestLinear call right after the AntiAliasing filter fixed it for me.

Of course this will slow down the conversion speed quite a bit. But the overall speed was still faster than turning off MT altogether.

This got me curious, would adding extra 'Prefetch(1,4)' lines around problematic filters have the same effect?
Not sure if it would be faster, as i haven't used RequestLinear before; couldn't find any documentation for it either.

Another thing that could increase stability would be adding 'OnCPU(4)' at the end of your script, as it creates a very low latency caching pipeline of some kind.

I'm using OnCPU and multiple Prefetchers on all my scripts these days as both seem to boost real-time performance by reducing buffer underruns.

pinterf

30th November 2020, 13:03

...
I'm using OnCPU and multiple Prefetchers on all my scripts these days as both seem to boost real-time performance by reducing buffer underruns.
I'm not sure OnCPU is doing anything, it was an addition from nekopanda's CPU/CUDA branch which I have not removed entirely.
edit: OnCPU docs in the original repo
https://translate.google.com/translate?sl=ja&tl=en&u=https://github.com/nekopanda/AviSynthPlus/wiki/OnDevice

Groucho2004

30th November 2020, 13:06

...

If this means that when I use the old Fizick build on one of my newer Win7 machines under the the latest AVS+ version in MT mode and I need to use RequestLinear right afterwards, so be it. FFT3DFilter is slow anyways, and if using RequestLinear makes it even a little bit slower, so what...
RequestLinear(rlim=50, clim=50) should not slow down the process that much. I did quite a few tests when I made a standalone version of it.

real.finder

30th November 2020, 13:08

Too bad, it was built with the usual XP-friendly settings, I cannot do more precaution for you.

he use xp on sse (Pentium III) cpu so usual XP-friendly settings is not enough

Nuihc88

30th November 2020, 13:36

I'm not sure OnCPU is doing anything, it was an addition from nekopanda's CPU/CUDA branch which I have not removed entirely.
edit: OnCPU docs in the original repo
https://translate.google.com/translate?sl=ja&tl=en&u=https://github.com/nekopanda/AviSynthPlus/wiki/OnDevice

I can tell from my tests that it's definitely doing something. [Related info] (https://github.com/CrendKing/avisynth_filter/issues/21)

How much of a performance difference there is seems to depend on the CPU load and the difference is not always obvious, but there are times when real-time AviSynth+ filtering under high CPU load consistently causes stuttering from dropped frames without it, but replaying the same clip with OnCPU works fine every time. As to whether the ported function is operating as designed, i have no idea; i just assumed nekopanda's documentation still applies and it does appear to function consistently with what is described there.

pinterf

30th November 2020, 13:39

I can tell from my tests that it's definitely doing something. [Related info] (https://github.com/CrendKing/avisynth_filter/issues/21)

How much of a performance difference there is seems to depend on the CPU load and the difference is not always obvious, but there are times when real-time AviSynth+ filtering under high CPU load consistently causes stuttering from dropped frames without it, but replaying the same clip with OnCPU works fine every time. As to whether the ported function is operating as designed, i have no idea.
Thanks for he clarification.
edit: Have you played with SetCacheMode?
SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size

pinterf

30th November 2020, 13:42

he use xp on sse (Pentium III) cpu so usual XP-friendly settings is not enough
True. Even 32 bit version requires sse2.

Nuihc88

30th November 2020, 13:51

edit: Have you played with SetCacheMode?

Yes, for real-time usage i always set SetCacheMode(0) as it makes seek times faster.

pinterf

30th November 2020, 13:56

Yes, for real-time usage i always set SetCacheMode(0) as it makes seek times faster.
O.K. Please keep sharing your experiments.

FranceBB

30th November 2020, 23:17

Just for the records, I tried the XP build on my XP with an SSE4.2 CPU and it works, so it is XP compatible, it's just that it can't work on CPUs that only have SSE.
Just a quick question, though.
I noticed that your new build works with all planar high bit depth, 8bit, 10bit, 12bit, 14bit, 16bit and even 32bit float and I'm really thankful for that, however I noticed an oddity.
When I just call it like this

FFT3DFilter()

on a 32bit float image, it looks ok:

https://i.imgur.com/1qAiuP2.png

however if I try to use the settings I generally use, I get this:

FFT3DFilter(sigma=3.0, beta=1.0, plane=4, bw=16, bh=16, ow=8, oh=8, bt=3, kratio=3.0, sharpen=1.0,
scutoff=0.3, svr=1.0, smin=4.0, smax=30.0, measure=true, interlaced=false, wintype=0, degrid=1.0, dehalo=1.0, hr=2.0, ht=50.0)

https://i.imgur.com/IGU6ErZ.png

however, if I try up to 16bit planar with the very same settings, it works fine:

https://i.imgur.com/ZjTZNHm.png

I tried to pinpoint what was the cause, and apparently plane=4 is the cause, but why? plane=4 means that it's gonna process both chroma and luma, so it's failing to process chroma correctly 'cause if I set plane=0 (only luma) it works just fine even on a 32bit float input:

https://i.imgur.com/pDzke7W.png

With plane=1 (U channel of the chroma) 32bit float:

https://i.imgur.com/DUZxOiN.png

with plane=2 (V channel of the chroma) 32bit float:

https://i.imgur.com/jYnf3R2.png

Did you intend to allow users to filter with 32bit float precision so this is a bug or perhaps you didn't want us to use 32bit but you forgot to add an assert to stop us doing that? :P

Thank you in advance and as always your work is very much appreciated! ;)

pinterf

1st December 2020, 09:41

J
Did you intend to allow users to filter with 32bit float precision so this is a bug or perhaps you didn't want us to use 32bit but you forgot to add an assert to stop us doing that? :P

Thank you in advance and as always your work is very much appreciated! ;)
Of course it's a bug.
Check this one (manolito can test is as well)
https://github.com/pinterf/fft3dfilter/releases/tag/v2.8
(fixing and supporting a half-dead plugin version is always fun :) )

pinterf

1st December 2020, 12:07

Updated avisynth wiki:
http://avisynth.nl/index.php/Internal_functions#Runtime_functions_for_frame_properties
http://avisynth.nl/index.php/Internal_functions#SetCacheMode

DTL

1st December 2020, 23:34

It looks like bug in resampler if using YV12 (4:2:0 planar i think):

After performing downsize and converting to YV12 and upsize - the image buffer got buggy blue (blue-yellow) pattern from the bottom. The pattern is unstable at different script running and may changes at different frames. Sometime crash with memory access violation error (sometime display grey frame in virtualdub and write an exception string at the status line).

Script:

ImageReader("01.png")

GaussResize(width/10,height/10,p=15)
ConvertToYV12()

SincResize(width*8,height*8,taps=20)

01.png image is about 1280x720 in size. https://i3.imageban.ru/out/2020/11/25/eb7046de78d66f7e93d8766c55f37c32.png

Buggy output:
https://i1.imageban.ru/out/2020/12/02/185f4f561a2e89ff0682d75fef797d8b.png

It looks bug mostly appear is processing (upsizing) small enough image buffers.

Almost version independent - in Avisynth+ from r2777 to 3.6.1.

pinterf

2nd December 2020, 11:15

It looks like bug in resampler if using YV12 (4:2:0 planar i think):

After performing downsize and converting to YV12 and upsize - the image buffer got buggy blue (blue-yellow) pattern from the bottom. The pattern is unstable at different script running and may changes at different frames. Sometime crash with memory access violation error (sometime display grey frame in virtualdub and write an exception string at the status line).

It looks bug mostly appear is processing (upsizing) small enough image buffers.

Almost version independent - in Avisynth+ from r2777 to 3.6.1.
That blueish haze is there in classic 2.6 as well.
I have cought the crash, it's because of an internal pitch table (which is the size of the actual source height) is too small compared to the filter size

I'm using this simplified script:
SetMaxCPU("none") # crash is more reproducible
BlankClip(1000,320,36, pixel_type="YV24")
SincResize(width,height*2,taps=20) # crash when height<taps*2
#SincResize(width,height*2,taps=18) # works

Now I put there an error message, e.g.:
"Source height (36) is too small for this resizing method, must be minimum of 40"

The artifacts you were seeing at the buttom came from random memory content instead of crashing immediately.

Soulvomit

2nd December 2020, 12:05

I'm trying to load a 16-bit RGB AVI exported by VirtualDub2 but AviSynth says there's no decompressor for "b64a". What should I do? I'm using the latest build.

LigH

2nd December 2020, 13:26

How do you load it with AviSynth? Using AviSource?

Soulvomit

2nd December 2020, 14:07

Yep, just one line in the entire script opened with VirtualDub2: avisource("avi.avi")

StainlessS

2nd December 2020, 14:50

pinterf

2nd December 2020, 15:22

Based on guesswork and :- http://avisynth.nl/index.php/AviSource
(look for b64a)

maybe try
FourCC="BRA[64]" and "G4[0][16]" and "b64a" : EDIT: Not sure if "*" used in linked table should be used or not, maybe try "*BRA[64]" also.
and
Pixel_type="RGB64" and "RGBAP16" [EDIT: colorspace returned to AVS, Interleaved, and then Planar]

But I is really just guessin'.
Try 1st,

AviSource("...", FourCC= "BRA[64]", Pixel_type="RGB64")
AviSource("...", FourCC="*BRA[64]", Pixel_type="RGB64")

BRA[64] means: "BRA" + Chr(64)
For me AviSource works flawlessly for an avi exported as b64a. I have Magicyuv and possibly some other random codecs installed.

StainlessS

2nd December 2020, 15:36

BRA[64] means: "BRA" + Chr(64)
Aha, thats wot that stuff means, eh! [EDIT: I thought Avisource() would do the conversion "BRA[64]" to "BRA@"].

I tried this to create RGBA 64 bit

Colorbars.KillAudio
ConvertToRGB64
Trim(0,-100)
#Info

Then Loaded into VDub2 and saved using Direct Stream Copy [uncompressed] to "Test.avi".
[Full Processing instead of Direct Stream Copy converts to 8 bit with my default Decode Format setting]

MediaInfo (version I'm using shows no bit depth but shows Codec ID (FourCC) as "BRA@".

AviSource(".\Test.avi",FourCC="BRA@")
Info

https://i.postimg.cc/TpD6MGd1/Test2-00.jpg (https://postimg.cc/TpD6MGd1)

EDIT:
This

AviSource(".\Test.avi",FourCC="BRA@",Pixel_Type="RGBAP16")
Info

Produces same RGB64 interleaved, I was expecting planar RGBA 16 .
https://i.postimg.cc/RqQMNvrY/Test3-00.jpg (https://postimg.cc/RqQMNvrY)
EDIT: Arh, looks like Pixel_Type is just a hint to format type, I thought it was requested result colorspace.

EDIT: I've found "b64a" references associated to Apple, and ProRes. b64a "Apple 64-bit ARGB". https://wiki.multimedia.cx/index.php?title=Apple_ProRes

EDIT: https://wiki.multimedia.cx/?title=SheerVideo
Would seem to be a 10 bit (out of 16) format in Sheer Video codec [EDIT: same 10 from 16 in Apple too]
EDIT: Or 'At least 10 bit out of 16 bit', or presumably Bitdepth=Most significant bits of 16.
Pixel Formats

The generic Sheer codec and each of the 6 main specific Sheer codecs support all of the following pixel formats:

RGB[A] 10b:
b64a
b48r
F10k
R10k
S10k
F210
r210
S210

I have Magicyuv and possibly some other random codecs installed.
I dont have MagicYUV. (maybe a really old 8 bit only, somewhere).

StainlessS

2nd December 2020, 17:23

So its not possible to specify RGBP10 style "G3[0][10]" for FourCC, [when contains nul char ie [0]], yes.

blankclip
p = "G3[0][10]"
RT_Subtitle("p=%s : # RGBP10 G3[0][10] r210 R10k",p)
s= "G3" + Chr(0) + Chr(10)
L=strlen(s)
RT_Subtitle("len=%d : s='%s'",L,s,y=1*20)
for(i=1,L) {
Alp=MidStr(s,i,1)
n=Alp.Ord
RT_Subtitle("%d : '%s'",n,Alp,y=(i+2)*20)
}

Chr(10) is Newline and causes printing to move to next line.
https://i.postimg.cc/brNnWmC7/Test-00.jpg (https://postimages.org/)

EDIT: FourCC in code would normally be 32 bit int, whereas in Avs is string which interprets Chr(0) as nul or End-Of-String.
So concatenating (joining) Chr(0) to a string, joins (zero length) empty string "".

EDIT: Or 16 bit

blankclip
p = "G3[0][16]"
RT_Subtitle("p=%s : # RGBP16 G3[0][16]",p)
s= "G3" + Chr(0) + Chr(16)
L=strlen(s)
RT_Subtitle("len=%d : s='%s'",L,s,y=1*20)
for(i=1,L) {
Alp=MidStr(s,i,1)
n=Alp.Ord
RT_Subtitle("%d : '%s'",n,Alp,y=(i+2)*20)
}

Ascii 16 unprintable via RT_subtitle, prints SPACE ' '.
https://i.postimg.cc/4dZwNkNq/Test-00.jpg (https://postimages.org/)

EDIT:
So, you would use "RGBP" as Pixel_type, to retrieve FourCC type "G4[0][16]" and cannot specifiy FourCC.
(Does not seem to be an "RGBAP" Pixel_type, in Docs)

EDIT:
AviSource(string filename [, ...] [, bool "audio", string "pixel_type", string "fourCC", int "vtrack", int "atrack", AVS+ bool "utf8"])
AviFileSource(string filename [, ...] [, bool "audio", string "pixel_type", string "fourCC", int "vtrack", int "atrack", AVS+ bool "utf8"])
OpenDMLSource(string filename [, ...] [, bool "audio", string "pixel_type", string "fourCC", int "vtrack", int "atrack", AVS+ bool "utf8"])

Perhaps could do with variation where FourCC = arg type Int. (Or parse and convert style "G3[0][16]" or "G4[0][16]").

EDIT: To below,
you can try another source filter like ffms2 or lsmash
@Soulvomit, Sorry, I should have suggested that.

poisondeathray

2nd December 2020, 17:26

I'm trying to load a 16-bit RGB AVI exported by VirtualDub2 but AviSynth says there's no decompressor for "b64a". What should I do? I'm using the latest build.

you can try another source filter like ffms2 or lsmash

jpsdr

2nd December 2020, 19:06

Now I put there an error message, e.g.:
"Source height (36) is too small for this resizing method, must be minimum of 40"

I'll wait for the commit...:D

vcmohan

3rd December 2020, 08:00

In case of YUV data like YV12, YV16 I remember to have read that u and V pitches are guaranteed to be equal. In case of YV24 or YUV444 will all 3 planes have identical pitch value?

pinterf

3rd December 2020, 08:05

...
Perhaps could do with variation where FourCC = arg type Int. (Or parse and convert style "G3[0][16]" or "G4[0][16]").

I'm planning to implement the second one.

pinterf

3rd December 2020, 08:15

In case of YUV data like YV12, YV16 I remember to have read that u and V pitches are guaranteed to be equal. In case of YV24 or YUV444 will all 3 planes have identical pitch value?
Yes, they are equal.

StainlessS

4th December 2020, 00:02

I'm planning to implement the second one.
Nice one :)

Yes, they are equal.
Might also be worth mentioning [maybe not for V.C.M, but for others] that pitch can change at every frame, not a clip constant value.

EDIT:

ColorBars.KillAudio
ConvertToYV12

PitchTortureTest
info
Return Last

Function PitchTortureTest(clip c) { # IanB:- https://forum.doom9.org/showthread.php?p=1628159#post1628159
c
A=SelectEvery(4, 0)
B=SelectEvery(4, 1).AddBorders(0,0,8,0).Crop(0,0,-8,0)
C=SelectEvery(4, 2).AddBorders(0,0,16,0).Crop(0,0,-16,0)
D=SelectEvery(4, 3).AddBorders(2,0,22,0).Crop(2,0,-22,0)
Interleave(A,B,C,D)
}

EDIT:

You must use the GetPitch() method on each and every PVideoFrame you get.

StainlessS

4th December 2020, 00:42

# Below all nonsense.
Further to above,
Yes, they are equal.
Is it also possible that something similar to PitchTortureTest() could be applied to any of the color channels, even an alpha channel,
so maybe could argue that above quote should maybe read

they are usually but not guaranteed equal.
so pitch should be ascertained for each frame and for each every channel, or problems could arrise, however infrequently.
Above maybe true (changable) on source frames only, if using NewVideoFrame(), then all frames same channel are equal,
and if YV24 or YV444 then all frames, all channels, are equal.

I think, maybe, perhaps, ???

I usually use SrcPitchU for V channel too, so maybe I amongst many am potentially wrong too.
Discuss.
EDIT:
[Are PitchU and PitchV, internally the same variable ?]
EDIT: Seems that in v2.58 header, VideoFrame there is a variable pitchUV, so single value for both[in v2.58].

EDIT: and in v2.60

class VideoFrame {
volatile long refcount;
VideoFrameBuffer* const vfb;
const size_t offset;
const int pitch, row_size, height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
const int pitchUV, row_sizeUV, heightUV;

Am I talkin' crazy above, do say :)

StainlessS

4th December 2020, 01:52

Got my answer to above daft post, can create separate clips where Y clip, U clip, V clip, all have changable pitch,
but in 'merging' the channels together into single clip - we create a NewVideoFrame which guarantees fixed pitch and copies
source channels into the new fixed pitch clip. Doh!

ColorBars.KillAudio
ConvertToYV24
ShowFrameNumber
K=Last.BlankClip(Length=1)

Y=(Last).PitchTortureTest.ExtractY # differently changing pitch for each channel
U=(K+Last).PitchTortureTest.Trim(1,0).ExtractU #
V=(K+K+Last).PitchTortureTest.Trim(2,0).ExtractV #

#Return Y.Info # Y, shows pitch change
#Return U.Info # U as Y, shows pitch change
#Return V.Info # V as Y, shows pitch change

#Return YtoUV(U,V,Y).info # NO pitch change : Creates and copies into NewVideoFrame() where fixed pitch

H=StackHorizontal(Y.Info,U.Info,V.Info)
Return H.BlankClip.StackVertical(H).Info # Top shows final fixed return clip pitch, bot individual changing channel pitchs

########
Function PitchTortureTest(clip c) { # IanB:- https://forum.doom9.org/showthread.php?p=1628159#post1628159
c
A=SelectEvery(4, 0)
B=SelectEvery(4, 1).AddBorders(0,0,8,0).Crop(0,0,-8,0)
C=SelectEvery(4, 2).AddBorders(0,0,16,0).Crop(0,0,-16,0)
D=SelectEvery(4, 3).AddBorders(2,0,22,0).Crop(2,0,-22,0)
Interleave(A,B,C,D)
}

Return H.BlankClip.StackVertical(H).Info
# Top shows final fixed return clip pitch, bot individual changing channel pitchs [Y, U, V]
https://i.postimg.cc/t73wmWjg/Test-00.jpg (https://postimg.cc/t73wmWjg)

NOTE, ExtractY/U/V does not produce fixed pitch clips, it must just drop unused channels from source and not produce NewVideoFrame().
In shown image @ bottom, Y has pitch of 704, as does U, but V has pitch of 640 [before combining with Stackhorizontal].

FranceBB

5th December 2020, 15:10

Thank you, Ferenc! FFT3D is now working just fine even on 32bit float! :D

Fjord

8th December 2020, 12:57

Calling the internal runtime function AverageB() on a high-bit YUV422Pxx clip (within ScriptClip() or FrameEvaluate()) causes immediate crash of the calling app - either AvsPmod or VirtualDub2. The app just disappears without warning or error message. I assume it is an AviSynth+ bug.

I first encountered this on a ProRes 422 HQ clip, but the script below provides a minimal script below for this reproducible crash, using ColorBarsHD().

The related runtime functions AverageR() and AverageG() work fine on YUV422Pxx clips. AverageB() also works fine on YUV444Pxx clips, so this problems is specific to YUV422Pxx pixel formats. I have confirmed the crash on YUV422P10, YUV422P12, YUV422P16 and YUV422PS clips.

I am using AviSynth+ 3.5 (r3043, master, x86_64), with both AvsPmod v2.6.5.0 (Windows (x86-64) and VirtualDub2 build 44282, on Win10 x64.

Minimal reproducible script:

# This script crashes AviSynth+ 3.5 (r3043)
#
ColorBarsHD ( 1024, 576, pixel_type="YUV444P10" ) # 10-bit
ConvertToYUV422() # change clip to YUV422P10
# show the PixelType
Subtitle("PixelType=" + last.PixelType, Align=9, Size=40)
# show the average value of Blue on each frame (causes crash)
ScriptClip("""
Subtitle("AverageB=" + String(AverageB()), align=7, size=40)
""")
Return last
You can comment out the line with ConvertToYUV422() to see that AverageB() works ok on YUV444P10. I am not familiar with debugging procedures in these apps, so I hope someone can trace where the problem arises.

pinterf

8th December 2020, 13:27

pinterf

8th December 2020, 16:02

EDIT: use test6
Avisynth+ 3.6.2 test6 (20201210) (https://drive.google.com/uc?export=download&id=1ZdSd_TAPRmdkFGerLaIrDVrsIE8pUBGx)

20201210 3.6.2-test6
-----------------------
- AviSource: fix test5 regression which refused handling old formats like YV24

20201208 3.6.2-test5
-----------------------
- Resizers: throw error on too small dimensions vs. taps
- Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
- Overlay: allow 4:1:1 input
- Overlay: fix crash when mask is YUV411 and greymask=false
- Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
- RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
- AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
- AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
- AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
- Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
- Add: AverageA
- New: Average...: allow YUY2, RGB24/32/48/64 inputs

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case