Avisynth+

[LigH]

Oh, that one is quite old (2015).

Of course, "loading plugins" is not the same as "importing scripts". Still, some automation would be appreciated here.

[pinterf]

Yes, the autoload issue is registered but not fixed yet.

[bxyhxyh]

Hello
I'm stabilizing shaky video with deshaker.
Converting it to 16-bit so I could reduce rounding errors.
Like this

Function YV12toRGB32(clip c)
{
c.convertTo16bit()
converttorgb64(matrix="Rec709")
convertto8bit()
}

Function RGB32toYV24(clip c)
{
c.ConvertTo16bit()
ConvertToYUV444(matrix="Rec709")
convertto8bit()
}

s = source()
s.yv12torgb32().dehsaker().RGB32toYV24()


I noticed bit difference on brightness.
It was clear it's caused by color convertion.
So I just typed
s.yv12torgb32().RGB32toYV24().yv12torgb32().RGB32toYV24().yv12torgb32().RGB32toYV24().yv12torgb32().RGB32toYV24()
Then this is the result
source - https://i.imgur.com/V3aioqT.png
converted - https://i.imgur.com/kddpb3i.png
Is it a bug or something? (Pictures are resized since it doesn't matter for what we're talking anyway.)

[raffriff42]

Then this is the result ...is it a bug or something?It does look like a bug. The problem seems to be in ConvertTo8bit; its output is aprox. 1 step darker after each pass, probably a rounding issue. Using dither seems to fix it:Function YV12toRGB32(clip c)
{
c.convertTo16bit()
converttorgb64(matrix="Rec709")
convertto8bit(dither=0)
}

Function RGB32toYV24(clip c)
{
c.ConvertTo16bit()
ConvertToYUV444(matrix="Rec709")
convertto8bit(dither=0)
}
however this does add a dither pattern, invisible in normal footage but apparent in Colorbars etc. Adding a fixed offset also seems to work:Function YV12toRGB32(clip c)
{
c.convertTo16bit()
converttorgb64(matrix="Rec709")
RGBAdjust(rb=127, gb=127, bb=127)
convertto8bit()
}

Function RGB32toYV24(clip c)
{
c.ConvertTo16bit()
RGBAdjust(rb=127, gb=127, bb=127)
ConvertToYUV444(matrix="Rec709")
convertto8bit()
}
Offset set to 127 because 0.5 (8bit) ≈ 127 (16bit).

[bxyhxyh]

Ah, so this might be also yet another "256 or 257" thing.

[Weirdo]

Probably trivial but can't find the workaround. My little script gives There is no function named 'SetMTMode' (line 3), while it works with the older Avisynth 2.6 MT (https://forum.doom9.org/showthread.php?t=148782) from SEt. Using Avisynth+ r2508, QTGMC 3.357s with its updated plugins, W10 x64. Thanks for any tips.

