PDA

View Full Version : To the developer trio - Some slight concerns


DDogg
18th March 2003, 17:07
First, you guys are my heroes so don't take this as any form of criticism. I only want to voice something that has been on my mind lately. Actually "slight worries" might be a better description than concerns.

The community that finds Avisynth a indispensable tool is made up of many groups. I am just guessing, but I think an argument could be made that the smallest might be those that use it for XVid and Divx encodes (don't beat me up on this statement, as I said I am just guessing and trying to make a point). Another huge group are the svcd'ers, and DVD'ers. Another is those that use VFAPI or Link2<(#%$%%#) to allow the use of avisynth with commercial programs like the various NLEs, and programs like AfterEffects. I would not be surprised if avisynth has not been used in some of those big budget Hollywood films occasionally. None of these people seem to be vocal in this forum for some reason, but I assure you they exist all over the planet :-). In other words, AviSynth is probably bigger than you think and I expect it to become much more so with the terrific work you three are doing.

OK, to the point of my worries. There are just the three of you. I may be completely incorrect, but I think your interests are primarily divx/xvid. By the very nature of that, I think it is possible that the needs of the full Avisynth community might accidentally be overlooked. Again, I stress, this is no form of criticism, rather just the nature of the situation where three overworked volunteers naturally might focus on those things that are part of the individual enthusiasms that fuel their efforts.

Where I am going with this is simple to bring the point up for discussion and to:

1> Politely request that as 3.0 takes shape the full community at large needs to take the time to give you three the feedback you need to keep you aware of these considerations. If nobody brings up these things to you how in the hell are you supposed to understand those needs? I know you guys are well talented, but I expect you are not mind readers. :-)

2> To ask that the devel team make some small effort to be more inclusive of these needs in their consideration and replies to non xvid/divx threads. Sh0dan mentioned in a post that he had never heard of VFAPI. Why should he, that's not his bag. I am completely OK with that, but it is one of the things that brought these worries to a head. Sh0dan, I am NOT beating you up with this statement :-) - Just making the point that you can not consider those things that you have no experience or use for. Perhaps these things COULD be included in a general test suite though as part of the devel process?

2> The closer integration and inclusion of non ripper members into the core development test team, i.e., those that use Avisynth for things other than xvid/divx encodes.

These few actions might serve to bring the full needs of the avisynth community closer to the developers as they make progress towards the richness of avisynth 3.0.

I hope my comments will be taken in the community spirit in which they were given.

Regards,

DDogg

Guest
18th March 2003, 17:37
What are you smoking? :)

The development process is completely open and transparent. Adequate mechanisms and forums exist for interested people to contribute thoughts and ideas. Anyone capable of contributing can join the team. Extensive open alpha and beta testing is performed.

So what are you asking for specifically, and of whom?

DDogg
18th March 2003, 18:57
Howdy, Donald, how are you doing, I hope you are well and are you back home yet? Darn, I kinda wish the first reply to this thread had not set a tone and asked what I am smoking. Marlboro actually :-) Anyway, OK, so be it.

What am I asking? I ask nothing except some different thoughts be openly considered in the spirit in which they were openly given. I wish no aggressive argument with anybody. As to those thoughts:

From some years of experience in the software business, IMO, there is a fundamental difference in the process of volunteer development vs. commercial development. Volunteer development is about the creation, or embellishment of software that is near and dear to the individual or peer group's need, i.e., an individual or group enthusiasm that is very vertical in its address and destination. That is a good thing and allows software to be written that would never be created in the commercial world because of that vertical nature. Perhaps Decomb is a great example of volunteerism at its best as is Avisynth. By its nature, commercial software is about active outreach and research to allow answering the needs of the largest potential user base. In general these separate needs are enough apart that the different development methodologies used do not tread upon the other.

