3.0 progress

[Bidoche]

Today I finally managed to get the 3.0 branch into a compilable state.

But don't you start imagining things, it is still without a parser, so the result has to be hardcoded.

As soon as I got a BlankClip wired, I will post a version for testing (testing it don't crash)

[Kurtnoise]

:) Good news...

[Bidoche]

I finally got it working (a 1sec 640x480 pink clip), but I have a little problem :

Is that me being stupid or I can't attach files directly here ?

[esby]

Is that me being stupid or I can't attach files directly here ?
I think only moderators can attach files directly,
and of course file attached or posted by non moderator need the approval of a moderator to be displayed in the message.

[Guest]

The moderator control panel is showing no pending attachments.

[DDogg]

AFAIK, only a mod can post an attachment. Even then, only the specific mods of the specific sub-forum can approve it. In other words, if I attached to a post in this sub-forum I could not approve my own attachment, whereas I can in the D2S sub-forums.

[esby]

I guess the rule was restricted.
Now only moderators can post attachment apparently.
And it stills need validation, as said DDogg.

"You may not post attachments"


Since most users uses temporary/permanent website to post 'attachment',
it's not really a problem, but I can remember there was a time we could post attachment.

I guess the changes was motived by security measure, to avoid allow the posting of possible harmfull code (for the board or for the people clicking on it) or something like that.


But we should go back to the main subject avs 3.0 progress :)

esby

[Zarxrax]

@Bidoche: This sounds like great news. What are or will be the main new features of version 3.0?

[Bidoche]

I guess I will post to upload somewhere else and post an url then.
I am supposed to have some space from my ISP somewhere, or maybe sourceforge ...


Changes/Features that have ben made in current code (excluding those I intend for the parser and co)

- VideoInfo is now a polymorphic interface (hiding implementation details) centralizing all parameters checking.
That is to say, you no longer have to check params by yourself, you try committing to VideoInfo, who will throw the appropriate exception if necessary.
- VideoFrame becomes an interface too (easier further extension), the 4 get methods (ptr, pitch, row_size, height) are replaced by a single one who returns a struct containing all the data and some helper methods for its handling (increase code clarity)
- It is now possible to attach custom properties to frames, of two differents types :
- Flow properties will, once set, be passed (if everything is coded correctly) to all frames derived from the source
- Static properties gives additional info about the frame state.
Unlike flow ones, they are immediately discarded if the frame is accessed on write.
NB: That was what Donald Graft requested for Decomb.
- Two support classes are provided for memory allocation, Block and OwnedBlock (same as Block but reporting memory consumption to the owning environment)
They allocate aligned memory (16 byte) from a common pool (to all scripts running).
You can explicitely request recycling behavior (or not) whether you expect to allocate the same size often.
Unlike 2.X, the pool is completely synchronised against concurrent accesses. (2.X is very unlikely to crash on that, but still possible)
- Since frames are built using OwnedBlock, that guarantees the frame data is always 16 byte aligned.
Even more : since pitchs are chosen mod 16 (even YV12 chroma), that guarantees that all scanlines are 16 byte aligned.
- Filter graphs are now able of dynamic refactorisation, thus simplifying the chain in some simple (or not so simple) cases.

[Bidoche]

Another big change is that 3.0 is built using VC7.1, using STLPort as standard library and highly dependant from boost libraries (www.boost.org)

[vion11]

Looks like AviSynth gets a second turbo and
becomes more robust. Good news!

[Guest]

@Bidoche

Email me the file and I'll be happy to attach and verify it for you. If you do, put the word MAGIC in the subject line. Don't ask why. :rolleyes:

BTW, "Developer" has only one 'p'.

neuron2@comcast.net

[Bidoche]

@neuron2

Thanks for your offer, I just sent it to you.


