Proposal for AviSynth 2.6

[MfA]

It isnt that I was suggesting that filters directly access the userdata directly through the pointer, you just need some way to associate the user data with the videoframe object. The entirety of PVideoFrame is implemented in the header, can't do nothing with that. Usually you would store a pointer in the private data of VideoFrame, but since you are trying to retain binary compatibility and that is not possible just tacking it onto vfb->data seems the easiest route. You either need to store the data with the object, or have some identifier for the videoframe object which you can use with a lookup table to find the user data (and the only identifiers available are pointers, and that is far fuglier than adding it directly to vfb->data).

Sure in principle the vfb->data pointer is readily exposed to filters, it is private though, but the syntactic suger in C++ never really hides anything ... privacy is a matter of manners in C++, nothing more.

Why do you want to implement it with virtual functions? Normal functions can be added without breaking compatibility without needing any tricks, and the implementation can still be in avisynth.cpp so they are still opaque/non-inlined. Implementing it with virtual functions seems a little roundabout ... when would you ever want to inherit VideoFrame and override those functions?

[mg262]

I think we ought to leave sometime for thought and discussion before throwing in the associated-values. There are several issues to resolve. For example, what about namespace clashes? Are we going to give each DLL its own namespace or are they all going to share one? If the former, does a DLL have a mechanism to access information from the namespace of another DLL? Etc.

@MfA,

Could I ask what in particular you are intending to use the associated values for?

[Bidoche]

Dlls should each use their own namespace, but even if they don't, why would it clash ?

[mg262]

Sorry, I meant namespace for keys. So if two different plug-ins both try and attach a value with a a key called, say, "size" to a frame then are they accessing the same value or different values?

[MfA]

Originally Posted by mg262

Could I ask what in particular you are intending to use the associated values for?

HDR filters.

As I said, Id use a GUID for a key ... a little less user friendly, filters who want to cooperate need to get the appropriate GUID from some higher level, but no chance of interference.

[Bidoche]

No need for string or guids for keys.

just :

struct Key { }; 

Key myPluginKey;  //inside my plugin somwhere, use &mypluginKey as key

That's the simplest approach

[IanB]

@MfA,

By implementing it with virtual functions and then deriving new classes we can support any differing requirements with different child classes. It's about providing the maximum scope for the future and it needs to be analysed on a case by case basis, for some cases normal methods may be preferable to virtual methods. If done correctly then 2.6 api plugins should be loadable in any future version. Don't let my forthright opinions stop you pushing the envelope, only by chalanging ideas can we beat bugs out of them before we code them.

@mg262,

There are many methods for both avoiding and allowing collisions, i.e the way HANDLES work in windows, note I'm not saying we need something this perverse, but it is an example. The 2 cases I see are A) 2 separate instance of the same filter each wanting their own unique data set and B) a set of filters that want to pass data tags up the GetFrame chain between themselves. And of course there is the amalgum of the 2. Things like the "this" pointer make good unique values. And the environment variables provide a method for sharing key information.

IanB

[Bidoche]

Here are what I use (simplified) in 3.0 :

class Key
{

public:  //structors

  Key() { }
  virtual ~Key() { }


public:  //Key interface

  virtual bool operator==(Key const& other) const { return &other == this; }

};

class Property
{

public:  //structors

  Property() { }
  virtual ~Property() { }


public:  //Property interface

  virtual PKey GetKey() const  = 0;

};

both handled after with smart ptrs PKey and PProperty

This can handle your A) and B)

[mg262]

This all seems very sensible. But I was trying (not very well) to say this: sh0dan very sensibly put forward a set of additions for 2.6 which it was very clear how to implement, and this one, much as I would like it, seems to me to need a lot more thought and clarification than the others. Namespaces were meant to be an example.

Or is it that they are coming up now not because we want implement them immediately, but because we want to make sure we don't break anything in doing so (which to some extent is something that can be applied to any feature)?

[MfA]

IanB : Well VideoFrame is an everything and the kitchen sink object, every type of videoframe you want is enumerated and stored in there ... it's as anti-inheritance as it gets, seems futile to start adding virtual functions now. If in the future the needs change, add a new enum

Anyway, an extra lookup doesnt matter much I guess (using the this pointer of the VideoFrame object as an index). all that pointer chasing which will be necessary to search the user data through a dynamically sized two dimensional lookup table isn't pretty, but compared to the actual work a filter does it isnt really relevant.

mg262, the changes to the API are relatively small for what I ask. Just two new public methods for VideoFrame, using something like Bidoches classes it would be something like void AddProperty(PProperty) and PProperty GetProperty(PKey). Now Im not big on OO design, but I dont think it should be too hard for those who are to agree on the interface (and implementation is relatively easy).