Avisynth is, perhaps, another matter. What I mean by that is Avisynth itself might be considered a more general purpose delivery vehicle that is used by many different types of users with different destinations. The individual and vertical needs are actually manifested in the plugins/filters. I think avisynth has, or will have in the future, a large, multi-purposed user base whose individual needs are met by purpose built plugins. Those multi-purposed needs of the delivery vehicle might be better met with a devel plan that pro-actively (sorry :-)) considers the full spectrum of those needs rather than passively doing so.

So, what am I saying? Nothing much probably. Just some intuition, based upon experience, that tells me thoughts like this should be voiced so that the core team, at least, is presented with a varied set of views for their consideration. If the vast majority of all feedback to the devel team is based only upon ripping and their own enthusiasms are focused there, IMO, there is a real danger that, completely accidentally, the full avisynth community needs might not be fully considered.

That's all really. Take it for what it is worth. As I said, this was not meant to stir up any pookee. This is I hope still an open forum for the full flow of thoughts and ideas.

/edit: DG, thanks for adding the smiley and making more clear the last sentence. I thought I was going to get a one of those famous neuron-blasts :-)

sh0dan
18th March 2003, 19:37
Your concerns are noted.

1) I don't understand much of what's going on with 3.0. But a lot of work has to be done before a version is going there is going to be anything useable. I trust Bidoche and Richard to do this - I won't get involved with it until we have a stable 2.5. Problem is - I don't know what Bidoche is doing, how or why, but I trust him completely.
Users can comment and suggest stuff to devels - I'm much pro-user involvement, but it often results in "all-talk-no-code".
Users actually interested in designing the framework, should learn C, and become developers themselves.

Both 2) IMO you are wrong. We VERY much use the feedback here to find out about potential problems. I would have focused much more on the sound aspect of AviSynth, had it not been for the 95% focus on video in this forum. Most of the errors fixed are because of this forum - 90% of all features are added because they have been discussed here. I try to prioritize from what's being discussed here, and what I'm actually good at. From what I can see 80% of what's being discussed here is MPEG2 -> MPEG2 / MPEG4 transcoding. My usage at work is actually DV -> MPEG 1, and MPEG2 -> MPEG4 at home.


In general my thoughs on this are as such:

* I have a fairly high "ignore-level" - I would rather spend time coding than discussion minor stuff here. This might seem as arrogance, but instead of having useless arguments, I'd rather have some actual code. (YV12 <-> YUY2 conversion is a shining example - we now have some great conversion routines all because of user feedback, and people being highly motivated in helping out finding the right algorithms). Another issue is that some topics are simply not AviSynth issues, but rather a "usability" issue. If you want to argue, that AviSynth has become considerably easier to use within the last year, I hope that I am not the only one to disagree with you.

* Of course I prioritize the tasks after my preferences. I do not owe any bugfixes or features to anyone - so I - and I alone - decide when I get involved with an issue. If you want the code added - do it yourself - nothing is stopping you!

* That being said, it is no surprise that I'm not the big "system-designer-guy" - taking on almost the entire 2.5 development was tirering, and at times frustrating. At times you just get tired of people stating obvious bugs, and doing nothing but complain - on the other hand - cheers from people actually being able to use what you're doing can help you through these period.
But from working with people on longer development projects, this is just something to be expected.

ok - 'nuff babling for now.

PS. Don't forget Wilbert and WarpE - they are a crusial part of the dev. team with all their documentation work!