Along with the avisynth dll, there are two others who are dynamically linked, one for STLPort debug mode (this is a debug build) and the other for boost.Thread who at the time being cannot be built as a static lib (hopefully it won't stay that way).


For now, there is not much to see, I just want to make sure it works on every OS.



BTW, "Developer" has only one 'p'.Oups... Let's check whether there are two in french so I can hide behind that fact.
Yes, saved. ;p

[zettai]

Will 3.0 break 2.5x filters in any way?

[Leak]

Originally posted by zettai
Will 3.0 break 2.5x filters in any way?

Well, since it's a rewrite and redesign I'd guess it breaks 2.5x filters in each and every way imaginable... :) (Not that that's a bad thing IMHO...)

np: Lali Puna - Scary World Theory (Scary World Theory)

[Bidoche]

3.0 breaks internal 2.5 filters, so there is no way it won't break plugins ones too.

It is not even built with VC6 anymore so there was no hope anyway.
(VC7.1 IS necessary, I am using boost libraries for which VC6 is too broken to work)


As for wrapping possibilities... I don't know, maybe it would be possible.

[Zarxrax]

The list of new features seems to be some very technical stuff. What practical applications would all of this have for people doing normal DVD-ripping and such? Breaking compatability with 2.5 seems like a major problem, seeing as there are many great plugins which may never be rewritten for the new version, or may not even have the source available. After all, if the current AVS works just fine for most people, why would they want to switch to this new one and possibly lose functionality? Or am I misunderstanding?

[t_2]

I know I don't belong here being only a very very satisfied AviSynth 2.54 user, and not a developer in any way shape or form, but just have to ask these questions.

1. Since you are breaking compatibility with 2.5 I hope you are doing it in a real big way, so that AviSynth could become cross platform something like Audacity, a wonderful sound editor?

2. Secondly I noticed that Avery Lee is now testing or perhaps just toying around with a native 64 bit version of VirtualDub, is AviSynth a native 64 bit program or if not could this code be written for a native 64 bit OS? Wouldn't that make it much faster, and ensure it a much longer lifespan than even 2.xx?

I don't understand computers enough to use anything but good Ol' Windows, but if I spent as many late nights/early mornings coding as you guys seem to, I'd want to make sure it would see the widest distribution and the greatest longivity.

[Bidoche]

@Zarxrax

Yes, since for now there is only the core who is done, changes are not of the sort easily visible to the user.
The one thing that would have been visible now (ie if you could actually render a script) is that 3.0 is less greedy on memory than 2.5.

People who only do normal DVD-ripping and cie probably who need to change before a long time, that is when 2.5 support is droppped...
But it won't happen that fast, 3.0 is still far from completion.


@t_2

1. There are no limitation to avisynth being ported on linux.
In the 3.0 core there is only one 2 line Windows dependancy in a small .cpp, nothing an #ifdef couldn't handle.
But in the other hand the avisource and export code are big fishs... and I am not the one doing them.

But if somebody else if willing, he can make himself known.


2. avisynth is C++, not native 64 bit code...
After that, maybe it can be compiled to 64bit code, but it would be special versions.

[Guest]

The zip from Bidoche is here:

http://neuron2.net/misc/avisynth.zip

It was too big to attach.

[vion11]

I'd give feedback for w2ksp4,
but where is msvcp71d.dll available?

[Kurosu]

Originally posted by Bidoche
@Zarxrax
1. There are no limitation to avisynth being ported on linux.
In the 3.0 core there is only one 2 line Windows dependancy in a small .cpp, nothing an #ifdef couldn't handle.
I gave it a try some weeks/months ago, but the code was probably in an unstable state to get any result. Anyway, here is my experience (of a failure):
- I saw many functions to which one had to lookup the POSIX equivalent; most of them were fortunately of the form _function() for the POSIX equivalent function(). Although there were many (especially with strings in parser), I guess this isn't overwhelming
- thread stuff (I mean, mutex, and locking access to the dll process as far I understood it) were a no go, as it is also platform-dependant.
- inline assembly. How my. I hate it when code use AT&T or Intel syntax for assembly. Sure it helps the compiler to schedule instructions better, and to make a better use of registers, but that's 0 freedom for choosing the compiler. The best alternative (people may complain it isn't available on all platform) is using nasm. I had to comment it all out, but I fear many functions were turned into no-op (I probably missed the C equivalent - which is more platform-independant than x86 asm code)

But someone used to porting code / with better knowledge of the linux platform can shed light on such matters.

But in the other hand the avisource and export code are big fishs... and I am not the one doing them.
I do agree. Even audio is a tricky part. Maybe even some libs used are too windows-centric to compile fine. I had the initial project to integrate it to ffmpeg or mplayer. The first one was maybe a better choice, given it offers input (not as wide as MPlayer) and output facilities. But in the long run, that wouldn't be very portable. Maybe making a plugin for GStreamer would be a wiser choice.

