3.0 Wip

[Bidoche]

I just committed new code/files to the cvs with those changes (not exhaustive) :

- Continued exploding of avisynth.h
- Integrated args checking into the property system
- Partial rewrite of this one to allow custom properties through COM
- ColorSpace is now a polymorphic class with big self knowledge


And I would like some input on some topic :

Collision issues : in stackvertical (for example) should I allow mix of frames of different types (top, bottom, progressive ....) or should I check it.
Then should I try extend it to custom properties... (they already can complain about illegal other args)

Avisynth exception hierarchy : I already created some new exception types and will probably do more, it had to be organised somehow..

[Atamido]

Don't forget to add in the register to contain the duration/timecode/whatever to support variable frame rate.

[Bidoche]

It's not done yet, and the decision to include it has not be taken.

[sh0dan]

It looks really great - even though it still is way beyond me. Great work!

[Kurosu]

Pamel
Don't forget to add in the register to contain the duration/timecode/whatever to support variable frame rate.

I think a bit more of thinking is needed, and we (rather, the developpers, as 'I' doesn't bring any contribution in matter of code) should wait for upcoming containers. Now sounds like a waste of time.

Bidoche
Partial rewrite of this one [property system] to allow custom properties through COM

Although I'm not sure what it will concern, I do hope it will bring some kind of backward compatibility. Besides, that makes me wonder on the possibility to export more information about a filter than its name, its command-line type of the kind "ciis". What I have in mind is the ability to make an inquiry on the filter:
- names of the parameters
- if possible, their range
- how much frames can be stored/asked (the SetCacheHints in some way)
The only use I see is for some User Interface...


- ColorSpace is now a polymorphic class with big self knowledge

I need to get back to some C++ tutorials... What could be the use? More logical design, separating colorspaces in the processing? Ability to reuse the same kind of code for planar/interleaved pixel formats?

[Bidoche]

Although I'm not sure what it will concern, I do hope it will bring some kind of backward compatibility
The whole point of COM is to resolve once and for all compatibility problems. Once it's done, plugins done using COM will always work wit future versions.
For 2.0 and 2.5 versions maybe we will manage to provide COM wrappers but don't count on it. Architecture changes are really big, and it won't be easy to adapt one to another.


What I have in mind is the ability to make an inquiry on the filter:
Even though it's certainly doable with COM, I think it may be smarter to publish these infos as an XML document.
If anybody has some insight about XML, you are welcome to give input.

I need to get back to some C++ tutorials... What could be the use? More logical design, separating colorspaces in the processing? Ability to reuse the same kind of code for planar/interleaved pixel formats?
Essentially more logical design.
It's generally better to have an self aware object (even if it has only one instance) than a (int) code that is interpreted by others (VideoInfo here).
It's better to put properties/code where they belong, the resulting code is easier to understand.


Besides it is more efficient too : Videoinfo was using switchs and virtual calls are faster.
In OOP, you should avoid when possible to use switchs and use polymorphism, it's done for that, to implicitly choose the good codepath depending on a paramater (the object).

That's why I keep complaining about all these filters with the 4 codepaths in one method. That's an hidden switch. (and redundant, the decision don't change between GetFrame calls)

Should be done like this:
class MyFilterParent : public GenericVideoFilter {
protected:
//my args here
//my constructor with these args checking

virtual void MyProcessFunction(... ptrs, pitchs, heights....) = 0;

public:
virtual PVideoFrame GetFrame(...) // GetFrame who calls MyProcessFcuntion appropriately
};

class MyFilterRGB24 : public MyFilterFilterParent {
protected:
virtual void MyProcessFunction(...) //RGB24 codepath
};
//same for others colorspaces...

CreateMyFilter(....) {
switch(colorspace)
//create an object of the good subclass
}

Edit: IIRC in you Turn version, you saved the process function to call in a parameter. That's smart, but it's more of a C solution when you lack polymorphism.

[Richard Berg]

quote:
--------------------------------------------------------------------------------
What I have in mind is the ability to make an inquiry on the filter:
--------------------------------------------------------------------------------


Even though it's certainly doable with COM, I think it may be smarter to publish these infos as an XML document.
If anybody has some insight about XML, you are welcome to give input.
I was about to make the same suggestion. Using XML for filter info lets us add as many properties as we want in the future using just a single, unchanging function call (string getXmlInfo() or similar).

[Si]

@Bidoche
That's why I keep complaining about all these filters with the 4 codepaths in one method. That's an hidden switch. (and redundant, the decision don't change between GetFrame calls)
Should be done like this: ...

Could/would you rewrite SimpleSample to show us "OOP challenged" the proper way of doing things or is it not possible with 2.5?

regards
Simon

[Bidoche]

@siwalters

Damn, I guess my attempt at laziness failed miserably...
I will do it ASAP.

Edit: finally I will do it in 3.0 style.

[Atamido]

Originally posted by Kurosu
I think a bit more of thinking is needed, and we (rather, the developpers, as 'I' doesn't bring any contribution in matter of code) should wait for upcoming containers. Now sounds like a waste of time.

I only mention it because matroska will support it and it close to public beta testing. I'm also assuming that OGG will support it whenever Xiph publishes specs for storing video in OGG. And for some reason, I was under the impression that MPEG-1/2 containers both supported it, but I can't remember where I heard that. Maybe it was in reference to the video being able to switch between interlaced and progressive whenever it likes? Not sure on that one.

But, I guess its really a moot point until a filter exists for AVISynth to accept one of these containers as input. Well, once those filters exist, I would hope that there would be somewhere set up already to store that variable in.

BTW, is there a flag that marks if a frame is part of an interlaced picture, or does it matter?

[Bidoche]

BTW, is there a flag that marks if a frame is part of an interlaced picture, or does it matter? !? What do you mean, I don't get it.

[Atamido]

At the risk of sounding like an idiot, I'll try to explain what I'm talking about. Please note though that I still pretty fuzzy about how exactly interlaced video is dealt with.

With NTSC interlaced video, the framerate is ~60fps. But it altenates between showing the odd and even lines for each frame. You can drop the framerate to ~30fps and combine these two fields to show progressively, but this will usually show combing artifacts bacause the interlaced video is often produced from a 60fps source, so the fields don't line up perfectly.

When dealing with the video digitaly, there are four different kinds of frames that can be passed. A regular progressive frame, a frame containing just the odd fields, a frame containing just the even fields, or an frame containing both fields of an interlaced video.

Well, for display purposes on a computer, it is handy to know what kind of video frame you are dealing with. A regular progressive frame is easy to display on a computers progressive display. When alternating between the odd and even fields, you have to 'bob' the frames, otherwise the image appears to jump up and down. With a combined-field frame, you either have to de-comb the image or separate the files, double the fps, and 'bob' the images.

There are some source (read DVDs) that will alternate between progressive and interlaced video. When somebody wants to use a filter to decomb a source, it is much better to only decomb the interlaced frames, than to also try to decomb frames that are already progressive. I realize that there are smart filters out there that can 'detect' an interlaced frame using image algorithms, but they are not nearly perfect. You could manualy split the video and into chunks and only decomb those portions that are interlaced, but some sources might switch a hundred times back and forth between interlaced and progressive (I have heard of some anime DVDs that do this), making it nearly impossible. (BTW, this is a perfect example of existing variable frame rate video)

How does this relate to AVISynth development?

Ah, if AVISynth could carry a flag indicating what type of frame it is passing, you could have a decomb (or 'bob') filter set up that only processed those frames. Talk about a world of pain saving.

[Bidoche]

@Pamel

please take a look at this thread:
http://forum.doom9.org/showthread.php?s=&threadid=46007

@all

Committed new code, essentially about function search/link (linker.h/cpp).
By using type_info and templates, now accepted types are no longer hard-coded.

For that I used boost::any to rewrite AVSValue.
From now on, boost and STLPort will be required (maybe we can use another STL implementation than STLPort but this one is known to work with boost, so...)

[Atamido]

So, the answer is "Yes", correct?