DDogg
18th March 2003, 20:32
Your concerns are noted.
That's all I could possibly ask and all I wanted to hear - thanks.
We VERY much use the feedback here to find out about potential problems.
Exactly. No argument. You have been super about doing that Edit/if those threads are of some interest to you /edit. My point was unless you get the feedback from a broad spectrum of users you can not respond. I wonder if a lot of the non ripper/video artsy types are too intimidated by the skill level of these forums to comment at times. That is not your problem, but if true, it denies the team of much needed feedback from those users. BTW, I did not know you were involved with DV at work. That is good news (to me).
If you want to argue, that AviSynth has become considerably easier to use within the last year, I hope that I am not the only one to disagree with you.
Don't know what you mean? I would certainly never argue that. I love 2.51
Of course I prioritize the tasks after my preferences. I do not owe any bugfixes or features to any... Exactly and as it should be. You are freely contributing your time and should do only those things that give you enjoyment, but again, there is my point, by the nature of that statement, certain areas (your individual preferences)will get more drive than others. That was all I was saying. That is the nature of the beast in volunteer devel. It becomes more so if and when all the volunteers have the same or very similar interests. I am not bitching about it in the least, just bringing up some of the inherent dangers, er, inherent effects might be the better word.
...taking on almost the entire 2.5 development was tirering, and at times frustrating.
My hat is off to you. As I said, and truly meant, you guys are real heroes to me. It is amazing what you have accomplished. I hesitated to post this as I was afraid you guys might take it wrong. I can see you did not and thanks for that.
PS. Don't forget Wilbert and WarpE -
The docs people are always the unsung heroes of devel. A critical but sometimes thankless task (I know from experience).