But if somebody else if willing, he can make himself known.
I guess only one programmer for the avisynth 3.0 architecture is insufficient. Bringing code (in the state I found it months ago) to a portable state is also a non-trivial task: if more than one is willing, the others can also make themselves known. :D

I remember a post of Kevin Atkinson (sorry for the spelling), the author of avisynth C API, on MPlayer dev mailing-list about doing a minimal port, ie from what I understood, bypassing as much stuff as possible like it is done for the loading of Windows codecs. It had no reply.

2. avisynth is C++, not native 64 bit code...
After that, maybe it can be compiled to 64bit code, but it would be special versions.
Same problem occurs as in any port of the sort. You have to check/adapt all ASM code, as registers are no longer the same, and plain MMX functions are not available in 64bits mode. AFAIK, only SSE2 instructions can be used, which integer part is identical to MMX, but brings alignment/new padding/limit issues.

[Bidoche]

@vion11

It seems to be a VC7.1 debug dll, I failed to notice it was required too :'(


@Kurosu


I saw many functions to which one had to lookup the POSIX equivalent; most of them were fortunately of the form _function() for the POSIX equivalent function(). Although there were many (especially with strings in parser)3.0 don't use char * functions but std::string ones (which is standard)

thread stuff (I mean, mutex, and locking access to the dll process as far I understood it) were a no go, as it is also platform-dependant.The boost.Thread library wraps around these platform dependances for us, so not a problem.

inline assemblyThat, I guess, IS a problem... :p
But in first times, C++ path could do.

[Kurosu]

@Bidoche

Originally posted by Bidoche
3.0 don't use char * functions but std::string ones (which is standard)
That's what I guessed it would turn into, so I didn't bother at the stage I found the code.

The boost.Thread library wraps around these platform dependances for us, so not a problem.
Again, that was my guess, but I simply forgot to mention it there :D

But in first times, C++ path could do.
I don't know what others would suggest, but I'd prefer to see all the ASM functions brought to nasm. I know that's a really tough thing, as you have to ensure that each converted function is properly working, and it's not completely trivial (in particular, the use of many arguments available at the level of the inlined asm).

What version of boost (never used it before) should one use to build AVS3.0? I guess that to use it, you have the typical steps:
- build the libs
- put the headers in the include path
- link the final DLL with the above mentionned libs

Maybe making a new thread would be more suited. Thread split from a moderator is welcome.

I got to the point where I could load the project and install the STLport/boost libs. However, MSVC choked on the build commandline for the .asm object. I suggest changing it to:
ml.exe /c /coff /Cx /Fo"$(IntDir)\$(InputName).obj" "$(InputPath)"
Other problem, I can't find either refcounted.h nor videoinfo.h in the 3.0 CVS (cvs co -r avisynth_3_0 avisynth) or in the libs' headers.

It appears they were removed. Check for instance the attic for refcounted.h (http://cvs.sourceforge.net/viewcvs.py/avisynth2/avisynth/Attic/refcounted.h
now)
Was this meant to be so !? Either way, it still can't be built.

[Bidoche]

I don't know what others would suggest, but I'd prefer to see all the ASM functions brought to nasm. I know that's a really tough thing, as you have to ensure that each converted function is properly working, and it's not completely trivial (in particular, the use of many arguments available at the level of the inlined asm).I would rather have asm functions NOT converted to nasm, as it defeats the purpose of having inline asm in the first place...
I'd rather have #ifdef guards to switch between versions, the 3.0 source is very well exploded so it won't make .cpp files grow unreasonably big.

What version of boost (never used it before) should one use to build AVS3.0?[QUOTE] Well, the last one, of course.
And yes you have to build it, include it and link it. Same for stlport.

[quote]Other problem, I can't find either refcounted.h nor videoinfo.h in the 3.0 CVS (cvs co -r avisynth_3_0 avisynth) or in the libs' headers.

It appears they were removed. Check for instance the attic for refcounted.h
Was this meant to be so !? Either way, it still can't be built.That would be me not updating the vc project, so the files it reports are completely obsolete :p (done now)
All the relevant files are in the src folder like 2.5 now, those in root are waiting to be worked on and moved there.

videoinfo.h is in /src/core/videoinfo.h
refcounted.h has been removed, I gave up this smart ptr attempt for boost::shared_ptr

[Kurosu]