global MeGUI_darx = 143
global MeGUI_dary = 80
SetMTMode(5, 4)
SetMemoryMax(1000)
LoadPlugin("F:\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("G:\source.d2v")
SetMTMode(2)
QTGMC( Preset="Slow", EdiThreads=2 )
Distributor()
crop(14, 4, -10, -4)

[Reel.Deel]

Probably trivial but can't find the workaround. My little script gives There is no function named 'SetMTMode' (line 3), while it works with the older Avisynth 2.6 MT (https://forum.doom9.org/showthread.php?t=148782) from SEt. Using Avisynth+ r2508, QTGMC 3.357s with its updated plugins, W10 x64. Thanks for any tips.


Multi-threading syntax in AviSynth+ is different, see wiki pages for more information: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes

[LigH]

There is indeed no function named "SetMTMode" in AviSynth+.

See AviSynth Wiki: AviSynth+ – 4. MT notes (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes)

Furthermore, use Distributor() only when you are really sure you know why. If not, it may multiply threads unexpectedly.

[Weirdo]

Thank you both, I made the corrections and it works fine.

[wonkey_monkey]

Can someone give me a dumbed-down summary of the different MT modes? I've read this:

http://avisynth.nl/index.php/AviSynth%2B#Guidelines_on_choosing_the_correct_MT_mode

But it's not very clear to me. It doesn't really state how the modes work, and especially the bit for MT_NICE_FILTER isn't clear at all on when it should be used, instead focusing on when it shouldn't.

I'm guessing that MT_NICE_FILTER requests multiple frames in multiple threads, but only one instance of the filter, and that MT_MULTI_INSTANCE makes multiple instances, so it's a bit like calling the same plugin multiple times on trimmed/selecteveryed subclips and then joining or interleaving them? Or does it crop frames up into smaller frames then stack them back together, or something? (probably not) And that MT_SERIALIZED is the same as plain old single-threaded AviSynth?

[Reel.Deel]

@davidhorman

See here for more info. http://avisynth.nl/index.php/Avisynthplus/Developers

There's a few post in this thread with a bit more info, unfortunately I'm away from my home computer ATM.

[wonkey_monkey]

I've read that, but I'm still none-the-wiser as to what actually happens. I am 99% sure my current filter can never be MT-friendly, at least...

[MysteryX]

I'm guessing that MT_NICE_FILTER requests multiple frames in multiple threads, but only one instance of the filter, and that MT_MULTI_INSTANCE makes multiple instances, so it's a bit like calling the same plugin multiple times on trimmed/selecteveryed subclips and then joining or interleaving them? Or does it crop frames up into smaller frames then stack them back together, or something? (probably not) And that MT_SERIALIZED is the same as plain old single-threaded AviSynth?
Yes, if you're using Prefetch(8), MT_NICE_FILTER has 1 instance and 8 threads calling that one instance. That means the code must be thread-safe and you can't have class-level writable variables and buffers. Any work buffer must be initiated and destroyed within each GetFrame call.

MT_MULTI_INSTANCE creates 8 instances, and I'm not sure the thread creating the class is always the same as the thread calling GetFrame, in fact I think it can be any thread but always only 1 call at once.

MT_SERIALIZED, it will have 1 instance and only 1 call at once. However, there is currently a bug in the latest AVS+ where it can actually receive 2 calls at once in certain cases. Pinterf is working on fixing that, but for now, MT_SERIALIZED is broken.

[wonkey_monkey]

but for now, MT_SERIALIZED is broken.

Which is the only one my filter can work under. Oh well! It's working for now on whatever version of AVS+ I'm using.

[pinterf]

MT_SERIALIZED, it will have 1 instance and only 1 call at once. However, there is currently a bug in the latest AVS+ where it can actually receive 2 calls at once in certain cases. Pinterf is working on fixing that, but for now, MT_SERIALIZED is broken.
It's not broken, fixed since r2502

20170602 r2502
- fix: (Important!) MT_SERIALIZED mode did not always protect filters (regression since r2069)
Such filters sometimes were called in a reentrant way (like being MT_NICE_FILTER), which
possibly resulted in using their internal buffers parallel.
[...]

[pinterf]

It does look like a bug. The problem seems to be in ConvertTo8bit; its output is aprox. 1 step darker after each pass, probably a rounding issue.
While YUV 8<->16 conversion is a simple bit-shift, RGB conversion is full-scale, e.g. 8->16 bit conversion is something like x*65535/255. 255 becomes 65535. Similarly for 16->8 bits the formula is x*255/65535. Anyway, I'll check it (Sorry, I still have limited time for a couple of weeks).

Remark: do not worry about rounding errors in 8 bit conversions and in 8 bit filters in general. Most of the 8 bit functions work internally with 13-15 bits precision (like in classic Avisynth)

[bxyhxyh]

While YUV 8<->16 conversion is a simple bit-shift, RGB conversion is full-scale, e.g. 8->16 bit conversion is something like x*65535/255. 255 becomes 65535. Similarly for 16->8 bits the formula is x*255/65535. Anyway, I'll check it (Sorry, I still have limited time for a couple of weeks).
Is it bit-shifting or that (something like x*65535/255) arithmetic formula?
Bit shifting wouldn't work correct since 255 bit-shifted is not 65535.
But in avisynth they are equal white.

I'm pretty sure you know it, just pointing to it.

[wonkey_monkey]

Is it bit-shifting or that (something like x*65535/255) arithmetic formula?

You can bitshift, and then OR in the original bits as well. It would be equivalent to the arithmetic formula (since 65535/255 = 257).

(x << 8) | x

Where does the convention that only a bitshift is used for YUV come from?

[TheFluff]

Can someone give me a dumbed-down summary of the different MT modes? I've read this:

http://avisynth.nl/index.php/AviSynth%2B#Guidelines_on_choosing_the_correct_MT_mode

But it's not very clear to me. It doesn't really state how the modes work, and especially the bit for MT_NICE_FILTER isn't clear at all on when it should be used, instead focusing on when it shouldn't.

I'm guessing that MT_NICE_FILTER requests multiple frames in multiple threads, but only one instance of the filter, and that MT_MULTI_INSTANCE makes multiple instances, so it's a bit like calling the same plugin multiple times on trimmed/selecteveryed subclips and then joining or interleaving them? Or does it crop frames up into smaller frames then stack them back together, or something? (probably not) And that MT_SERIALIZED is the same as plain old single-threaded AviSynth?

I wrote this (https://forum.doom9.org/showthread.php?t=174437) a while ago. May or may not help.

The tl;dr is that as a rule of thumb:

if your filter's GetFrame is threadsafe (basically, does not attempt to write to any memory that is not explicitly associated with this specific frame request) => MT_NICE_FILTER
if your GetFrame does depend on shared state of some kind, but your filter supports things like interleave(yourfilter().selecteven(), yourfilter().selectodd()) in vanilla Avisynth => MT_MULTI_INSTANCE
if you are a source filter, or rely on frame request order (i.e. stuff with side effects outside Avisynth such as writing to a file), or rely on internal state that changes with every frame request (i.e. pattern-tracking decimation filters) => MT_SERIALIZED


It also may or may not be relevant to note that all GetFrame calls that need to happen to produce a given output frame at the end of the script happen in the same single thread, regardless of what MT modes are in use. You probably shouldn't rely on this for anything, though.

[wonkey_monkey]

Thanks TheFluff - that helps. I'm certain my filter will never be able to be MT'd. It's internally multi-threaded though.

[Myrsloik]

Is the avs+ api stable now? I really don't want to waste time adding compatibility for it if I'm going to have to change things later.

[pinterf]

I'm not planning to change it.

[real.finder]

I'm not planning to change it.

what about add support for vs api in avs+ to load vs plugins (dll) in avs+?

We discussed this in irc years ago and Myrsloik said it's possible

[pinterf]

Short developer news, I hope I'll have less busy months from now (finished a marathon with 2:55, this year I was preparing on this race instead of coding)

- "Levels" now allows 32 bit float inputs
- today I have successfully ported Expr (http://www.vapoursynth.com/doc/functions/expr.html) filter from the VapourSynth project, with some additions (masktools syntax of built-in constants and some of the scaling helper functions).

[pinterf]

what about add support for vs api in avs+ to load vs plugins (dll) in avs+?

We discussed this in irc years ago and Myrsloik said it's possible
If he says it's possible then it's the question of someone's time :) isn't it? Not planning in the near future either, to tell the truth I cannot imagine the magnitude of the effort at the moment.

[real.finder]

Short developer news, I hope I'll have less busy months from now (finished a marathon with 2:55, this year I was preparing on this race instead of coding)

- "Levels" now allows 32 bit float inputs
- today I have successfully ported Expr (http://www.vapoursynth.com/doc/functions/expr.html) filter from the VapourSynth project, with some additions (masktools syntax of built-in constants and some of the scaling helper functions).

good news :)

Expr will be part of internal avs+ functions?

[pinterf]

good news :)

Expr will be part of internal avs+ functions?
Yes, it was more convenient and faster for me than putting it in a separate dll (masktools).

[MysteryX]

and Expr really has nothing to do with masks, it's more of a core feature

[Myrsloik]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.

And speaking of formats... are only formats with a pre-combined constant allowed or can I have some 16bit yuv with insanely high subsampling?

Btw, do any filters have meaningful planar YUVA or RGBA support or can I skip implementing it properly for now?

Oh, and is the threadpool and jobcompletion stuff actually documented somewhere?

[ChaosKing]

Maybe AVSMeter (src included) can help you for the detection part: https://forum.doom9.org/showthread.php?t=174797

[Groucho2004]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.I'm not aware of any way to extract that information. For a compiled plugin DLL you can query the type and the version (C 2.0, C 2.5, CPP 2.0, CPP 2.5, CPP 2.6) by checking the DLL exports but that's about it.

[TheFluff]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.

Is that actually strictly necessary in practice? Most plugins tend to check for the colorspaces they can handle in the constructor, and I think the colorspace checking functions in 2.6 won't misdetect new stuff as something old, although 2.5 plugins will pretty much think everything is YV12 AFAIK.

[Myrsloik]

Is that actually strictly necessary in practice? Most plugins tend to check for the colorspaces they can handle in the constructor, and I think the colorspace checking functions in 2.6 won't misdetect new stuff as something old, although 2.5 plugins will pretty much think everything is YV12 AFAIK.

I don't trust plugin code to handle it properly. Never trust plugins.

[pinterf]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.
Avs+ filters can only provide a hint about their MT modes when avisynth core requests for it, by returning the proper mt enum on the CACHE_GET_MTMODE poll. So they do not actively set multithreading modes.
int __stdcall SetCacheHints(int cachehints, int frame_range) override {
return cachehints == CACHE_GET_MTMODE ? MT_NICE_FILTER : 0;
}


And speaking of formats... are only formats with a pre-combined constant allowed or can I have some 16bit yuv with insanely high subsampling?
Only those pre-combined constants are allowed. NewVideoFrame explicitly checks against them (Btw., that was the reason when I was starting to mod 8-bit only avs+, because NewVideoFrame did not allow me to create a video frame with arbitrary set bit-mask flags. Nor allows arbitrary flags today but the list of the preset video format was hugely expanded wiht 10+bit and planar-with-alpha constants)

Btw, do any filters have meaningful planar YUVA or RGBA support or can I skip implementing it properly for now?Masktools, Rgtools accepts planar formats with alpha. But you asked meaningful, I suppose you mean when a filter is using the clip's alpha channel for mask operation for example. I'm not aware such filter.

Oh, and is the threadpool and jobcompletion stuff actually documented somewhere?
No. Nor have I studied that part of avs+ in deep. I don't know whether ultim treated them as a finalized chapter in avs+ development, but since he left the scene, we'll never know.

[jpsdr]

Oh, and is the threadpool and jobcompletion stuff actually documented somewhere?

Probably the most important documentation you can find is here (http://forum.doom9.org/showpost.php?p=1778346&postcount=53).

[Myrsloik]

Probably the most important documentation you can find is here (http://forum.doom9.org/showpost.php?p=1778346&postcount=53).

Interesting, with that description I could actually implement it if an interesting plugin using it is found.

[jpsdr]

Personnaly i don't because i don't want my plugins be "avs+ only", and unfortunately i don't think any plugin is using it actualy.

[sausuke]

can I ask why the thread count of avisynth+ is always at 37? I don't use MT in the script and on avs meter why my CPU usage is only 2%? I used avisynth MT too and the CPU usage is only 8% max>

script:
AVISource("E:\2Encoded Files\klsdjfjklfdsakjlfdsa.avi", audio=false).AssumeFPS(60000,1001)
ConvertToYV12(matrix="PC.709")


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

I'm frameserving from Sony Vegas 15. It uses all the cores 99% with no speed benefit (with MT when using MEGUI). I even used the ultrafast preset on x264 same 49fps. Is this a bug?

PS: when I used Prefetch(4) the thread count goes to 41

[tuanden0]

@sausuke:
I think they not yet optimize for your CPU. Almost people using AMD Ryzen TR have same issue with you.

[sausuke]

@sausuke:
I think they not yet optimize for your CPU. Almost people using AMD Ryzen TR have same issue with you.

yeah same with Avisynth MT, when I used high threads on SetMTMode the speed is faster but sometimes the video jitters randomly on the first seconds. Some encodes are not. Still testing...

[Groucho2004]

can I ask why the thread count of avisynth+ is always at 37?
It's not always 37 threads, just in your specific scenario.


I don't use MT in the script and on avs meter why my CPU usage is only 2%? I used avisynth MT too and the CPU usage is only 8% max>
I think that Vegas simply doesn't serve frames to Avisynth fast enough and therefore creating a bottleneck. That also explains the low CPU usage.

[sausuke]

It's not always 37 threads, just in your specific scenario.


I think that Vegas simply doesn't serve frames to Avisynth fast enough and therefore creating a bottleneck. That also explains the low CPU usage.

the video preview on sony vegas is so fast though even the video realtime in frameserver (100%+) when using avsmeter (100-150fps) using other scripts and avisynth.

the thing is all the avisynth I used (MT,avs+MT) I need to push the Queue button on MEGUI many times (1x to 3x) to get a fast FPS, when I pushed it and the video is slow they have the same cpu usage too, so I abort again and push then pray that it will be fast (40fps=slow 75fps=fast)

here's the screenshot using this script with avsmeter:

script:

SetMemoryMax(1536)
SetMTMode(5,4)
AVISource("E:\2Encoded Files\kljsdfkjlfdskjlfds.avi", audio=false).AssumeFPS(60000,1001)
SetMTMode(2,4)
ConvertToYV12(matrix="PC.709")
return last



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

same scenario on avsmeter, in that screenshot that is the fastest, I first drag the script and it only have 50fps so I close avsmeter and drag again then that's the fastest (I always look on Vegas Preview too and the frameserver percentage). Dunno if it's the architecture of the threadripper though first time experiencing this.

EDIT:

here's what I'm saying

Slow: 30+ FPS

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

Fast: 70+ FPS (too lazy to wait) xD

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

That's the two scenario when I want to encode either get the 30fps one or the 70fps one. When using the normal avisynth always 40fps

PS: Look also the jobs, 11 to 13 hence I aborted in Job 12 'cause I get the same slow fps and get the fast FPS in Job 13

[Yanak]

What is the pixel format for the ouput , 8bits or 32bits floating ?
Also if not already done disable the preview rendering in vegas before frameserving, this make it run like a turtle when frameserving.

I don't have this CPU ( 3770k@4Ghz here) but I frameserve from vegas14 my output file directly to a 4GB Ramdisk , vegas temp folder is also set on the Ramdrive. On AVSmeter I usually get around 10-12% CPU usage for 1080p60fps footage and 20-25% CPU usage for 720p30FPS footage with average 250frames output according to avsmeter.

When i have the possibility, when it's not too big i put my source video on the Ramdisk too and work from there on vegas and also output to the ramdrive the frameseved and avisynth created files, wish i had more RAM to make bigger ramdisk tho.

Edit: took me time to answer with window opened, just seen the previous post after i sent mine.

[sausuke]

What is the pixel format for the ouput , 8bits or 32bits floating ?
Also if not already done disable the preview rendering in vegas before frameserving, this make it run like a turtle when frameserving.

I don't have this CPU ( 3770k@4Ghz here) but I frameserve from vegas14 my output file directly to a 4BG Ramdisk , vegas temp folder is also set on the Ramdrive. On AVSmeter I usually get around 10-12% CPU usage for 1080p60fps footage and 20-25% CPU usage for 720p30FPS footage with average 250frames output according to avsmeter.

When i have the possibility, when it's not too big i put my source video on the Ramdisk too and work from there on vegas and also output to the ramdrive the frameseved and avisynth created files, wish i had more RAM to make bigger ramdisk tho.

Edit: took me time to answer with window opened, just seen the previous post after i sent mine.

8bits only, afaik the encoding suffers when I do 32bit floating in sony vegas. (same when I'm using my i7-5960x) so I always use 8bits.

Gonna test that preview rendering thank you

EDIT:

Same even the preview rendering is disabled. It goes slow or fast fps when encoding.

[Yanak]

I don't know what is the bottleneck for you, preview screw up my speed on my system :/

Made a quick test and using aviynth x64 that is not compatible with the frame-server output format from debugmodeserver but under MP_Pipeline and a win32
process inside it i got this for the cpu usage:
https://s14.postimg.org/ky6r5akc1/34575520171026142337.png

Was a short 1080p video, stored on the ramdisk and debugmodeframserver was outputting it at 211% speed into avisynth.

Like Groucho said i think the problem is not avisynth itself, or not totally at least, maybe the HDD speed vs me using a Ramdisk mostly, or some vegas performances parameters maybe, hard to say more on this.

Edit : forgot i had megui installed on my machine, using only Staxrip since a while, but made a test in native x86 with it :

https://s14.postimg.org/4zy1f5xtt/81718320171026194158.png
Output from frameserver was 230 to 238% ...

[sausuke]

hmm I've tried a normal avi and the normal speed is 400fps (not frame serving) but I've tried my nvenc codec recordings and it will not have preview on megui so I can't test (megui crashing). Maybe the nvenc codec is the bottleneck problem? I can't try the avi on sony vegas 'cause it can't accept now which is weird.

EDIT:

oh my it seems the nvenc codec (in MP4) is the bottleneck, I run a test using avi file and it's so fast in sony vegas (frameserver/avisynth+without mt), the problem is now I will use AVI on my recordings on bandicam though (have problems in sounds)

will test the other option though

EDIT:

Finally solved it, it seems the source is the culprit all along (should have read the bandicam faq) I've been using H264 on the settings all these years and not X264 in FourCC code options. Thank you guys for the comments, Groucho2004 for avsmeter (helps alot), Yanak (got the idea of using other source because of your screenshots) xD

EDIT:

Can I ask if avsmeter preset is the ultrafast of x264 which why is it fast? thank you

[Groucho2004]

Can I ask if avsmeter preset is the ultrafast of x264 which why is it fast? thank youAVSMeter simply reads the frames from your script, there's no encoding involved. It measures how fast Avisynth can serve frames to your encoder (x264).

[sausuke]

AVSMeter simply reads the frames from your script, there's no encoding involved. It measures how fast Avisynth can serve frames to your encoder (x264).

now I understand, hmm the problem appears again but not as bad, the script on avs meter is fast now

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

now it's either the Sony vegas or my computer, dunno if my it's my ram or my overclock, the speed is random when encoding (more on fast now) I always check avsmeter it's always on that speed so I already have fast frameserver.

what did I do:

Increased Sony vegas 15 threads to 48 (already tried only 1 and the encoding slows down)

I've already done the ramdisk and the slow fps does happen too so I think I don't have bottleneck on my HDD, I checked the taskmanager too

Gonna reset all the parameters on BIOS if it will help

EDIT:

Alright I finally know what the cause, 100% fix. This is all about the ram. I thought my 1 of my 4 ram is busted (can't boot with XMP on) so I've removed it then my computer runs in triple channel (2666Mhz XMP On). Yesterday I'm googling about threadripper performance problem and it said that low speed and not quad channel ram causes performance decrease up to 50% and infinity fabric relies on faster ram speed. So I put again my 1 8gb ram (for quadchannel again), overclock all my 32gb to 3000Mhz and it boots. I test it on all my .veg files with MEGUI and wallahh: always fast encoding, no more abort and pray to be faster.

It seems the ram speed needed to communicate to the processor, I have feeling about this though cause why sometimes it only uses the other half of the die

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

Hope this will help who gonna buy Ryzen or Threadrippers, buy high speed rams or overclock it (if you want to save money with previous ram). Didn't know this can affect the CPU performance that match in AMD (first time using AMD) haven't research much about this I always thought it's the same with intel, all about CPU not affecting by ram specification

[TheFluff]

Continuing the discussion from here (https://forum.doom9.org/showthread.php?p=1823329#post1823329), let's talk about those nasty memory offsets again.

In avisynth.h from 2.6:
size_t (VideoFrameBuffer::*GetDataSize)() const;
size_t (VideoFrame::*GetOffset)(int plane) const;
class VideoFrameBuffer {
BYTE* const data;
const size_t data_size;
(...)
protected:
VideoFrameBuffer(size_t size);
(...)
public:
size_t GetDataSize() const AVS_BakedCode( return AVS_LinkCall(GetDataSize)() )

class VideoFrame {
(...)
const size_t offset;
const int pitch, row_size, height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
(...)
VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height);
VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height,
size_t _offsetU, size_t _offsetV, int _pitchUV, int _row_sizeUV, int _heightUV);

void* operator new(size_t size);

// generally you shouldn't use these three
(...)
size_t GetOffset(int plane=0) const AVS_BakedCode( return AVS_LinkCall(GetOffset)(plane) )

In Avs+ all these size_t's are (32-bit signed) int instead. In Avisynth it doesn't really matter in practice because a frame is always allocated as one big chunk of memory, and nobody really has any use for more than 2^31 bytes of vfb. If you ever wanted to stop doing this though and use one individual pointer per plane like VS does, this won't fly because you can't reliably stuff a 64-bit pointer in a 32-bit integer, and it's generally bad coding practice to not use size_t (or ptrdiff_t) for these things.

Way back in the day ultim claimed that he didn't want to follow IanB's lead and switch to size_t because it'd break a number of completely irrelevant plugins (that would have been trivial to recompile). I didn't realize it at the time, but I'm pretty sure that in practice, he was wrong even on the technical aspect. If you look at these functions above, the only one that conceivably might end up getting called by plugins in reality is VideoFrame::GetOffset(), and I'm 99% sure that its return value just gets passed in a register and zero-extended, so as long as you keep passing the same old less-than-2^31 offsets, everything will keep working just fine (but most plugins just use GetRead/WritePtr). New VideoFrames and VFB's are only constructed by env->NewVideoFrame, so changing the signature of the VideoFrame constructor shouldn't be an issue.

[enctac]

r2508 RGB->Y8 [incorrect]
r2508 RGB->YV24->Y8 [correct]
2.6MT RGB->Y8 [correct]

OS: Win10 CU
CPU：i7-4702MQ(Haswell)


function LumaBlock(int n){
return BlankClip(width=60,height=400,pixel_type="RGB32",color=n*(65536+256+1)).Subtitle(String(n),align=2).KillAudio()
}

StackHorizontal( LumaBlock(0), LumaBlock(8), LumaBlock(16), LumaBlock(32), LumaBlock(64), LumaBlock(96), LumaBlock(128), \
LumaBlock(160), LumaBlock(192), LumaBlock(224), LumaBlock(235), LumaBlock(245), LumaBlock(255) )

# Avisynth+ r2508 needs ConvertToYV24()
# ConvertToYV24()

ConvertToY8()
Subtitle(VersionString,align=9)

# Show Histogram
ConvertToYV24()
Histogram("levels")

Subtitle("r2508 RGB32------->Y8",align=7)
#Subtitle("r2508 RGB32->YV24->Y8",align=7)
#Subtitle("2.6MT RGB32------->Y8",align=7)

ConvertToRGB()