int 21h
18th March 2003, 21:07
I would say one of the most important things for 3.0 to establish is transparency. An Avisynth script should be treated no differently (in my mind) than an actual AVI. We know its possible, its already done with Link2 (http://www.videotools.net/index.php?rub=guides&htm=intro2link2.htm), I think others would agree that this should be a task high on the priority list.

DDogg
18th March 2003, 21:15
An Avisynth script should be treated no differently (in my mind) than an actual AVI.
God, that would be a most wonderous thing.

sh0dan
18th March 2003, 22:14
@int21h:

I would say one of the most important things for 3.0 to establish is transparency. An Avisynth script should be treated no differently (in my mind) than an actual AVI.

As would we all. The main problem is, that this would require some intermediate steps, which might as well be done by an external program (As Link2). There is nothing holding back 2.5 to be capable of this.
For this to be possible, it would also have to look like an AVI file. That would mean that there should be written a codec, that calls AviSynth. It would also mean that an AVI file would have to be written for each avisynth script - this cannot be done automatically, but could be done by something like vdubmod.

Unfortunately - making such software is far beyond my personal capabilities.
Anyway - the question is wether this should be a part of AviSynth itself, when it might as well be a standalone app.

@DDogg:BTW, I did not know you were involved with DV at work. That is good news (to me).
Actually I'm a video producer at a rather small company. I'm in charge of managing recording, editing and compressing fictional material for (corporate)educational purposes. So actually, when I'm not planning video shoots, I'm spending most of my time in Avid Express DV and After Effects. AviSynth processing and compression is only a small part of my job.
In my spare time I do programming for "relaxation" - it is nice to be able to focus on "simple" mathematical problems and algorithms. My programming background comes from doing "demos" (http://scene.org) - small realtime calculated presentations, mostly 2D and 3D effect-based. Hoax (http://www.back2roots.org/Demos/Files/Hoax%2C1/) / Cayenne (http://www.back2roots.org/Demos/Files/Cayenne%2C1/) are two of the best productions I've been doing - even though they seem to have problems running on modern JVM's (thank you Sun!).

DDogg
19th March 2003, 18:44
@Sh0dan, well that news about your occupation is even better. I don't think you have ever mentioned that before. Tell me, do you ever use AviSynth to serve to Avid or Afterefx? If so, do you have any specific scripts you find useful for DV?

BTW, I tried to figure out how to view the demos you mentioned but I guess my machine does not support the java or it is operator error on my part.

sh0dan
19th March 2003, 18:59
Tell me, do you ever use AviSynth to serve to Avid or Afterefx? If so, do you have any specific scripts you find useful for DV?

No - there is always a HuffYUV or an MJPEG inbetween - which is ok, considering that you need the fastest possible feeding, when doing the actual editing - otherwise it just adds up on each render/preview.

DDogg
19th March 2003, 19:42
Well, if you have not tried it, it might be worth your time. In Vegas, you do not notice a difference between using avisynth (vfapi wrapped) over huffy. I know this is suprising. Perhaps this is because of some smart buffering? It did surprise me how well it worked. I don't know much about Avid. It would be interesting to know if it would or how it worked with AviSynth.

/add BTW, I think I saw somewhere where you said you had changed avisynth to use 1/3 of the available ram for a buffer. Is this correct?

Bidoche
19th March 2003, 19:50
@DDogg

I would gladly accept any input/feedback one may give...
But apparently people don't feel they are concerned.
Nobody replied to the thread I made, I guess it may be a bit cryptic, but then they could say at least that. :/

Design decisions are what take the most of my time.
I mean when you know where you are going, the code come easily. Otherwise you write something, change your mind and globally stall...

For that, the discussion about frames types was really helpful.


@int 21h

I know nothing about this avi stuff, so I can't do it.

DDogg
19th March 2003, 19:58
@Bidoche, well remember that thread is in devel and of a highly technical nature. Even big mouths like me would not dare risk treading there :-) Hell, even Sh0dan said it was beyond him. Maybe later you could start a thread in usage to encourage more user feedback and wishlists. I would think that might be very helpful in prioritizing the devel framework and yes, count on me for feedback there. lol

/add: As much as I hated many of the aspects of the commercial devel structure, the framework architect was always one of the most critical to the teams. I wonder if that might be an area you guys should recruit? Coders, IMO, should not have to be involved in framework design unless it is an area they enjoy. Obviously they need to have a big part in the final say as to whether something is possible and worth the devel time, but I am not so sure if framework and coding are not somewhat exclusive of each other. After all, coders like to code, not yap about it.

Bidoche
19th March 2003, 21:46
It's not really that technical, at least not property collisions.

When you mix two (or more) frames, you have to check that they share some properties.
Generally colorspace but often width/height too...

The idea is that repeat these all the time is annoying (and inefficient), so I am thinking about integrating them in the property system. Then custom properties could be checked too.

The problem is what to do when properties disagree.
Example: if I allow to stack 'top' and 'bottom' frames (and should I allow it ?) how do I qualify the result ??
That's collision...

int 21h
20th March 2003, 04:45
The only way I could see an integration of the avi idea into Avisynth succeeding, would be that Avisynth itself would have the capacity to be a framehandler. A different application would generate the mock avi with the FourCC of AVIS, and framehandling would be offloaded to Avisynth (instead of making a 3rd party decoding mechanism such as Link2). The foundation for this already exists in VirtualDub and its frameserving mechanism...

Bidoche
20th March 2003, 11:54
I don't follow you, isn't framehandling already made by avisynth ?

ulfschack
20th March 2003, 14:08
I could absolutely NOT survive without the IPCSource capabilities in pre 1.06 versions when exporting the timeline from Premiere to various encoders (DVD/divx). My HD is simply not made for a 1 hour Huffy (not even intermediate DV). Besides, why should I waste my time with it. After all, frameserving (and filtering) is what Avisynth is all about, ain't it? So why not let us DV'ers in on the frameserving as well ... pretty please ?

I don't use avisynth for Audio. There simply are too many other options for it to be critical.

cheers

PS Especially now, when avisynth's handling of interlaced material has reached such maturety, I'm really pulling my hair in frustration that I can't use it.

DDogg
20th March 2003, 14:16
ulfschack, bear with my ignorance, but could you instruct me a little on "IPCSource capabilities"? I have never used Premiere much. Was this something taken out of avisynth? How was it used?

Wilbert
20th March 2003, 15:11
How was it used?
I don't know how it worked. The script is like this:

IPCSource(something)
filter(...)

"Premiere" will make this for you when selecting AviSynth frameserving in Premiere (of course you need the premiere export plugin installed for that). Then you adjust this avs file (adding filters and such) and open it in TMPGEnc or whatever.

Was this something taken out of avisynth?
Yes, that's a strange story ... AFAIK Edwin (who developed v1.05 and v1.06) had to take it out because he didn't want to give the sourcecode of the corresponding premiere plugin. But I don't understand why he got away with it, because he didn't make IPCSource (at least Ben already developed a version of IPCSource and premiere plugin, and Edwin improved it). Apologies if I'm misinformed.

ulfschack
20th March 2003, 15:15
Sure thing, if you'll bear with mine :)

IPCSource (Inter Process Communication ... in short frameserving) has been in Avisynth from as early as version 0.3. For Premiere there are a few good shareware wrappers that plugs right in.(see vcdhelp.com)

From Premeiere you have to activate the serving from the "export" option and choose the wrapper/server plugin you've installed, then type the name (f.i. "clip") and press ok.

Proceeding then to write an avisynth script that contains the line:
IPCSource("clip0")
...allows you to crop, split, weave and all that you ordinary do in Avisynth. Just like it would had you used Avisource. It's immensly useful. It's timesaving, spacesaving and qualitysaving since no rendering is done ... pure uncompressed video to the app of your choosing directly from Premiere.

Just say yes to IPCSource !! :)