Originally posted by Bidoche
I would rather have asm functions NOT converted to nasm, as it defeats the purpose of having inline asm in the first place...
I'd rather have #ifdef guards to switch between versions, the 3.0 source is very well exploded so it won't make .cpp files grow unreasonably big.I have to disagree on the later point, and that is a big concern IMHO. First, it would require to maintain the same piece of asm code in 2 different syntaxes (Intel, and another one). Then, one could think that if MSVC/... can have it, then why wouldn't gcc/...? The problem isn't to find someone who would be willing to port inline Intel-style asm, but the clutering of the source code. You could find 2 inlined versions of the same ASM code, plus possibly other #ifdef'ed references to an external function or yet another syntax. The equivalent of function pointers (specific classes which are holding the actual optimized code, like I did with Vaguedenoiser?) could help in that regard.

Although the ones who will port the asm parts to AVS3 should be the ones to decide, my opinion is that an unified way to store the asm code is needed. I don't know what is the impact of a function call through a function pointer (C-ish style), but I'd find it cleaner to have that simple function call instead of a ton of inlined ASM code for different architectures.

Another point to consider is probably what Sh0dan has done to some parts of the code, ie the compile-at-load-time of some ASM portions to better fit the architecture on which they are run. This involves another way to include asm, and does go against turning ASM functions into extern C's by porting code to nasm syntax.

That would be me not updating the vc project, so the files it reports are completely obsolete :p (done now)Anyway, I think I've only started my long journey into the land of the AVS3 compilation :)

All the relevant files are in the src folder like 2.5 now, those in root are waiting to be worked on and moved there.
OK

videoinfo.h is in /src/core/videoinfo.hWhich means it was already there, or it should be now available there ?

refcounted.h has been removed, I gave up this smart ptr attempt for boost::shared_ptrWell, then, I guess that if it wasn't needed, the errors I saw weren't completely due to its lack.

Thanks for the info. More attempts tonight (GMT+1).

[MfA]

As long as you hit the BTB an indirect function call is almost as fast as the direct function call ... of course for a lot of applications of inline assembly even function call overhead itself is too large.

Personally I like the Linux way of programs being optimized for architectures at compile time better than loadtime determined function pointers. It totally defeats the point of inlining, and you end up with needing to put far more functionality in assembly to get the same speedup.

[Wilbert]

Some questions from someone who can't follow much of this discussion:

1) Bidoche, could you write a one page document about the new features of 3.0 (*), differences with 2.5, and how new plugins (deinterlacers, denoisers) can make use of those new features. Then I will add it to avisynth.org.

(*) I saw your item list on the first page of this thread, maybe you can expand it a bit (so that more people can understand it).

2) I gave it a try some weeks/months ago, but the code was probably in an unstable state to get any result. Anyway, here is my experience (of a failure): (...)
Maybe the three of you (Bidoche, Kurosu and Kevin) could work together and try to port it to Linux? Kevin will probably help if you ask him. If you want Sh0dan can add you to the avs project.

3) I guess mpeg2dec3 is the first obvious plugin to be compiled for avs 3.0. I will ask Neuron when he's "ready" working on dvd2avi/mpeg2dec3, but that can take a while. Btw, are the resizers already working in 3.0?

[Bidoche]

The whole idea about inline assembly, is that since it's inline, it can take values directly from the stack frame.
When .asm or function calls can't do that.

To avoid source cluttering, we can limit the use of #ifdef to small and simple asm code.
And make a avisynth_3_0_linux branch for the others.
After all, we ARE NOT under the obligation to have exactly the same source files on both platforms.
That way, we keep inline assembly (which is easier to understand and maintain than .asm) and have the CVS keep track of gcc versions to make.


Another point to consider is probably what Sh0dan has done to some parts of the code, ie the compile-at-load-time of some ASM portions to better fit the architecture on which they are run.Of course, using SoftWire is a solution, but it's a lot of work to make code like it.


@Wilbert

3.0 is not intended to users yet, but to developers.
So we can't really talk of features yet, but of a developement framework...

But I agree I could give more explanations about my classes.


I guess mpeg2dec3 is the first obvious plugin to be compiled for avs 3.0. I will ask Neuron when he's "ready" working on dvd2avi/mpeg2dec3, but that can take a while. Btw, are the resizers already working in 3.0?Just signaling that for now, there are no plugin loading code, nor function table to fill in 3.0.
It's a bit early to really do plugins. But the code conversion matter can still be looked up.

