Avisynth+

[Reel.Deel]

Isn't it possible and an idea to port fmtconv from vapoursynth to avs+? Would give you all the resizers, kernels, chroma conversion, matrix conversion, gamma space conversion and dithering tools you would I guess.

There's already z.lib resizers: http://forum.doom9.org/showthread.php?t=173986

[pinterf]

Was asking about the output. Apperantly the code is in main.cpp (*), but i don't know that part well enough to tell what and how it should be updated.

(*) see CAVIStreamSynth::Info, CAVIFileSynth::ImageSize, CAVIStreamSynth::ReadFrame and CAVIStreamSynth::ReadFormat.
Thanks for the hints. Made some tests with vdubmod14.

ConvertToYV16().ConvertBits(16) # 1st frame OK, crash when play
ConvertToYV12().ConvertBits(16) # P016 unknown
ConvertToYV12().ConvertBits(10) # P010 unknown
ConvertToYV16().ConvertBits(10) # 1st frame OK, crash when play
ConvertToRGB32().ConvertBits(16) # BRA[64] OK, upside down
ConvertToRGB24().ConvertBits(16) # BGR0 unknown (could not locate decompressor)

For BRA[64] I had to reverse the output though (in avisynth internally it's upside down like RGB32)

[odyssey]

I have a minor issue with plugin loading in Avisynth+

Plugins loaded with absolute path works fine, but if they are just loaded with their name, it complains that it can't find the plugin in the current working dir. It never searches for it in the plugins directory.

E.g. LoadPlugin("DGMVCDecode.dll")

If I comment it out, it works, because it finds it in the plugins directory when calling the function.

Perhaps this should be fixed, so it behaves the same way as normal Avisynth?

[shekh]

Thanks for the hints. Made some tests with vdubmod14.

ConvertToYV16().ConvertBits(16) # 1st frame OK, crash when play
ConvertToYV12().ConvertBits(16) # P016 unknown
ConvertToYV12().ConvertBits(10) # P010 unknown
ConvertToYV16().ConvertBits(10) # 1st frame OK, crash when play
ConvertToRGB32().ConvertBits(16) # BRA[64] OK, upside down
ConvertToRGB24().ConvertBits(16) # BGR0 unknown (could not locate decompressor)

For BRA[64] I had to reverse the output though (in avisynth internally it's upside down like RGB32)

Crash in which module? With VapourSynth P210/P216 worked for me.

[Groucho2004]

I have a minor issue with plugin loading in Avisynth+

Plugins loaded with absolute path works fine, but if they are just loaded with their name, it complains that it can't find the plugin in the current working dir. It never searches for it in the plugins directory.

E.g. LoadPlugin("DGMVCDecode.dll")

If I comment it out, it works, because it finds it in the plugins directory when calling the function.

Perhaps this should be fixed, so it behaves the same way as normal Avisynth?
Works fine for me. What do you use to load the script? VDub, mpchc, x264?

[pinterf]

Crash in which module? With VapourSynth P210/P216 worked for me.
I don't know. Not in avisynth. Works for single step forward or backward.
I will build a 32 bit test soon.

[pinterf]

New test build: Avisynth+ r2367 (http://www.mediafire.com/file/gcts63bn7gb6v44/avsplus-r2367.7z)

20170109 r2367dev

VfW: BRA[64],b64a,BGR[48],P010,P016,P210,P216,Y3[10][10],Y3[10][16],v210
experimental, just to have feedback

Default format FourCCs:
RGB64: BRA[64]
RGB48: BGR[48]
YUV420P10: P010
YUV420P16: P016
YUV422P10: P210
YUV422P16: P216

Use these global variables to override default formats:
OPT_Enable_V210 = true --> v210 for YUV422P10
OPT_Enable_Y3_10_10 = true --> Y3[10][10] for YUV422P10
OPT_Enable_Y3_10_16 = true --> Y3[10][16] for YUV422P16
OPT_Enable_b64a = true --> b64a for RGB64
Overlay: blend for float format
Overlay: blend: SSE4 for 10-16 bit, SSE2 for float
AddAlphaPlane: also accepts clip with Y-only or alpha (YUVA/PRGBA/RGB32/64) for alpha source
(was: optional int/float mask value)

[tuanden0]

Can someone help me the filter fft3dGPU crashed if I use SetFilterMTMode("FFT3dGPU", 3)
Here is my script:

SetFilterMTMode("LWLibavVideoSource", 3)
SetFilterMTMode("gradfun2dbmod", 2)
LWLibavVideoSource("E:\Download\test.mp4")
AssumeFPS(24000, 1001)

#Denoise
SetFilterMTMode("FFT3dGPU", 3)
FFT3DGPU(sigma=4,bt=3).gradfun2dbmod()


Prefetch(6)

[shekh]

I don't know. Not in avisynth. Works for single step forward or backward.
I will build a 32 bit test soon.

I can produce a crash with input pane. Will take some time.

Fixed (build 38494).

[shekh]

New test build: Avisynth+ r2367 (http://www.mediafire.com/file/gcts63bn7gb6v44/avsplus-r2367.7z)

OPT_Enable_Y3_10_10 = true --> Y3[10][10] for YUV422P10
OPT_Enable_Y3_10_16 = true --> Y3[10][16] for YUV422P16


I see bigendian tags:
[10][10]3Y
[16][10]3Y

[jpsdr]

I think it would be great if (at least) the formats RGB64, YUV422P10 and YUV422P16 would be exposed through the VfW interface. Then we can open such scripts in Virtualdub and encode straight to MagicYUV (without any color conversion).
How do you "open" in VDub this kind of avs script ?
Configure video in "DirectStream Copy" ?
I think there will still be an issue with the "Output format to compressor/Display" in Video Color Depth. How do you configure this one ?
Because even if the Compressor can handle it, what about the display ? Disabling both Output and Input Video Pane ? Because the display will probably be possible only with color format VDub understand.
It could be interesting, i'm curious to see how you think you may work and configure VDub for this kind of files.

[Reel.Deel]

@jpsdr

Use shekh's VirtualDub mod: https://forum.doom9.org/showthread.php?t=172021

[pinterf]

I see bigendian tags:
[10][10]3Y
[16][10]3Y
Isn't is normal? It is encoded the same way as all the others.
012P = P210
008Y = Y800
[16][10]3Y = Y3[10][16]
etc...

[shekh]

Isn't is normal? It is encoded the same way as all the others.
012P = P210
008Y = Y800
[16][10]3Y = Y3[10][16]
etc...

This is strange but these literals are translated differently.

'610P' -> 'P','0','1','6'
'\012\0123Y' -> 10,10,'3','Y'

How about this:


#define MAKEFOURCC(byte1, byte2, byte3, byte4) (((uint8)byte1) + (((uint8)byte2) << 8) + (((uint8)byte3) << 16) + (((uint8)byte4) << 24))

MAKEFOURCC('Y', '3', 10, 16)

[pinterf]

Thanks, then I will do this way. Noticed that behaviour but could not find the real reason for it, maybe it is undefined or compiler specific to define dword such way...

[pinterf]

Is there any planar rgb for VfW? Or else I could convert them to classic packed rgb formats on the fly? And 12 and 14 bit 420/422 formats could be silently converted and reported as 16 bits as well.

[shekh]

MagicYUV implements these (planar rgb/rgba 10,12,14,16) G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]
I don`t implement them (it is boring and benefit over b64a is not obvious)

[jpsdr]

MagicYUV implements these (planar rgb/rgba 10,12,14,16) G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]
I don`t implement them (it is boring and benefit over b64a is not obvious)
Having planar data format over interlaced/packed can be a great benefit, the most is avoiding to have to transform (and transform back) the data into planar for doing the process/filter whatever.

@jpsdr
Use shekh's VirtualDub mod: https://forum.doom9.org/showthread.php?t=172021
No 64bits version ? :(
And it seems it's not using the last version for code base, as some menu/interfaces are different from the version i'm using.
Nevertheless, it still can be usefull to have this.

Otherwise, tested :
64bits RGB(A) : Working.
4:2:2 YCbCr 10bits : Working.
4:2:2 planar YCbCr 16-bit : Working.
4:2:0 planar YCbCr 16-bit : Complain can't find decoder for P016.
4:4:4 planar YCbCr 16-bit : Everything is grey.

Release 38494.

[sl1pkn07]

No 64bits version ? :(


https://sourceforge.net/projects/vdfiltermod/files/VirtualDub%20pack/version%2014/

@printf you can upload the avs+ binaries to github instead of cyberloker?

greetings

[shekh]

Having planar data format over interlaced/packed can be a great benefit, the most is avoiding to have to transform (and transform back) the data into planar for doing the process/filter whatever.


If you promise to port some useful filters for rgb planar mode, I can implement it.
Otherwise just having planar source "supported" but immediately converted to packed - is not useful.


No 64bits version ? :(
And it seems it's not using the last version for code base, as some menu/interfaces are different from the version i'm using.


Since original VirtualDub was never hosted publicly, I have no idea about last code base.
If you have it, please share.
Of course some menu/interfaces are different, I am making changes after all.


4:2:0 planar YCbCr 16-bit : Complain can't find decoder for P016.


Not implemented yet.


4:4:4 planar YCbCr 16-bit : Everything is grey.
Release 38494.

May accept Y416 but AviSynth+ does not implement it, I wonder what happens.

[jpsdr]

If you promise to port some useful filters for rgb planar mode, I can implement it.
Otherwise just having planar source "supported" but immediately converted to packed - is not useful.

No, so indeed, don't bother.


Since original VirtualDub was never hosted publicly, I have no idea about last code base.
If you have it, please share.

Can get it here (https://mega.nz/#!VJ9j1aQC!lD2fVyRJuVA3ncM1tOPIeZJ6uEWPdQS1WxEt51zI2Xk). That's the last version that has been made avaible a loong time ago already (you can get it only in the forum, now unfortunately closed).
Thanks for your work on this upgraded version.

I've tested only the modes avaibles on the Decode format menu, that's why i've tested 16 bits 4:2:0.

Thanks for the links with all VDubMod version.

[pinterf]

New test build
Avisynth plus r2372-dev (http://www.mediafire.com/file/rl3fuac03tk3kuz/avsplus-r2372.7z)

20170110 r2372dev (vdubmod14 VfW test)

New: SSE2/SSE4 for 10-16 bit <-> 10-16 bit Planar RGB (and Alpha plane) full scale conversions
(needed for automatic planar RGB -> packed RGB VfW conversions)
VfW:
Fixed: Y3[10][10],Y3[10][16] fourcc's byte order
New: Planar RGB(A) (MagicYUV)
10,12,14,16 bits: G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]
New: YUV444P16 to fourcc Y416
New: Automatic conversion of 12, 14 and float YUV formats to 16 bit for 4:2:0 and 4:2:2
Note: OPT_Enable_Y3_10_16 is still valid as if format was originally 16 bits
New: Automatic conversion of 10, 12, 14 and float YUV formats to 16 bit for 4:4:4
New: Conversion of 10, 12, 14 and float planar RGB formats to RGB64
when global Avisynth variable Enable_PlanarToPackedRGB is true
New: Conversion of 8 bit planar RGB formats to RGB24
when global Avisynth variable Enable_PlanarToPackedRGB is true
New: Conversion of 8 bit planar RGBA formats to RGB32
when global Avisynth variable Enable_PlanarToPackedRGB is true

Note: OPT_VDubPlanarHack=true may still be needed for Virtualdub for YUV planar outputs other than YV12 or else U and V planes are exchanged
Edit: this must affect only 8 bit videos. Fixed in a following release


Supported formats:
BRA[64],b64a,BGR[48],P010,P016,P210,P216,Y3[10][10],Y3[10][16],v210,Y416
G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]

Default format FourCCs:
RGB64: BRA[64]
RGB48: BGR[48]
YUV420P10: P010
YUV420P16: P016
YUV422P10: P210
YUV422P16: P216
YUV444P16: Y416
Planar RGB 10-16 bit: G3[0][10], G3[0][12], G3[0][14], G3[0][16]
Planar RGBA 10-16 bit: G4[0][10], G4[0][12], G4[0][14], G4[0][16]

Global variables to override default formats:
OPT_Enable_V210 = true --> v210 for YUV422P10
OPT_Enable_Y3_10_10 = true --> Y3[10][10] for YUV422P10
OPT_Enable_Y3_10_16 = true --> Y3[10][16] for YUV422P16
OPT_Enable_b64a = true --> b64a for RGB64
Enable_PlanarToPackedRGB = true --> RGBP8->RGB24, RGBAP8->RGB32, all other bit depths to RGB64

[shekh]

New test build
Avisynth plus r2372-dev (http://www.mediafire.com/file/rl3fuac03tk3kuz/avsplus-r2372.7z)


> New: YUV444P16 to fourcc Y416

video data is too short (w*h*6 bytes, should be w*h*8 bytes)

> Note: OPT_VDubPlanarHack=true may still be needed for Virtualdub for YUV planar outputs other than YV12 or else U and V planes are exchanged

I dont know, who is guilty? The Y3[10][10] output works with magic, but requires hack with avs+

[pinterf]

It's history.
Comment in avisynth.h:
// Hack YV16 and YV24 chroma plane order for old VDub's

[shekh]

It's history.
Comment in avisynth.h:
// Hack YV16 and YV24 chroma plane order for old VDub's

Does it mean there is old (bad) VD, and there is new one (which?), where the hack is not needed anymore?
But I have to apply it now, is this expected?

[pinterf]

1.) OK, Y416 is now really done but cannot test, vdub says: XYUV64 output is not implemented. Using vdubmod 38494.

2.) (plane hack)
It looks something like this in the avs source


// Old VDub wants YUV for YV24 and YV16 and YVU for YV12.
if (parent->VDubPlanarHack && !vi.IsYV12()) {
plane1 = PLANAR_U;
plane2 = PLANAR_V;
}
else {
// Set default VFW output plane order.
plane1 = PLANAR_V;
plane2 = PLANAR_U;
}

[shekh]

"XYUV64 output is not implemented" is message from output (dubbing) part, why you see it?
Has nothing to do with raw/avs input.

I think there is misunderstanding, Y3[10][16] is not 16-bit YV16, it has YUV plane order while YV16 has YVU plane order.


ConvertToYV16()

works (YV16)


OPT_Enable_Y3_10_16 = true
ConvertToYV16().ConvertBits(16)

swapped


OPT_VDubPlanarHack=true
OPT_Enable_Y3_10_16 = true
ConvertToYV16().ConvertBits(16)

correct

There is no reason for Y3[10][16] to be affected by VDubPlanarHack since it is brand new fourcc.

[pinterf]

"XYUV64 output is not implemented" is message from output (dubbing) part, why you see it?
Has nothing to do with raw/avs input.

I just had a look at the log window after clicking on play.

[shekh]

I just had a look at the log window after clicking on play.

Thanks, I too often forget about play button.

[pinterf]

I think there is misunderstanding, Y3[10][16] is not 16-bit YV16, it has YUV plane order while YV16 has YVU plane order.

There is no reason for Y3[10][16] to be affected by VDubPlanarHack since it is brand new fourcc.
O.K. I will then use (vi.IsYV16() || vi.IsYV24())
instead of !vi.IsYV12()
In the 8 bit world the latter was enough.
What about YV411? (Y41B)

[ajp_anton]

Question: why are there two versions of RGB, planar and packed? Does the user really have to know/care which one is used?

[jpsdr]

Something came to my mind, i've checked in avisynth.h and didn't see any information about it.
Standard/normal YUV mode is 16..235 for Y and 16..240 for UV. You can have a "full range" mode, but it's "unusual" or not the standard.
VDub has in its color mode a difference for the YUV mode between full range or limited range. I didn't see anything like this in avisynth. Have i missed it (in that case where is it), or is it just that there is not a such thing ?
If there is not something to chose between full or limited range, can we assume that the behavior in this case is the standard/common behavior, meaning the limited range ?
What are the specifications for the extended bit range ? Are they also limited, or are they just only full range by default ?
If limited, how is the range ? Is it proportional (16-240 becomes 4096-61440 in 16 bits) or fixed (16-240 becomes 16-65520 in 16 bits) ?

That make me realise that since the begining, at least the resample and nnedi3 filters are prone to produce incorrect results, as they clip only to 0-255, meaning they can produce out of range values in case of YUV data (but not in case of RGB data, of course).

So, what is exactly the situation about these points ?

[TheFluff]

Avisynth has functions to convert between full and limited range (just pointing that out, because it does seem like you might have somehow missed this) but does not have metadata flagging to keep track of which range a given clip has.

YUV limited range ("TV range") numerical limits for bitdepths above 8 are quite well-defined (see f.ex. the H.264 standard). For any bitdepth, the luma offset is
16 * (2^(bitdepth - 8))
while the range is
219 * (2^(bitdepth - 8))
For chroma, the offset is the same, but substitute 224 for 219 to get the range.

Full range YUV on the other hand isn't well defined at all. It's been discussed extensively in this thread before, see here (http://forum.doom9.org/showthread.php?p=1773277#post1773277) and a number of posts forward.

[jpsdr]

but does not have metadata flagging to keep track of which range a given clip has.

Argh.... That is very troublesome, it's a shame something like this have been missed when it should have been present since the begining...
Thanks for the others informations.

[pinterf]

Can someone help me the filter fft3dGPU crashed if I use SetFilterMTMode("FFT3dGPU", 3)
Here is my script:

Reproduced, but cannot help with it.

I tried with this simplified script:
Colorbars(pixel_type="YV12")
SetFilterMTMode("FFT3dGPU", 3)
FFT3DGPU(sigma=4,bt=3)
Prefetch(6)


Debug log shows, that sometimes this filter requests negative frames.
This was already mentioned, related link:
https://forum.doom9.org/showthread.php?p=1671525#post1671525

Debug log with Prefetch(6) until the sad finish, which occured in fft3dgpu.dll when frame number 7 was requested from it.

ColorBars::GetFrame 0
ColorBars::GetFrame 3
ColorBars::GetFrame 2
ColorBars::GetFrame 1
ColorBars::GetFrame 1
ColorBars::GetFrame -1
ColorBars::GetFrame 5
ColorBars::GetFrame 4
ColorBars::GetFrame 4
ColorBars::GetFrame 4
ColorBars::GetFrame 2
ColorBars::GetFrame 1
ColorBars::GetFrame 0
ColorBars::GetFrame 6
ColorBars::GetFrame 4
ColorBars::GetFrame 6
ColorBars::GetFrame 5
ColorBars::GetFrame 7
ColorBars::GetFrame 1
ColorBars::GetFrame 0
ColorBars::GetFrame 7
ColorBars::GetFrame 8
ColorBars::GetFrame 3
ColorBars::GetFrame 7
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 2 child=007302F8 frame=0A4BF9E8 vfb=0900AEF8 videoCacheSize=0 SeekTime :0.068393
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 1 child=007302F8 frame=0A4BF8B0 vfb=006B6D20 videoCacheSize=0 SeekTime :0.069542
ColorBars::GetFrame 2
ColorBars::GetFrame 6
ColorBars::GetFrame 13
ColorBars::GetFrame 1
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 6 child=007302F8 frame=0A4BFAB8 vfb=0900AEB8 videoCacheSize=0 SeekTime :0.075657
ColorBars::GetFrame 8
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 0 child=007302F8 frame=0A4BFA50 vfb=0900C178 videoCacheSize=0 SeekTime :0.077987
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 4 child=007302F8 frame=0A4BF918 vfb=0900A4F8 videoCacheSize=0 SeekTime :0.078408
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 3 child=007302F8 frame=0A4BF980 vfb=0900C1B8 videoCacheSize=0 SeekTime :0.078792
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 5 child=007302F8 frame=0A4BFB20 vfb=0900ADF8 videoCacheSize=0 SeekTime :0.078573
ColorBars::GetFrame 8
Exception thrown at 0x02DF1FDA (FFT3dGPU.dll) in AVSMeter.exe: 0xC0000005: Access violation reading location 0x00000000.


Although this filter is set for serialized mode in MT, the frame requests are not sequential in a multithreaded environment. Requested frame numbers can jump randomly back and forward. Maybe this situation is not handled too well in the code, but seeing no source for it I cannot make any further assumption.

This post got a bit long, but interesting to see what happens in the background:

Without Prefetch (non-MT):
ColorBars::GetFrame -1
ColorBars::GetFrame 0
ColorBars::GetFrame 1
ColorBars::GetFrame 0
ColorBars::GetFrame 2
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 0 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.025495
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000010
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 1
ColorBars::GetFrame 3
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 1 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006794
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000006
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 2
ColorBars::GetFrame 4
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 2 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006903
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000016
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 3
ColorBars::GetFrame 5
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 3 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006695
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 4
ColorBars::GetFrame 6
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 4 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.005836
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 5
ColorBars::GetFrame 7
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 5 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006020
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 6
ColorBars::GetFrame 8

[pinterf]

New dev build
Avisynth Plus r2380-dev (http://www.mediafire.com/file/6pyic6yoto80vtq/avsplus-r2380.7z)

20170111 r2380

Overlay: Modes "Blend", "Luma" and "Chroma" now support all bit depths and 444 conversionless (use444=false) mode
Overlay: fix SSE2 Blend for mask+opacity for 10-16 bits
VfW: (vdubmod14 VfW test)
Fix: YUV444P16 or YUVA444P16 to fourcc Y416
if alpha channel is present, it will we copied, else filled with FFFF
Fix: VDubPlanarHack is checked only for 8 bit YUV planar sources


Now practically all color formats can be shown in vdubmod. If a specific bitdepth does not exist, it will be converted on-the-fly, and some alternative output formats can be hinted with OPT_xxx variables.
For details see readme.

(I'd like to separate github releases from these 'daily' builds. Albeit this version is quite usable, there were huge refactorizations and earthquake e.g. in Overlay, so I'd like to wait a bit more)

[LigH]

Question: why are there two versions of RGB, planar and packed? Does the user really have to know/care which one is used?

The "user" may not care. But a programmer has to. Planar formats have an important advantage to process video filters fast, but it is completely different to the way the video memory stores pixels displayed on screen.

Planar RGB (components can be kept in separate memory blocks, the same pixel will have the same offset in all components, needs to be calculated only once per pixel):
RRRR...RRRR

GGGG...GGGG

BBBB...BBBB

Packed RGB24 (please notice that memory addresses aligned to 32-bit structures = DWORD are addressed most efficiently in 32-bit systems):
(R,G,B)(R
G,B)(R,G
B)(R,G,B)
...

Packed RGB32 (to align pixels with 32-bit addresses, a fourth byte is inserted which may contain an alpha value – or be ignored, which wastes RAM):
(R,G,B,A)
(R,G,B,A)
(R,G,B,A)
...

[TheFluff]

VS only supports packed RGB for backwards compatibility with Avisynth and for output. Internally in a filtering framework there is no reason whatsoever to ever use packed. Just unpack on input and pack on output if you have to - my gut feeling says that for any but the most trivial filters that's going to be insignificantly slower than filtering packed (and you can drop a dumb extra code path too). There are most likely no particularly useful or interesting RGB only filters anyway, so breaking things shouldn't be a big deal.

[ajp_anton]

But what is the point then in using packed in Avisynth, which is about processing video, not displaying it? If the input serves packed, then immediately "unpack" it. And pack it again for the output if needed.
Is there any reason for the user to ever convert to packed RGB? And if there are rare cases, why not just have one type of planar "ConvertToRGB24" (/32/48/64) function, and require "packed=true" for packed? It's easier to remember from previous experience that RGB48 is 16-bit per component RGB without alpha, than remembering whatever the name of the planar versions are (tried to google them for this post, but didn't find them fast enough). Having everything the same type (planar?) makes things easier for the user.

[LigH]

Many VfW compatible tools don't support planar RGB. They can't handle it. It was not supported by Microsoft in a blank installation of most Windows versions (I am not even sure if there are any supporting VfW codecs as of today). I would even believe, if the semi-pro home users did not insist in it, hardly any professional software company would have cared about it... So, for ancient compatibility's sake, AviSynth still must be able to output packed RGB. The most compatible way of displaying images in Windows, DIB = "Device Independent Bitmaps", was invented with packed-pixel RGB and palette formats only, AFAIK. Planar RGB is a rather recent invention, I believe...

YUV based formats are useful for real-life content, whereas RGB based formats are common for computer generated content. Just imagine screen recordings of a game or an application's user interface. Recording that in a YUV based format, especially with the most common 4:2:0 chroma subsampling and TV range, would limit the color saturation and chrominance resolution, blurring and fading 1-pixel wide colored lines.

[wonkey_monkey]

If the input serves packed, then immediately "unpack" it. And pack it again for the output if needed.

That's needlessly wasteful.

Packed RGB(A) has its advantages. Want to copy a whole pixel? With packed RGB32, that's two instructions. With planar, it's several more.

[Myrsloik]

That's needlessly wasteful.

Packed RGB(A) has its advantages. Want to copy a whole pixel? With packed RGB32, that's two instructions. With planar, it's several more.

TRIGGER WARNING

I don't care about ancient cpus. Take that!

This thread is now painful to read. Truly painful. I wish I could quote all the stupid assumptions but the most recent example will have to do.

1. The unpack-process-pack method is effectively no more expensive than keeping pixels packed. This is because you generally have to copy memory into a frame in source filters and there's a memcpy at the VfW side too. Ha!

2. To whoever said something about DIB. It's irrelevant because they only go up to rgb32. Doesn't say what everything else should be. Also asking what the early 90s at best thought was a good idea IS NOT A GOOD IDEA.

3. About using the most common input format as the processing format: b64a is the most common rgb64 format. It's BIG STINKING ENDIAN AND YOU DON'T WANT TO GO THERE ON A LITTLE ENDIAN CPU.

4. Individual examples about the pros and cons of different pixel layouts. You know what? (you obviously don't since you post them) IT DEPENDS ON THE ALGORITHM THE INDIVIDUAL FILTERS USE.

5. Planar is still your friend even if there are no direct performance gains. This is because of code sharing between yuv and rgb paths in filters.

6. If you allow unchanged planes to be passed through (as VS does) you'll save a lot of memcpy.

7. Read and write sizes don't matter much as long as they're 16 bits or more. For simple 8 bit filters sse2 can speed things up a lot just by combining loads and stores. With multiple threads and a simple 16 bit filter you'll usually become ram bandwidth limited even without simd.

(EN)CODING TRUTH

[wonkey_monkey]

triggered warning

ftfy.

[LigH]

Regarding 2.: I don't say DIB compatibility is a "good" idea. I only say some people still use "legacy" software which doesn't know it better than that. And if packed RGB would be removed from AviSynth(+), then you could probably not use AviSynth(+) anymore in conjunction with such tools or plugins.

The questions were:

a) Why are there both worlds? – Legacy, compatibility, and different advantages for different kinds of use.

b) Should AviSynth(+) get rid of one? – Only if compatibility with legacy software doesn't matter.

[jpsdr]

@pinterf
In the process of avs+ upgrade/improvements, i suggest the following to fill the missing gaps.
It would work the way the new bitdepth functions works : "Do nothing" or return a default value if we are on standard avisynth.

It should be nice to add these missing metadata :
Range mode, result would be : NONE, FULL_RANGE, LIMITED_Y, LIMITED_C.
Two limited modes, because a grey plane can be either a true greyscale plane, or an extract of an RGB plane, or an extract of a YUV plane, in that case it can be a chroma plane.
For YUV mode, LIMITED_Y or LIMITED_C would be the same thing, but i propose the used of LIMITED_Y by default.
Color mode, result would be : NONE, REC601, etc...
MPEG mode, result would be : NONE, MPEG-1, MPEG-2.
Frame mode, result would be : NONE, PROGRESSIVE,INTERLACED.

Several way to handle them.
A function wich return the status, with NONE returned on not avs+.
A function which manualy set it, "doing nothing" on not avs+.
And the last, the "automatic" way.
The default value, when a clip is created, would be the default value used in functions specifying them.
For exemple, a ConvertYV16 has a default color matrix value, this is this default value which will be used when a clip is created.
Same for all the others tags.
When a function with one or more of these parameters exist is used, the behavior would be the following :
- If the meta data is not NONE, and the parameter is not specified, the value used is the one of the meta data.
- If the meta data is NONE, the meta data get the value of the default value of the parameter if it's not specified.
- If the parameter is specified, the metadata get the value of the parameter.
Some metadata are kept even if the format don't need it.
For exemple, an YUV clip converted to RGB, would it be directly converted, or would it be converted and result put in a different clip, the resulting RGB clip will keep the Color mode. Because this same color mode will be used if converted back to YUV without the color matrix specified in the called function.
Some metadata will be automaticaly changed according what is done, unless a parameter in the function specify it.
For exemple, an YUV clip converted to RGB will have the range parameter changed from LIMITED_x to FULL_RANGE. On the other way, an RGB clip converted to YUV will have the parameter changed from FULL_RANGE to LIMITED_Y (unless parameter specification, of course).
RGB will allways be FULL_RANGE, because it's RGB we're working with, not R'G'B'.
Extracted plane would have the parameter set accordingly.
En extracted plane from RGB or from YUV set to FULL_RANGE will be FULL_RANGE. Y or U/V plane extracted to LIMITED_x will be set accordingly.

Well, i think you see the picture.
What do you think ?
I personnaly think these metadata realy should be present, and adding them is within the actual avs+ improvement way.

[LigH]

slightly confused

Does pinterf also develop the legacy AviSynth? If not, he won't be able to implement any features there. Then your requested features will only exist in AviSynth+ at all.

MPEG mode: What does this mean? AviSynth(+) only handles uncompressed video frames. Do you refer to chroma subsampling locations?

[pinterf]

This is what I found.

VideoInfo struct, defined in Avisynth.h has an image_type property.
It is a bitmap, we have 32 bits for storing video related properties.
This is where BFF, TFF, and FIELDBASED info is stored.

Single bit properties can be checked with VideoInfo::Is(property) function.

Checking for the few existing properties are directly implemented
VideoInfo::IsFieldBased()
VideoInfo::IsBFF()
VideoInfo::IsTFF()

VideoInfo::SetFieldBased(bool fieldbased) is a shortcut for set/clear FIELDBASED flag, something like this:
void VideoInfo::SetFieldBased(bool isfieldbased) { if (isfieldbased) image_type|=IT_FIELDBASED; else image_type&=~IT_FIELDBASED; }

One can set and clear a bit property as:
VideoInfo::Set(property) and VideoInfo::Clear(property)

In avisynth.h these are defined:
// Imagetype properties

int image_type;

enum {
IT_BFF = 1<<0,
IT_TFF = 1<<1,
IT_FIELDBASED = 1<<2
};


Then there are some other defines, that are nowhere used. At least not inside avisynth plus.

Based on the CS_xxx naming, maybe these were originally intented to appear in the pixel_type. But as VideoInfo:: pixel_type is directly used for checking/setting the video format, using these chroma placement bits in pixel_type would break plugins and avisynth itself.


// Chroma placement bits 20 -> 23 ::FIXME:: Really want a Class to support this
enum {
CS_UNKNOWN_CHROMA_PLACEMENT = 0 << 20,
CS_MPEG1_CHROMA_PLACEMENT = 1 << 20,
CS_MPEG2_CHROMA_PLACEMENT = 2 << 20,
CS_YUY2_CHROMA_PLACEMENT = 3 << 20,
CS_TOPLEFT_CHROMA_PLACEMENT = 4 << 20
};

[pinterf]

slightly confused

Does pinterf also develop the legacy AviSynth? If not, he won't be able to implement any features there. Then your requested features will only exist in AviSynth+ at all.


In avisynth.h there are a couple of VideoInfo:: functions that smartly fallback to return a default value when the relevant function does not exist in avisynth linkage.

Thus using this avisynth.h in your plugin development you can use the new functions (VideoInfo::BitsPerComponent(), etc...) and it won't crash when your plugin is used with classic avisynth or pre-high bit depth avisynth plus. You needn't distinct whether your target audience uses newer avisynth plus or classic avisynth.

Possibly specialized image_type getter and setter functions could work in such a way, but one could use the all-compatible VideoInfo::Set and Clear

[Groucho2004]

Can someone help me the filter fft3dGPU crashed if I use SetFilterMTMode("FFT3dGPU", 3)
Apart from instability/crashing, running fft3dgpu multi-threaded is pointless. The speed does not increase and the GPU memory consumption goes through the roof.

I suggest you use FFT3DFilter from here (https://forum.doom9.org/showthread.php?t=173229). Multi-threaded, it will be faster than fft3dgpu.

[jpsdr]

Do you refer to chroma subsampling locations?
Yes, and it seems that some features allready exist, this one seems to be already included.