cheers


[EDIT]

Wilbert beat me to the punch. Allow me to add that after 1.06 IPCSource was put in a plugin "AvisynthEX.dll". But since the (premiere) plugin needed to be replaced to encompass 2.0x compatability, I feared to change it since I had some hassle setting the whole thing up in the first place (a mixture of lazyness and ignorance). Besides 2.0x wasn't that appealing to me anyways. I'm still doing very well with 1.05 but feel the call from 2.5 growing stronger by the hour :)

DDogg
20th March 2003, 16:42
OK, some thoughts are starting to stir in my head. Let me posit a forest view and let's forget the trees (details) for a moment, and please, overlook my poor grasp of programming details for a few moments and me being somewhat presumptuous and overly wordy (its a curse I have :-)). This is about framework, big picture and potential possibilities.

Imagine for a moment an avisynth 2,x or 3.0 that had incorporated within the basic framework a concept of, as int 21h described it, transparency. This would be done by providing a standard, expressed within an SDK, that would allow any video software, both commercial and non, to interface out and in to avisynth. Sh0dan said in another thread that the IN (loading the avs script)is trivial (not a direct quote, just my sense of what he said). As well as the IN, the SDK would demonstrate how software writers could write an intermediate plugin that translated their output into a suitable format that would interface with Avisynth. This is the OUT. This might be a more robust and generic version of IPCSource? This SDK would be freely distributed, touted to anybody that would listen, and provide a worldwide STANDARD that would allow the potential of ALL video software being able to load and frameserve out via avisynth.

What developer would not jump on that opportunity to add the richness of avisynth to their video program if the SDK made it a trivial effort? Could not Avisynth then become a defacto standard for video Inter Process Communication? Was this where Ben was going and never got to???

Sh0dan, Bidoche, from what you have said, I know this is not an area of expertise for either of you. That's just a detail.I am more interested in whether you guys and Richard would "buy in" to the basic concept? If so, I would think that somebody with this expertise could be recruited to your team. You all seem very open minded so I would think you would welcome a person like that? What are your thoughts?

/add and query: a friend of mine mentioned their may be a problem with commercial developers interfacing with avisynth due to the GPL license. I admit I don't understand the GPL license very much, but would interfacing via their own plugin written to the avisynth SDK's specification violate it? int 21h, I seem to remember you know quite a lot about this subject :-) ?

int 21h
20th March 2003, 18:15
Avisynth does frame handling, but it doesn't posess the entries and functions to be used as a 'codec', which is what it would need.

Doom9
20th March 2003, 21:24
I guess ddogg's post came off the wrong way. I think he meant to say that for v3.0 it would be great if the potential userbase could be extended by providing facilities allowing more programs to process AviSynth output. Link2 sets an example there but I bet most of us would rather have an open source implementation.
Personally I think that would be a good idea, too, yet I see that this it's not necessarily the task of AviSynth to provide codec facilities or a Premiere plugin to input frameserved content.

DDogg
20th March 2003, 22:07
Avisynth does frame handling, but it doesn't posess the entries and functions to be used as a 'codec', which is what it would need.
I question part of this and I wonder if we are ALL not a little confused. I say this for the reason that, a few months ago, I downloaded an older editing program that had an "EXPORT TO AVISYNTH" option. So, how could that be? I will have to find it again, it got deleted with a HD crash. If memory serves me, it required 1.03 and I got an ipcsource error as I did not have an old version of avisynth laying around.