The resizers are partly done, I made the support classes (Pattern, pattern::Maker, pattern::packer, and the filters) the pattern interpretation is yet to be converted.

I will go back on that when the Antialiaser code is complete (so I can have clip messages to show rather than blank frames :p)

Since I am talking about the Antialiaser, I think the way it actually uses to calculate haloAlpha is flawed....
( there are some cenmask |= (BYTE)(((long)-src[srcpitch*i ])>>31); which happens to be a noop (src is unsigned char *).... )

[MfA]

You could also put ifdef'd static inline versions of the functions (with appropriate inline asm) in a header file. Clutters up the main program less, and the compiler would remove the function call overhead.

[Kurosu]

Originally posted by Bidoche
The whole idea about inline assembly, is that since it's inline, it can take values directly from the stack frame.
When .asm or function calls can't do that.
That's indeed an avantage, that helps avoiding a bunch of headaches.

To avoid source cluttering, we can limit the use of #ifdef to small and simple asm code.
That is another idea, although I prefer MfA's idea.

And make a avisynth_3_0_linux branch for the others.
After all, we ARE NOT under the obligation to have exactly the same source files on both platforms.
I disagree here. I wouldn't like to maintain or keep porting code from a syntax to the other. It's indeed feasible, but I don't think the Avisynth project has (yet) the resources (the developpers) to spend on that task.

That way, we keep inline assembly (which is easier to understand and maintain than .asm) and have the CVS keep track of gcc versions to make.
Well, I hate AT&T syntax, even though it is better at register allocation. So in my case, it wouldn't be easy to maintain this inline code. And so, someone would have to do it. There I feel huge problems (unsynchronized code, porting error, ...). And nasm's syntax isn't that more difficult than Intel's. Sure you loose the direct use of values as you stated. But that's IMHO the only drawback besides function call overhead and x86 (not even sure of that one) limitations.

Anyway, just ask some people coding in assembly around here. They would probably give better evidence in a way (several asm code pathes for each platform and architecture) or the other (extern "C" function) than my single opinion.

Of course, using SoftWire is a solution, but it's a lot of work to make code like it.
Agreed.

[Bidoche]

Whaouh, that was fast, both of you.
Were you lurking here, waiting for a post ? ;p

