PVideoFrame is a so called Safe Pointer (with auto self delete type stuff), and keeps a count of number of references to itself,
if more than a single reference, then is no longer writeable. summick like that.

EDIT: And frame not actually deleted until reference count goes to zero (ie nobody else is using it).

EDIT:

Quote:

I checked the actual value of PVideoFrame

Also, CPP can do some clever stuff, it probably massages some results that you may get from it, Operators can be overridden to do something a little different,
but the main prob is the reference count not being 1, ie not writable.

overlay doesn't seem to throw errors properly, or at least not in the usual manner. Instead of a popup error, as you get with layer when specifying bad parameters or providing unsupported colourspaces, overlay's internal errors (e.g. "Overlay: Invalid 'Mode' specified.") come up as status bar messages in VirtualDub2 instead.

Is it because they are being thrown in GetFrame instead of in the constructor?

PS Is there any reason layer and overlay couldn't be merged? They seem like they overlap quite a lot.

I would class below as a definite bug. We had something similar where Trim() was not trimming audio where source was Colorbars.

Code:

A=AVISource("D:\L&M.avi")
B=AVISource("D:\B2.avi")
F=B.trim(0,-1) # Should be single frame
A=A.Trim(18000,0)
#Return F # Returns single frame OK
StackHorizontal(A,F) # SHOULD Stack clip alongside a Fixed Single frame, but F is NOT single frame

StackHorizontal, is ignoring the trim(somehow), this must be fixed.

EDIT:

Quote:

We had something similar where Trim() was not trimming audio where source was Colorbars.

Perhaps it is the very same problem, in Trim (that problem also incorporated StackHorizontal). Not trimming properley will break scripts.

EDIT: Managed a temporary fix so that I could do as required by inserting an "F=FrameStore(F)" line before the Stackhorizontal line.

overlay doesn't seem to throw errors properly, or at least not in the usual manner. Instead of a popup error, as you get with layer when specifying bad parameters or providing unsupported colourspaces, overlay's internal errors (e.g. "Overlay: Invalid 'Mode' specified.") come up as status bar messages in VirtualDub2 instead.

Is it because they are being thrown in GetFrame instead of in the constructor?

I'll check it later this week.

Quote:

Originally Posted by wonkey_monkey

PS Is there any reason layer and overlay couldn't be merged? They seem like they overlap quite a lot.