Are we absolutely sure some of this stuff was not built in to avisynth by Ben BEFORE it was tampered with /edit in 1.06 /edit? As for frameserving to another program, who needs another program to do that? From what Sh0dan said, if the programmer allows it, opening avisynth scripts directly is a no brainer. That is just a matter of education and providing the proper information to programmers unless GPL would come in to it although, as Doom9 said, an alternative to Link2 would certainly be appreciated by many.

int 21h
20th March 2003, 22:11
Some programs use a different mechanism for getting frames from their video sources (i.e. CCE 2.66), this extension of Avisynth wouldn't necessarily be codec functions as much as it would be an addition of the API necessary to truly emulate .avi files.

DDogg
20th March 2003, 22:36
Encoders are primarily interested in getting video into an encoder. Clearly there is another camp interested in getting video out of a commercial program via avisynth so that the appropriate standalone encoder can be used to fit the job instead of being locked into the internal encoders (never the best) of a program. This is probably not going to be an area of interest here, but I can still hope. It is very frustrating to think there may have been some of this work already done and that it was yanked out.

int 21h
21st March 2003, 04:35
Originally posted by DDogg
/add and query: a friend of mine mentioned their may be a problem with commercial developers interfacing with avisynth due to the GPL license. I admit I don't understand the GPL license very much, but would interfacing via their own plugin written to the avisynth SDK's specification violate it? int 21h, I seem to remember you know quite a lot about this subject :-) ?

You put a BSD-like license on the headers needed for the implementation, and then derivatives aren't required to GPL. That is how Edwin does closed-source Link2. However, as far as I know, there never was a BSD license on that portion of the code (only GPL), and Edwin's link into Avisynth for his closed-source, pay programs, (**USUAL int 21h DISCLAIMER HERE**) in my opinion was against the spirit of what Ben and Avery originally intended (Avisynth does borrow some code from VirtualDub) with their code, and in violation of the license agreement. But again, that's just my opinion, and Edwin becomes quite offended at its discussion, as history has demonstrated.

sh0dan
21st March 2003, 10:50
You CANNOT change the avisynth.h license from GPL to BSD-license!

You are in no way allowed to create a binary of avisynth (or ANY part thereof without) releasing the source code.

With permission from BenRG and us, people are allowed to interface with the existing avisynth.dll (with the functions defined in avisynth.h) - as a plugin or a GUI without releasing the sourcecode of your filter.
This is a deviation from GPL, which requires you to release the source of your plugin, when you interface with avisynth.dll.

So it is NOT allowed to modify avisynth.dll to fit your specific application _without_ releasing the sourcecode. When you release the sourcecode, you are allowed to copy and modify everything you like.

Regarding Edwin, I will not discuss him or his actions, as this happended before I began working on AviSynth. This is between him and BenRG, and other people developing AviSynth at the time.

DDogg
21st March 2003, 13:10
Sh0dan, sorry this thread became so convoluted. There is too much to read and I assume, too many questions, but I do hope you can find the time to at least look at some of them and if you could look at the older ipcsource code and let us know if that code makes any sense to you. Perhaps speak to the whole area of ipcsource? Is it possible to re-introduce it? Was there any information showing how to interface to it?

sh0dan
21st March 2003, 13:11
I will see what I can find! :)

WarpEnterprises
21st March 2003, 14:46
OT: me found something too: http://www-inst.eecs.berkeley.edu/~cs61a/images/Ben_Rudiak-Gould.jpg

milan
21st March 2003, 14:57
Link2 sets an example there but I bet most of us would rather have an open source implementation.


I'm working on this. Yesterday I've got the idea how I could implement something similar to link2 in ffvfw and Iv'e immediatelly started work on it. It's not finished yet, I have to create some GUI application for creating fake AVIs, but it seems to work with occasional crashes at exit. Only video is handled currently. Sources are in ffdshow CVS in ffvfw module.

