AviSynth+ thread Vol.2

[LigH]

Core filters: Overlay and mask filters: The entry for Mask links to Layer instead of Mask.

[Myrsloik]

The format support in avs+ is genuinely confusing. I tried to construct the constant for YUV440. And it doesn't error on construction. Instead it errors when creating a frame.

The relevant code is here:
https://github.com/AviSynth/AviSynth...ynth.cpp#L4377

Why have such an elaborate set of flags for subsamplings if I can't use them?

[v0lt]

Originally Posted by Myrsloik

The format support in avs+ is genuinely confusing. I tried to construct the constant for YUV440. And it doesn't error on construction. Instead it errors when creating a frame.

You can't just come up with a new format ID and hope it works.

[Myrsloik]

Originally Posted by v0lt

You can't just come up with a new format ID and hope it works.

Sure can. Just did.

[pinterf]

I'm on long holiday till July 31st w/o PC, and will continue pending tasks in August.

[qyot27]

The enums to control for color constants are basically just for being pieced together for the core's I/O, any new format needs to be explicitly defined and exported rather than made on the fly. It probably wouldn't hurt to actually provide some mechanism for that, albeit with a massive caveat utilitor attached.

That said, https://github.com/AviSynth/AviSynthPlus/pull/502

If there is some sort of problem for C++ plugins accepting what's in that PR, then sure. But it worked for libavformat being able to display the output of Version(pixel_type="YUV440") (or YUV440P10, P12).

[flossy_cake]

How much headache would it be to add namespaces to .avs scripts?

C++ supports namespaces and it looks fairly simple but I have no idea how the script parser works so it could be a nightmare for all I know.

I need namespaces for 2 reasons:

1. I use many ScriptClips all in the one .avs file, and to "see" outside of ScriptClip from within you need to use globals and gosh I have a lot of them now cause my ScriptClips uitlize many runtime frame counters, thresholds etc. that need to be read and/or modified by all ScriptClips at runtime. If I could put it all into a namespace then that avoids polluting the global namespace.

2. I can only call my main function once otherwise the second call would start overriding globals used by the previous call. With a namespace I could assign each function call a new namespace and avoid the issue.

Currently my plan to reduce my global namespace pollution is to append some random numbers or characters to the end of every one of my global names (big job) and then put some logic to disallow multiple calls.

But obviously a namespace would be much nicer.

If we take ScriptClip out of the equation, namespaces wouldn't be needed as we could just pass everything as function arguments. But actually even that might not work because there is a very conservative limit to the number of function arguments allowed by Avisynth, which I'm already brushing up against.

I had thought to maybe put all variables into 1 big array and pass that around as an argument, but that won't work either cause they can only be accessed by an integer index not a string index - you can't go globals["variable_name"]. And then if you want to modify it you can't go globals[0] = 3.14 because that's invalid you have to go globals = ArraySet(globals , 3.14, 0) which is probably slow too.

[wonkey_monkey]

I feel like I may have asked this before, but is there any way to access frame properties without having to get a PVideoFrame via GetFrame, and if not, should there be?

For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

Conceptually it seems like frame properties should exist somewhere independent of video frame pixels. Or are the two inexorably tied together for backwards compatibility?

[v0lt]

Originally Posted by flossy_cake

How much headache would it be to add namespaces to .avs scripts?

I don't want new features right now. I'm waiting for the release!

[flossy_cake]

Originally Posted by wonkey_monkey

I feel like I may have asked this before, but is there any way to access frame properties without having to get a PVideoFrame via GetFrame, and if not, should there be?

For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

Conceptually it seems like frame properties should exist somewhere independent of video frame pixels. Or are the two inexorably tied together for backwards compatibility?

I think I've asked a question like that before too but in the context of scripts, whether doing a PropGet forces a GetFrame.

The answer was yes, and I think it's by design since frame properties could be derived from the pixels, so the pixels have to be evaluated anyway.

eg. filters that write frame difference metrics, or scenechange status, or update the field order would need to evaluate the frame to calculate such properties.

But the source filter seems to be an exception to the rule, because its frame properties aren't calculated from Avisynth clip pixels, so I think you are right and it should be theoretically possible to make a special code path for source filter frame properties that doesn't require an internal GetFrame.

But I'm having trouble understanding how this could be a performance issue if you are getting the frame properties immediately after the source filter in which case you should be getting probably thousands of frames per second in a benchmark. What's your use case scenario? Are you trying to prescan the source filter's frame properties of every frame? Like, potentially hundreds of thousands of frames?

[StvG]

Originally Posted by wonkey_monkey

I feel like I may have asked this before, but is there any way to access frame properties without having to get a PVideoFrame via GetFrame, and if not, should there be?

For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

Conceptually it seems like frame properties should exist somewhere independent of video frame pixels. Or are the two inexorably tied together for backwards compatibility?

This is more related to the source filters. They know the frame type without decoding needed. So, the source filter can expose function to get only frame type without decoding / getting the pixel data.

[gispos]

Originally Posted by wonkey_monkey

...
For example: some source filters will put the frame type (I, P, B) in a frame property. It could be very useful to scan all of these when a script loads, but if it means generating every frame then then it'll take far too long.

+1
It would be wonderful to have functions for communicating directly with the source filter. Two things would be of interest: '_PictType' and '_AbsoluteTime'.

[flossy_cake]

Originally Posted by v0lt

I don't want new features right now. I'm waiting for the release!

Fair enough, maybe it's more appropriate to implement it as a standalone plugin kind of like GScript, something like this...

GScript("""

	namespace MySpace {
	
		global MyCounter = 0   # only stuff inside MySpace sees this
	
		ScriptClip(last, """
		
			global MyCounter = MyCounter+1
			return last.Text(String(MyCounter))
			
		""")

	}
	
""")

Because then we don't have to mess around with Avisynth script parser and risk breaking stuff .