I have finished porting Layer to support all formats and bit depths (it's on git source already, but not finished and published the whole project because the possible integration with Overlay has also come in my mind). Theoretically Overlaps and Layer can be merged - unfortunately we have to keep both - compatibility you know. They are using different set of parameters - though I already introduced 'opacity' for layer, it was needed instead of 'level' because of the consistency among different bit-depth), terminology (add-blend), and they are also using different methods for some of their similar filters (lighten-darken has an additional threshold in Layer), Layer can use a single alpha channel for masking as part or the format (RGB_A, YUV_A), Overlaps is using mask, but this can also be a luma-chroma clip.
In 'Layer' I have done proper chroma masking based on a single luma mask (now you can even choose placement as mpeg2 or mpeg1), for such task Overlay converts 4:2:0 or 4:2:2 clips to 4:4:4, and can only use a not-so-precise conversion for chroma.
So the two filters are similar but there are still differences -> lot of work.

I just tried upgrading to AviSynth+. During the installation I chose the option that would allow me to downgrade safely back to the old AviSynth I already had installed.
Immediately after the restart I tried one of my .avs scripts and found that the new installation broke my srestore(). I already posted about this on the srestore thread:: https://forum.doom9.org/showthread.p...53#post1866853.

Because I need this script to work right now, I went into "Uninstall or Change a Program" (Win8.1x64) and selected to uninstall AviSynth+.
It did so quickly, so I tried running my .avs script again and I now got this error
---------------------------
VirtualDub Error
---------------------------
AVI Import Filter error: (Unknown) (80040154)
---------------------------
OK
---------------------------

I am not yet sure how to fix this - hopefully, reinstalling the old AviSynth will help, but I just wanted to show that the current downgrade process isn't working smoothly.

Actually, I think that VS2017, and VS2015 runtimes are exactly the same (not sure, might be 2013 and 2015 same), but it would not do any harm to install both, maybe.
Groucho AVS AOI installer is real good, I'm in never ending process of installing dll's for v2.58, v2.60, avs+ x86 and x64 (partly because I'm updating my plugins to x64).
Remember to also use Groucho2004 AvsMeter to check plugins OK, and make REGULAR backups (when modding dll's) of the Videotools\AvisynthRepository\ directory.
Avs+ defo runs smoother, when sorted out, its just that it sometimes takes a while to get to the sorted out stage, especially if you've been running 2.5x up to now.

The old AVS+ from 1st post, is under control of Ultim, and he no longer visits, you aint the first to download the wrong/old version dll, think I probably did that too.

I installed VS2017 alongside VS2013 recently and the resulting compiled filters were significantly (10-20% or so) slower than VS2013. Just thought I'd mention that in passing.

Anyway, to my point, which is a modest proposal.

I'm developing a filter which necessitates the passing of, for want or a better word, metadata between clips. Traditionally non-video data has been passed around as video in special clips, like MVTools's "super" clips, but this (not necessarily what MVTools does, but other filters doing similar things) is a bit of a bodge. Of course it's necessary because Avisynth has nothing for passing around data otherwise. I believe one of the DG tools uses the low bits of the first few pixels to pass data, for example.

What I'm doing with my new filter (and what I've previously done with warp) is abusing GetAudio. If it's called with start=1 and count=3, which is extremely unlikely to ever come up in the real world, and if the passed buffer starts with a special integer, then my code takes over and instead of filling the buffer with audio, it fills it with whatever information the child filter (backwards terminology from Avisynth's, don't get me started on that one) has requested by way of other data in the passed buffer.

By doing this, I can chain commands to add more and more metadata, all of which can be "bubbled up" to the ultimate descendant. Best of all it's completely transparent to VirtualDub2 (my viewer of choice) because all audio is passed through normally, so I only ever have one clip to pass to the actual "doing something" filter at the end of the chain.

But it still has some caveats, namely that audio filters can't be trusted not to destroy my metadata. And if a clip doesn't have audio to start with, it has to be added (and can't be removed until after the final filter runs).

So I was wondering if such a system could be implemented in Avisynth separate to GetAudio. GetData, perhaps. By just passing a pointer to a buffer - or maybe have one other integer parameter as well, for simplicity/flexibility - the system could be made extremely flexible but infinitely adaptable. For a start, custom clip properties would then be easy to implement as a plugin.

As far as I can tell all it would take is adding an extra member function to GenericVideoFilter which, by default, simply passes its parameter(s) down (up?) to the parent (the confusingly-named "child" in GenericVideoFilter), or, if there is no parent, does nothing. Filter writers can then override this to their heart's content.

I installed VS2017 alongside VS2013 recently and the resulting compiled filters were significantly (10-20% or so) slower than VS2013. Just thought I'd mention that in passing.

I'd say it cannot be slower and there must be a reason for that. 10-20% is an enourmous difference and cannot be explained by a simple difference in optimization.
I'd look at the generated assembler code.
Then, I think new projects in VS2017 are defaulting to handle spectre mitigation.
There can be a speed difference between MT and MD builds.
Check for possible AVX2-SSE2 transition penalties if any of your code has AVX2.

I'd say it cannot be slower and there must be a reason for that. 10-20% is an enourmous difference and cannot be explained by a simple difference in optimization.
I'd look at the generated assembler code.

That's probably it. I didn't realise it had also been added to compilers.

Edit: further investigation suggests it isn't enabled by default, but also that the slowdown isn't as bad as I remembered. It's still slower with VS2017 though.

Maybe there are new optimisations which have slightly detrimental effects on older processors, or in certain circumstances. I expecting there are halting-problem type problems with trying to apply the best optimisations on all occasions.

The difference is slight enough that it could be any of several parts of my program. The busiest loop is full of ifs and switches and SSE.

Maybe there are new optimisations which have slightly detrimental effects on older processors, or in certain circumstances. I expecting there are halting-problem type problems with trying to apply the best optimisations on all occasions.

The difference is slight enough that it could be any of several parts of my program. The busiest loop is full of ifs and switches and SSE.

For the busiest part of the code using templates (even for longer functions) can make wonders, avoiding thousand of ifs and switches in an inner loop has also big advantage on the optimization. Letting know the compiler to use constants (given as template parameters) instead of variables is also a big help. I don't know the actual situation but it would help a lot. Explicitely forceinlined functions can give further gain as well.