BTW I've tried link2 only today to see that my idea was pretty close to link2.

P.S. Sorry for not responding to anyone for such a long time.

sh0dan
21st March 2003, 15:00
Milan - as always you work wonders! :cool:

milan
21st March 2003, 15:10
Thanks :)

The idea was simple: put Avisynth script or its file name as extradata after BITMAPINFOHEADER, and create fake avi with correct width and height and frames containg just frame numbers (this was required because AFAIK VFW doesn't provide current frame number when decoding). Then just create IScriptEnviromnent instance in ffvfw and let it call GetFrame with requested number. I choose AVIS FOURCC for the fake AVI, but I might try to imitate the exact link2 behaviour and set fourcc to WRPR.
I forgot to mention another limitation: currently only YV12 output is supported - this is because ffvfw works internaly only in YV12.

Wilbert
21st March 2003, 15:24
What a very nice surprise!!! Of course if you want us to test something, just drop a post.

sh0dan
21st March 2003, 15:27
Nice!

Regarding colorspaces, it would of course be a good idea to support all output formats. Any input format would also be optimal. XviD provides most conversion routines.

YV12 -> YUY2 - use AviSynth routines (if possible). These routines have better chroma upsampling, and optional interlaced handling.
There _must_ be an option to select interlaced conversion. Sort of: Use interlaced upsampling, if more than 'n' lines, would be best.
There would have to be special adaption if width is not mod-16, since AviSynth has larger pitch in these cases. I would be glad to help out here.

YV12 -> RGB - use XviD conversion routines. Unfortunately they are not qualitywise optimal, but they are fast and has support down to mod-8 width.
Interlaced upsampling is also a problem here.
A solution could be to use AviSynth YV12 -> YUY2 and also use AviSynth YUY2 -> RGB. This will be slower, but on the other hand it would be possible to properly support interlacing and have optimal chroma upsampling.

IMO any VFW codec should be able to output in YV12, YUY2 and RGB24/32, so it might even be a gain for ffvfw overall.

milan
21st March 2003, 15:32
I just want to prepare better tool for creating those fake AVIs and run few BoundsChecker sessions to catch some bugs. Most probably on monday I'll put ffvfw binary to SourceForge.

milan
21st March 2003, 15:40
@sh0dan:

OK, I'll try AviSynth colorspace conversion routines.

ffvfw supports many colorspaces on output, but the inner working (sufficient for mpeg4 codecs) is to proccess everything in YV12 and only after that convert to requested colorspace. I'll change ffvfw to internally handle at least YV12, YUY2 and RGB32.

sh0dan
21st March 2003, 16:01
Link to the latest convert_yv12.cpp (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/convert_yv12.cpp?rev=1.10&only_with_tag=MAIN&sortby=date&content-type=text/vnd.viewcvs-markup). If you need _any_ help I'd be happy to help you out with ffvfw.

There are MMX and ISSE YUY2 -> YV12 (interlaced and noninterlaced) and YUY2 -> YV12 (interlaced/non-interlaced).


Lastest XviD (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/convert_xvid.cpp?rev=1.1&only_with_tag=MAIN&sortby=date&content-type=text/vnd.viewcvs-markup) conversion routines - adapted for MASM, if they are of any help. No interlaced handling, and sub-optimal chroma interpolation.

The best way for ffvfw to handle this would probably to be able to pass through material, if possible, or use the simplest possible conversion - this does include much work though - but AviSynth has assembler routines for most of these.

|YUY2 -> RGB32 (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/convert_yuy2.cpp?rev=1.1&only_with_tag=MAIN&content-type=text/vnd.viewcvs-markup)| - |MMX RGB32 -> RGB24 (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/convert.cpp?rev=1.16&only_with_tag=MAIN&content-type=text/vnd.viewcvs-markup)| - |MMX YUY2 -> RGB24/34 (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/convert_a.asm?rev=1.4&only_with_tag=MAIN&content-type=text/vnd.viewcvs-markup)|

trbarry
21st March 2003, 16:26
Milan -

Great to hear you are working on this! :)