[mg262]

If it's just interface, then that seems very sensible to me!

[foxyshadis]

(Love the sideband data push, even if it might have to get shelved for 2.7.x it's still awesome.)

I'm not sure if this should be a 2.5.x or a 2.6 request, but I was wondering if changing the cropping options for resize filters was on the map. The right/bottom parameters aren't currently compatible with the negative offsets regular crop can use.

Edit: I just noticed that it was committed to 2.5.6 CVS shortly before my request. Sorry.

[Richard Berg]

I just noticed that Avery Lee made a very extensive post on a next-gen filter interface. I think you guys need to talk to him -- not only is he a really smart & helpful video guy, but if both platforms are going to be changing at the same time then it makes sense to build in better compatibility. After all, most AVS users still use VDub every day, and vice versa.

MS keeps me pretty busy, but let me know if there's anything I can do to help -- if you find bugs in DirectShow, for example, that helps us too. (I work on Visual Studio, so developers are literally my customers). I think you'll find the C++ features in Whidbey are much improved, even if you don't use C++/CLI.

[sh0dan]

I created a branch for 2.6. Called "avisynth_2_6":

http://cvs.sourceforge.net/viewcvs.p...g=avisynth_2_6
(New files not reflected there yet)

I committed my first changes:

Added preliminary general planar support:
- Formats added to avisynth.h.
- NewVideoFrame can produce general planar images.
- PVideoFrame should return correct values for rowsize, pitch, height.
- Cache behaves correctly on new format.
- All code assuming UVwidth = Ywidth/2 an similar should be gone.
- So far old plugins behave nicely!

- SubFrame is BROKEN! It should be replaced by a bitblit.

Added SSE3 to CPU detection. Not tested.

The changes are mainly to be able to get started on the filter work, which is my strongest side. Assuming there will be no changes to the avisynth.h interface from a filter POV we can always remove (new) the baked code before beta 1.

[tsp]

I made some changes to make avisynth more threadsafe. You might want to add some of those.

[ARDA]

bool sse3sup()
{
	bool sse3prt=false;
	_asm{
		pushad
		sub eax,eax
		cpuid

		mov eax,1
		cpuid
		and ecx,00000000000000000000000000000001b //bit0
		jz noexistesse3
		mov  [sse3prt],1
align 16
noexistesse3:
		sub eax,eax
		cpuid
		popad
	};
	return sse3prt;
}

I didnt look your code but this I ve tested and I think it works ok
I hope this could be useful
Luck with all this new work. ARDA

[IanB]

Originally Posted by sh0dan

- SubFrame is BROKEN! It should be replaced by a bitblit.

I assume you mean SubFrame can cause non aligned data, this is not broken, just unfortunate. Doing bitblits to correct alignment is a really bad thing because they are slow, about 5 orders of magnitude slower than passing a pointer. Or is it about the existing baked code having YV12 only assumptions, hence my isPlanar() bit shuffle.

I had a thought about introducing virtual edges to the API where frames can have junk around the edges to keep the alignment and virtual width and height. Would also mean all the power of 2 width/height restriction could just go. Only filters that care to notice the the true width and height need make of it. From the core point of view, the output blitter will need to know and I guess the resizers could make efffective use.

IanB

[sh0dan]

I assume you mean SubFrame can cause non aligned data, this is not broken, just unfortunate. Doing bitblits to correct alignment is a really bad thing because they are slow, about 5 orders of magnitude slower than passing a pointer. Or is it about the existing baked code having YV12 only assumptions, hence my isPlanar() bit shuffle.

It'll get more and more messy with various formats, to adjust offsets for each plane. From the top of my mind I can only think of crop that is widely used, which uses SubFrame. I think it'll be cleaner for the future if we just drop this and use blits instead.

@ARDA: Looks like the code I put in. Code is here:
http://cvs.sourceforge.net/viewcvs.p..._with_tag=MAIN

@tsp: I thought the thread safety had been implemented already, but I see it hasn't. I'll apply it ASAP.

@all: Just saw I accidently committed the code to MAIN. I'll correct this back when I get home tonight. Sorry.

[bill_baroud]

sorry if this sound dumb, but while i'm reading your very interesting discussion about the design of avisynth, there is one thing i don't understand : what's the "baked code" ? I'm pretty sure that a litteral translation can't apply here

[tsp]

sh0dan: The source changes I made include both the neccesary changes to make avisynth threadsafe (mainly in the avisynth.cpp, cache.cpp and internal.h) and a filter to actually run avisynth multithreaded (although it's not completly done yet). I don't know if you want both thing in 2.60.