I disagree here. I wouldn't like to maintain or keep porting code from a syntax to the other. It's indeed feasible, but I don't think the Avisynth project has (yet) the resources (the developpers) to spend on that task.Because you think conversion to nasm form is not as much as formidable a task !?
This solution has the advantage of not crippling the win32 branch from its lag.
On the contrary I think since we have few ressources, it's better this way.
Besides maybe we only have to announce that a linux port is under way to have ppl to do the conversion for us...
Personally I do not intend to do it myself, I already have my hands full with the C++ code to convert from 2.5 (I don't want to touch to AT&T asm either :p )

[MfA]

How about just having a pure-C backup of asm code whenever possible? (Possibly with intrinsics, they are readable and portable ... and in a lot of cases fast enough.) It's good practice IMO, and allows ports to be done more gradually.

[Bidoche]

Good idea.
It's always good to have the C version of the asm anyway, especially when comments are sparse.


Otherwise I got the Antialiaser compiling, so I will post a new build (with msvcp71d.dll) showing a message instead of a blank frame as soon as ready.

[Bidoche]

@Wilbert

Here is an example of the differences between 3.0 code and 2.5 :
A (partial) conversion of the SimpleSample 1.3 code.


//GetFrame now returns CPVideoFrame (smart VideoFrame const *)
CPVideoFrame SimpleSample::GetFrame(int n) const
{
//implicit conversion to smart VideoFrame *
PVideoFrame frame = GetChildFrame(n); //method for lazy coders :p

WindowPtr dst = frame->WriteTo(NOT_PLANAR); //fetch ptr, pitch, height, width at once in the WindowPtr struct

dst.to( dst.width / 2 - SquareSize * 3 / 2, dst.height / 2 - SquareSize / 2); //move to top left of square we want to draw

for( int y = SquareSize; y-- > 0; dst.pad() ) //goes from end of current line to start of next, ie add pitch - width
for( int x = SquareSize; x-- > 0; dst.to(3, 0) ) //move to next pixel
{
dst[0] = 255;
dst[1] = 255; //or in coordinates form dst(1, 0)
dst[2] = 255;
}

return frame; //implicit conversion to CPVideoFrame
}

[Kurosu]

Originally posted by Bidoche
Because you think conversion to nasm form is not as much as formidable a task !?
Either way, there's one conversion needed for a linux port: Intel syntax to AT&T syntax or nasm .asm files. Now look back: you either have inline asm in AT&T syntax or .asm files in nasm syntax. VC++ doesn't support AT&T syntax, gcc doesn't support Intel syntax. My conclusion: only if you have nasm code, you can use it in both environment. Now, imagine that you add new ASM code: you either add it as Intel, AT&T or nasm. The first 2 require that you also convert code from one syntax to the other. You don't with nasm.

On the contrary I think since we have few ressources, it's better this way.
Well, either way, code needs to be ported. But once it's ported, I have described what happens.

Besides maybe we only have to announce that a linux port is under way to have ppl to do the conversion for us...
http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2003-09/msg00244.html
Seeing the absence of reply, I guess it needs to be really well marketed to have people join. Or maybe it was just Avisynth being in C++? (I'm not being sarcastic - I know C++ is a no-go for some developers [I dare say linux developers])

btw, I contacted some time ago Kevin about this matter. His intent really was to emulate (like it's done with the DCOM Api for loading DMO codecs and the like) the parts that were too windows-centric from what I understood.

Personally I do not intend to do it myself, I already have my hands full with the C++ code to convert from 2.5 (I don't want to touch to AT&T asm either :p )
And it would be a waste of your time to do the conversion by yourself, compared to what is left on the C++ side, and what you can achieve there.

Another message:
It's always good to have the C version of the asm anyway, especially when comments are sparse.
Indeed, I always try to do that in my case. But anyway, I think MfA was referring to the possibility to use specific intrinsics to write C-like asm code. For instance (very reduced example):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vcrefmmxtechnologysetintrinsics.asp

[MfA]

Originally posted by Kurosu
Either way, there's one conversion needed for a linux port: Intel syntax to AT&T syntax or nasm .asm files.

ICC under linux groks msvc inline asm too I believe.

The port to GCC would require the conversion, but only to create an optimized version ... a slower C version could be immediately available if you make sure C versions are always available (again possibly with intrinsics, since they are the same between compilers AFAIK ... in which case it wouldnt be all that slow).

[Kurosu]

Originally posted by MfA
ICC under linux groks msvc inline asm too I believe.
Yes it does. But very few people have access to it, and making it a requirement would almost defeat the purpose of a linux port.

a slower C version could be immediately available if you make sure C versions are always available
Well, we are dealing with asm code porting here. It is a temporary solution however, as in any project, to fall back on such code when no optimized exists.

(again possibly with intrinsics, since they are the same between compilers AFAIK ... in which case it wouldnt be all that slow).
I would place intrinsics in an even lower ease of use than AT&T syntax. But that's just me not being used to it. I don't know if there are any multi-platform intrinsics available.

@Bidoche
Could you tell what version of boost you used? I used 1.31 from http://www.boost.org/
Except other errors I want to deal after this problem is solved, it fails on including <boost/circular_buffer.hpp>
It doesn't seem to be present in boost and AVS3.0 include dirs.

TIA,
Kurosu

[MfA]

Apparently MSVC's code generation using intrinsics sucks, at least according to Phaeron, so you might be right.

[Bidoche]

@Kurosu

Didn't you see the comments about circular_buffer in the source ?
This library is not part of boost yet, and has to be downloaded separately...

Hmm, checked, my comments about that are gone :/

Here is the url where it can be found
http://groups.yahoo.com/group/boost/files/circular_buffer_v3.6.zip

[Kurosu]

Originally posted by Bidoche
Didn't you see the comments about circular_buffer in the source ?
Even if they were there, I don't think I'd have searched that. I've just copied the header's name and searched for it in the appropriate folders.

This library is not part of boost yet, and has to be downloaded separately...
OK, excuse my great ignorance of boost, that even 1 minute of doc-reading may have solved (thanks for not replying with that ;)

Here is the url where it can be foundThanks

[Bidoche]

OK, excuse my great ignorance of boost, that even 1 minute of doc-reading may have solved (thanks for not replying with thatWell, you probably could have found easily that it was missing from boost...
In fact you actually did :p
But finding the source files takes some time.


With that, maybe you will only be left with the annoying task of understand how to build boost :p

[Bidoche]

Finally fixed RGB output.
Now it can make pink clip in YUY2 and YV12 and gray ones in RGB

[Kurosu]

Originally posted by Bidoche
http://groups.yahoo.com/group/boost/files/circular_buffer_v3.6.zip No luck, it requires a registered account, which I'm not likely to get. I know it's much asking but could you make it available differently?

Otherwise, boost/STLport were the first things I compiled, and it seems it went fine. I don't recall having much difficulty in that.

[Bidoche]

No luck, it requires a registered account, which I'm not likely to get. I know it's much asking but could you make it available differently?Registering is free... It should not be a problem.
Anyway if you want I can mail it to you (supposing you give me your mail).


Otherwise, boost/STLport were the first things I compiled, and it seems it went fine. I don't recall having much difficulty in that.You are more courageaous that I was. :)
It took me quite a while to get myself over bjam.
But that's true I did not need it (since not attempting to build)

[Kurosu]

Originally posted by Bidoche
Registering is free... It should not be a problem.
Registering to a commercial entity which use of my email address is unknown is a problem for me. Not that I'm paranoïd, but I think CNIL is a good idea. :)

Anyway if you want I can mail it to you (supposing you give me your mail).Yes, please. Check PM (being paranoïd by not giving my email on public forums? erm... :D)

You are more courageaous that I was. :)
It took me quite a while to get myself over bjam.
Now, I'm not: jam is now available as a binary on the project's sourceforge download page. :)

Anyway, linux and shell scripting of some autobuild systems got me used to doing such stuff. But maybe I haven't done all that was needed (though I don't regret the Python stuff). boost failed on building some targets (I've got 74 libs for 92MB), but I'll wait for problems before bothering with those.

[Bidoche]

Registering to a commercial entity which use of my email address is unknown is a problem for me.Isn't that what hotmail is made for ? :p


Anyway, I managed to get the Antialiaser compiling (not working as expected yet).
I get nice antialiased text, but the halo is all blocky :/
As soon as I fix that, I will post a build making a msg from the source text

[Sigmatador]

good to see that unix is considered as well this time.
Avisynth is THE reason why i'm not on linux all the time.

[vispgraedde]

Is there any real project page for 3.0 anywhere?
Some page that list information about what you want to achieve with 3.0, and what features will be added/removed, etc. together with timeframes for when things are expected to happen.

How many developers are working on 3.0?
Anyone from the 2.5x branch?

Is 3.0 a rewrite from scratch or is it yet another patchwork based on the existing stuff?

[Bidoche]

Is there any real project page for 3.0 anywhere?I guess that's what Wilbert wanted to setup on avisynth.org, but I haven't produced anything yet.
Let's give it a try :


Avisynth 3.0 :

Motivation :

The old architecture has proven its limits at the 2.5 update when YV12 support had been hacked into it.
The code base, besides being old code from 1998, not using advanced C++, has never be really meant for future extension.

3.0 is rewrite from scratch who aims (among other things) at far better extensibility.
Adding a colorspace, since that was my example, is a simple matter.
And you won't have to update each filter on it for them to report "Unsupported ColorSpace"...

Expected Features:

- Improved memory management, ie not use more memory than necessary and do the best of the available when it's short.
- Multi instance awareness : 3.0 will behave correctly when multiple scripts are loaded at once, they will share memory, and some filters (multiple avisource on same file) may even resolve themselves into a fusioned clip.
- Improved parser : the parser will include the widely requested flow control structs (if then else, for, while).
It will add two new types : frame and function.
If it can be made, it will also include terminal recusivity optimisations to avoid stack overflow on recursive functions.
- It will include GUI hooks so they can retrieve info about filters directly from avisynth and its plugins
- Filters can support a dynamic refactorisation feature who aims at simplify the filter graph (kill dead branchs, limit depth)
- Maybe: exposes itself as COM interfaces and accept COM plugin.
That would solve the plugin recompile issues.
- Maybe: if ppl are willing to work on it, a linux port

Avancement :

3.0 has reached alpha stage, ie it builds and does things, but it's not of interest for users (no parser yet)
Developers, however, can start looking into it. I took a great time making helper classes to simplify filter development.

3.0 Crew :

Me, alone (for now (I hope))

TimeFrame :

If I manage to tame spirit (parser library) the parser may be done in a couple of months.


Will that do ?