- Tom

int 21h
21st March 2003, 17:42
Sorry, I think that came out wrong, because I didn't that anyone should just modify it without talking to someone first.

Originally posted by sh0dan
You CANNOT change the avisynth.h license from GPL to BSD-license!

You are in no way allowed to create a binary of avisynth (or ANY part thereof without) releasing the source code.

With permission from BenRG and us, people are allowed to interface with the existing avisynth.dll (with the functions defined in avisynth.h) - as a plugin or a GUI without releasing the sourcecode of your filter.
This is a deviation from GPL, which requires you to release the source of your plugin, when you interface with avisynth.dll.

So it is NOT allowed to modify avisynth.dll to fit your specific application _without_ releasing the sourcecode. When you release the sourcecode, you are allowed to copy and modify everything you like.

Regarding Edwin, I will not discuss him or his actions, as this happended before I began working on AviSynth. This is between him and BenRG, and other people developing AviSynth at the time.

DDogg
21st March 2003, 18:48
milan, first, thanks for considering this. Those of us who have a strong need to interface avisynth with commercial programs will be in your debt.

Second, just a question. Could the techniques you mention possibly allow or be adapted to allow, "Inter Process Communication",i.e., output from a commercial program (properly interfaced)to be directed to avisynth so it could process and frameserve the data to another standalone application without an intermediate file? Or, is this a completely different beast?

sh0dan
21st March 2003, 18:58
It cannot be done as a codec - any VFW application will require random access to frames. The problem is that all application delivers frames linearly, and there si no way for the codec to request any given frame.

So unless an exporter is written for each app, this will not be possible.

DDogg
22nd March 2003, 02:03
So unless an exporter is written for each app, this will not be possible.
Well, my hope is when you get a chance to look at ipcsource that some clues may be there. You know, Ben must have been one heck of a smart guy to have already thought this out years ago.

sh0dan
22nd March 2003, 05:45
Trust me - Ben's work is not for children to watch :)

Even though we find bugs now and then - his brilliant design of Avisynth still shines through - as great inspiration indeed!

ulfschack
24th March 2003, 13:56
Yes, a new server has to be written for every app for it to work, but such plugins and servers allready exists. Premiere for one has a couple ready and waiting. It doesn't care whether it serves to avisynth 0.3, 1.05 or 2.5 as long as it can take care of the IPSsource handle ... or does it? Please enlighten?

As i give it a little closer thought Plugin and avisynth version probably IS dependant. For why else do I get "wrong server version" when trying it from 2.0x ... hmm

Please forgive my ignorance. It's just that IPCsource is not discussed on a heck of a lot of places, so I just grab the opportunities when can :)

cheers

Wilbert
24th March 2003, 14:27
Yes, a new server has to be written for every app for it to work, but such plugins and servers allready exists. Premiere for one has a couple ready and waiting. It doesn't care whether it serves to avisynth 0.3, 1.05 or 2.5 as long as it can take care of the IPSsource handle ... or does it?
Yes it does, but I don't know why. Maybe it is easy to change the source code of this server, but I'm not a programmer :) The original plugin of Ben works only with 0.3. If you want to use it with v2.0x, you have to download premiere video server plugin 0.951 and avisynthex.dll v1.1 (download here (http://www.videotools.net/uk/download.php?PHPSESSID=b4f4623b21eccde25db6429564a7384e)). This version should work both with v1.0x and v2.0x (and not with v2.5x). However:

1) You can use it for 30 days, without paying anything.
2) During those 30 days it is limited to 5fps (something like that).

ulfschack
26th March 2003, 12:08
Thanks for the info Wilbert. Given the circumstances I think I'll stick to the older server plug-in that interfaces to 1.05. This server all it does is pop up a window about optional registering, but is not hampered by speed restrictions in any way. If you want me to I could find out more about version number, author and download link ...

cheers