View Full Version : Humbly requested: Filter SDK / Easy filter sample
redfordxx
22nd December 2006, 16:43
If you don't want to go through the hassle of getting and installing the platform SDK just to get the aligned malloc/free, then you can use the code for those functions to be found in the file alloc.cpp contained in the DGDecode source zip (part of DGMPGDec).
:thanks:
That will work better than my first attempt:
First (2weeks ago) I wanted to download the new malloc include file. But it wanted another include and that one another... so I stopped after certain recursion depth;)
Fizick
22nd December 2006, 17:12
redfordxx,
no, at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm
is NEW SDK not-compatible (officially) with VC6.
redfordxx
22nd December 2006, 20:29
redfordxx,
no, at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm
is NEW SDK not-compatible (officially) with VC6.
Are you sure?
Because the new "Windows® Server 2003 R2 Platform SDK Full Download" is supposed to be 400MB and this is 323MB. And the last update date says February 2003.
Fizick
22nd December 2006, 21:03
No, I am NOT sure :)
Probably you a right.
redfordxx
23rd December 2006, 03:24
Neuron2,
I want to use your alloc.cpp.
However, after copying into project dir, adding to project source files, on compiling it writes
error C2065: 'aligned_malloc' : undeclared identifier
I see it in the workspace class view.
#include won't help because then it writes that the declarations are twice...
And same for my other functions.
What's wrong?
Guest
23rd December 2006, 04:03
You need a prototype for the function for any code that wants to call it. Put this in your global header file or make sure that any code that wants to call aligned_malloc() sees this prototype:
extern "C" void *aligned_malloc(size_t size, size_t alignment);
You'll also need a prototype for aligned_free().
Your C/C++ skills need brushing up if you don't know about function prototypes.
redfordxx
23rd December 2006, 04:29
Thanks!
BTW...there is nothing to brush up, that's why I am in the simplesample thread:p
redfordxx
1st January 2007, 05:44
If you don't want to go through the hassle of getting and installing the platform SDK just to get the aligned malloc/free, then you can use the code for those functions to be found in the file alloc.cpp contained in the DGDecode source zip (part of DGMPGDec).
As I looked at alloc.h, I also looked at the functionYV12PICT* create_YV12PICT(int height, int width, int chroma_format)
{
YV12PICT* pict;
pict = (YV12PICT*)malloc(sizeof(YV12PICT));
int uvwidth, uvheight;
if (chroma_format == 1) // 4:2:0
{
uvwidth = width>>1;
uvheight = height>>1;
}
else if (chroma_format == 2) // 4:2:2
{
uvwidth = width>>1;
uvheight = height;
}
else // 4:4:4
{
uvwidth = width;
uvheight = height;
}
int uvpitch = (((uvwidth+15)>>4)<<4);
int ypitch = uvpitch*2;
pict->y = (unsigned char*)aligned_malloc(height*ypitch,32);
pict->u = (unsigned char*)aligned_malloc(uvheight*uvpitch,16);
pict->v = (unsigned char*)aligned_malloc(uvheight*uvpitch,16);
pict->ypitch = ypitch;
pict->uvpitch = uvpitch;
pict->ywidth = width;
pict->uvwidth = uvwidth;
pict->yheight = height;
pict->uvheight = uvheight;
return pict;
}I am sorry with my small knowledge if I miss something, but...
Isn't bug there that in case 4:4:4 is wrong pitch and incorrect malloc?
Sorry it's off topic here but it is kinda reply to a post here.
I will delete it if you consider it suitable.
Guest
1st January 2007, 05:53
Why do you think it is wrong?
redfordxx
1st January 2007, 05:58
uvwidth = width;
int uvpitch = (((uvwidth+15)>>4)<<4);
int ypitch = uvpitch*2;
that means?
int ypitch = (((width+15)>>4)<<4)*2;
redfordxx
1st January 2007, 06:05
maybe could be
YV12PICT* create_YV12PICT(int height, int width, int chroma_format)
{
YV12PICT* pict;
pict = (YV12PICT*)malloc(sizeof(YV12PICT));
int uvwidth, uvheight,hshift,vshift;
if (chroma_format == 1) // 4:2:0
{
hshift = 1;
vshift = 1;
}
else if (chroma_format == 2) // 4:2:2
{
hshift = 1;
vshift = 0;
}
else // 4:4:4
{
hshift = 0;
vshift = 0;
}
uvwidth = width>>hshift;
uvheight = height>>vshift;
int uvpitch = (((uvwidth+15)>>4)<<4);
int ypitch = uvpitch<<hshift;
pict->y = (unsigned char*)aligned_malloc(height*ypitch,16<<hshift);
pict->u = (unsigned char*)aligned_malloc(uvheight*uvpitch,16);
pict->v = (unsigned char*)aligned_malloc(uvheight*uvpitch,16);
pict->ypitch = ypitch;
pict->uvpitch = uvpitch;
pict->ywidth = width;
pict->uvwidth = uvwidth;
pict->yheight = height;
pict->uvheight = uvheight;
return pict;
}
... If I know correctly what does << and >>
Guest
1st January 2007, 06:06
Yes, you are correct. I don't think it's a bug per se, however, because it apparently doesn't break anything. It just allocates more memory than it needs to. I'll try to check that, but I don't have any 4:4:4 source material and I don't know who wrote that code, although I know tritical modified it.
redfordxx
1st January 2007, 06:11
Yes, you are correct. I don't think it's a bug per se, however, because it apparently doesn't break anything. It just allocates more memory than it needs to. I'll try to check that, but I don't have any 4:4:4 source material and I don't know who wrote that code, although I know tritical modified it.
Yes doesnot break...but it could double slow down the speed of processing luma if there is some cycle for (i=0;i<pict->ypitch...
Richard Berg
18th January 2007, 03:58
Hi,
I prepare draft version of avisynth license text, and after some discussion with IanB I put it to CVS tree at docs/english/license.htm
Please look and comment/edit.
The most unclear for me is documentation status (offline and online).
Can I ask, why you select Attribution-NonCommercial-ShareAlike 2.5 for wiki? (and not GNU FDL for example)
I hope, we will see avisynth.org soon.
The revised avisynth license looks great.
--------------------------------------------------------
The SDK license looks technically correct -- it gives the proper license for each part. But I think the overall intent is very hard for users to discern. All they want to know is: does my plugin have to be GPL? Right now it's hard to answer without poring over the details of the various sub-licenses.
My personal opinion is we shouldn't restrict plugin developers at all. I'd be fine with the SDK in the public domain or very liberally licensed (BSD style), so long as we keep the friendly "please consider our community" section at the bottom. If truly we want SDK users -- including companies -- to follow the GPL, we should use persuasion instead of force. Sell them on the merits of free software. Encourage them to share the code here so we can answer questions. Convince them that the contributions they'll receive from others are worth giving up some control. And if they still want to keep it closed after all that, so be it: a closed plugin is better than nothing. Ben & Avery seem to share this viewpoint.
In reality, it looks like SimpleSample, IanB's contributions, and (possibly) the avisynth 1.0 documentation are GPL. What does that mean for plugin developers? I'm not sure. There is no apparent boundary line between the SDK documentation text and the SDK sample code, so it's very hard to know what is allowed. I propose we separate the text vs code licenses, then write a new preamble that makes the answers clear.
----
SDK text should be Attribution-NonCommercial-ShareAlike. Why not GFDL?
(a) The CC licenses are very simple. Virtually everything you need to know is in the name. GNU licenses are complicated and carry a lot of baggage (both ideology and perception -- it turns off many people who dislike Stallman/GNU project for whatever reason).
(b) MediaWiki uses CC.
(c) I like Larry Lessig a lot more than Richard Stallman.
Result: anyone can read the SDK text and do whatever they want with that info. Only if they are modifying or redistributing the text itself do they need to attribute the authors, not be commercial, and redistribute their changes under CC. [this summary, or something like it, should go in the license preamble]
-----
SDK code needs a license. For consistency & sanity we should re-license and distribute all SDK code under the same license. Ideally that would be BSD. However, there is lots of GPL code in it already, and some of you disagree, so for that to happen we'd need a lot of discussion. The path of least resistance would be to apply the GPL + avisynth.h exception to everything.
Assuming we go down that path, the result: plugin developers who modify or redistribute the SDK code obviously need to contribute their changes back to us and make them GPL. As for plugin developers who want to paste parts of the SDK code into their own code, they would have to consult a lawyer to see whether the parts they copy are copyrightable or trivial. [this summary, or something like it, should go in the license preamble]
Having worked in commercial software for awhile, here's how I see the GPL scenario playing out. Large companies will not touch the SDK with a 10ft pole; no matter what they do, the chance of being sued is too high. Small companies won't bother to consult a lawyer; they'll simply copy/paste at will. Since the SDK code is so fundamental they know they won't be caught (bits generated by SDK code look the same as bits generated by virtually any other plugin that follows the avisynth.h interface) -- and if they are caught, they'll claim they only copied parts that are trivial/uncopyrightable. Hopefully you can see why I don't consider GPLing the code to be helpful.
Fizick
18th January 2007, 19:28
Richard Berg,
thanks for answer and for restoring of avisynth.org today! :)
At least I know text of "GettingStartedWithAudio" article from FilterSDK (but I still do not know who wrote it, probably sh0dan?)
----------------------
Generally I agree with most part of your opinion.
(preable could be useful).
Here is my "disagree" part:
1) IMO, SDK may be free for Avisynth plugin developers, but not for complitely "any use".
We must not permit freely use the SDK for non-avisynth (e.g. photoshop, etc) plugins
or to create some close source host aplication instead of avisynth (using avisynth plugins).
---------------------------------
2) I do not see any reason to put SDK text under some additional complex (CC or other) license.
It may be under GPL (if somebody want) or "free for any use", BSD (like sh0dan and Avery say).
main rule: whole SDK content must be GPL-compatible.
It is very closely related to avisynth code.
And certainly SDK text should NOT be Attribution-NonCommercial-ShareAlike!
Big question is "NonCommercial. You may not use this work for commercial purposes."
1. Suppose somebody put Avisynth 2.5.7 distribution package to magazine CD and sell it.
It may do it with avisynth, but it can not do it with "CC-noncommercial" portions.
2. Suppose somebody use Avisynth for commercial film-production. He may use avisynth for this,
but he may not "use" (read ?, citate) Avisynth and FilterSDK documentation?
3. Suppose someboby publishes an review article (electronic or on paper), he cited some avisynth doc text there.
He can not get royalties for his article?
General opinion, that Non-Commercial is NOT FREE license.
MediaWiki uses CC.
You say about wikimedia.org or Avisynth.org MediaWiki?
If you say about compatibility with Avisynth.org MediaWiki, here is my opinion:
current Attribution-NonCommercial-ShareAlike license is wrongly declared. :(
We at least could use "Attribution-ShareAlike 2.5" license for Avisynth.org MediaWiki, which permits commercial usage. Or "Attribution-By", or GNU FDL.
And any of CreativeCommon license is not simple.
Full text of license is very complex:
http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode
So called human-readable summary is not license, but some kind of preamble.
http://creativecommons.org/licenses/by-nc-sa/2.5/
This topic was discussed at another thread though (in usage forum).
http://forum.doom9.org/showthread.php?t=105205&page=5
My suggestion is to change mediwiki declared license to more appropriate (and correct). From my private and public discussion, it is be GNU Free Documentation License (used in wikipedia).
I do not like GNU FDL though. It is complex to use.
I know about more simpler draft:
http://gplv3.fsf.org/comments/gsfdl-draft-1.html
But it seems, various CC licenses are more useful for media (phonerecord, movie, photo images, etc) created by artists.
GNU FDL is more useful for text documents. Both SDK and whole avisynth documentation is mainly text, not images.
And this images are used for illustration only, not as creatve work - DVD or other capture frames is usually not under our copyright :).
Some CC license could be useful, if we use some content from other wiki (under CC) or put some content to it.
Bu I do not see any such case.
Most text wiki (like wikipedia) is under GNU FDL (without invariant sections, cover text, ...)
May be more approriate is some sort of CC Atribution-BY (rather complex, see http://creativecommons.org/licenses/by/2.5/legalcode) or BSD-like "any use" license for Avisynth doc.
It must be decision of all avisynth documentation authors,
of course.
Richard Berg
18th January 2007, 20:49
1) good point. I don't know how we can fit that requirement into GPL, BSD, or other existing licenses though. We may need to abandon them and just write a new one that says exactly what we want.
2) you're right, we definitely need to remove NonCommercial. I have not read the GFDL in a long time, my memory of it may be bad (I thought it was more restrictive than CC), will investigate.
Wilbert
18th January 2007, 21:35
At least I know text of "GettingStartedWithAudio" article from FilterSDK (but I still do not know who wrote it, probably sh0dan?)
Yes, it's Sh0dan who wrote this.
@Richard,
2) you're right, we definitely need to remove NonCommercial. I have not read the GFDL in a long time, my memory of it may be bad (I thought it was more restrictive than CC), will investigate.
1) Declaring it CC is not allowed without everyone's (every contributer) approval. This must be cleared up. We should get the approval of the main contributers or change the license.
2) Sh0dan (at least that's what i understood from Fizick) and I prefer GNU FDL as the documentation license. So we would like to get everyone's opinion about this.
GSFDL look also fine too me:
http://gplv3.fsf.org/sfdl-draft-2006-09-26.html (at least at first sight, i didn't read everything thouroghly)
Fizick
18th January 2007, 22:33
Richard Berg,
The current "avisynth.h" license is probably fine ?
But I an not lawyer.
Wilbert,
GSFDL is still in draft.
my (and IanB) opinion: we (you) must decide,
1) what are we want to permit, and what to do not.
2) Are we need in some inter-change with others (wikipedia, etc). or not.
Then we can select approriate license.
May be different part of documentation may have diferent licenses.
(core filters, syntax - more strict to preserve,
faq, scripts at WiKi - more free to change by users).
We (and users) generally need in not in free but in correct documentation.
Fizick
19th January 2007, 19:01
When I discuss (FilterSDK doc) with sh0dan, he said, that for documentation he prefer less restrictive license than GPL, and say about FDL.
But I am not shure that he ever read whole FDL text. :)
It has many restrictions too.
Generaly,
CC Attribution-ShareAlike, GNU FDL and GNU GPL are very similar in a spirit (free, copyleft) but different in details.
Richard Berg
20th January 2007, 00:58
I like the GSFDL.
Fizick
20th January 2007, 03:20
There is also draft of new GNU FDL v.2 license
http://gplv3.fsf.org/comments/gfdl-draft-1.html
with section:
8a. SFDL RELICENSING
If the Work has no Cover Texts and no Invariant Sections
then you may relicense the Work under the GNU Simpler Free Documentation License.
8b. WIKI RELICENSING
If the Work was previously published, with no Cover Texts, no Invariant Sections,
and no Acknowledgements or Dedications or Endorsements section,
in a system for massive public collaboration under version 1.2 of this License,
and if all the material in the Work was either initially developed
in that collaboration system or had been imported into it before 1 June 2006,
then you may relicense the Work under the GNU Wiki License.
Secret Gnu Wiki license was not published and may be will not.
new CreatioveCommons v.3.0 exist in draft too.
But they all are not legally compatible.
I repeat the question:
Are we need in compatibility with some sites under some specific licenses? Like technical review, etc.
Seems "Advanced Topics" only (possible).
Wilbert
20th January 2007, 14:44
I repeat the question:
Are we need in compatibility with some sites under some specific licenses? Like technical review, etc.
Seems "Advanced Topics" only (possible).
Could you elaborate a bit on what you mean here? Are you referring to some quoted stuff in some of these articles (quoted pieces from other websites)?
my (and IanB) opinion: we (you) must decide,
1) what are we want to permit, and what to do not.
(...)
May be different part of documentation may have diferent licenses.
(core filters, syntax - more strict to preserve,
faq, scripts at WiKi - more free to change by users).
We (and users) generally need in not in free but in correct documentation.
In my opinion everyone should be allowed to edit the documentation. Precisely because of the reason you say ... "correct documentation". I've seen a lot of useful corrections in the past by anonymous people.
2) Are we need in some inter-change with others (wikipedia, etc). or not.
Then we can select approriate license.
Yes that's a good one. Some issues (note that I haven't thought about this very well ...):
1) Users should be able to freely use and quote scripts from the official documentation. So scripts shouldn't and can't be licensed, because we "borrowed" many of them from the community.
2) As far as i know, there is no inter-change between wikipedia and official documentation. So it shouldn't be a problem if these licenses are not compatible. Of course there are problems with other sites (Japanese (avisynth.info) and Russian translation for example). I guess those need to be licensed too?
Fizick
20th January 2007, 18:52
Could you elaborate a bit on what you mean here? Are you referring to some quoted stuff in some of these articles (quoted pieces from other websites)?
...
As far as i know, there is no inter-change between wikipedia and official documentation. So it shouldn't be a problem if these licenses are not compatible.
Sorry my wrong wording.
Yes, in both cases I say about sites like wikipedia here.
Generally, some "standard" license give us compatibility (by quoting, and to be quoted) with some video-related sites.
2) Of course there are problems with other sites (Japanese (avisynth.info) and Russian translation for example). I guess those need to be licensed too?
Re-licensed?
Japanese (translate from mediaWiki) is currently under CC Attribution-NonCommercial-ShareAlike,
Russian (translated from off-line doc) is under GNU GPL :rolleyes:
If we try find some common, it is only BSD-type all-permission attribution license (or public domain).
In my opinion everyone should be allowed to edit the documentation. Precisely because of the reason you say ... "correct documentation". I've seen a lot of useful corrections in the past by anonymous people.
Of course, all doc parts may have the same free license.
IMHO: But some (core) parts may be editable at Avisynth Wiki by more limited number of people (developers).
These parts may be freely (under license) qouted-edited-distributed somewhere else, at forums, some other (not-official) sites and in articles.
1) Users should be able to freely use and quote scripts from the official documentation. So scripts shouldn't and can't be licensed, because we "borrowed" many of them from the community.
Lets try to analyze...
Scripts are generally published here at doom9 and similar forums and in plugins documentation.
Forum posting here (at doom9) is not under any license, so scripts are just copyrighed ?
But all scripts may be free used by anybody under "fair use" rule (for education, discussion, etc) without any additional license.
Some complex scripts and its decription are not (generally) "public domain", and we must ask its authors to reproduce and distribute (with attribution) them under new license. The best case if author put it to Wiki himself.
But on the other hand, all scripts usually :) consist of avisynth core and plugin functions calls, so they are (probably) may be considered as derivative works from avisynth, plugins and its documentation, and must be under same license (copyleft, shareAlike rule).
So, we (avisynth developers) may distribute these scripts under this license.
We need in users opinion here.
But I hope they will agree with any smart license.
IMHO, new avisynth documentation license must be set as a default license for wiki (and CVS off-line doc?), but some portions may be under other explicit license (for example, FilterSDK, some plugins documentation, etc).
Richard Berg
20th January 2007, 20:57
Forum posting here (at doom9) is not under any license, so scripts are just copyrighed ?
On most forums, when you sign up you agree that either your posts become (c) owned by the forum, or you have to grant the forum a perpetual license.
But on the other hand, all scripts usually consist of avisynth core and plugin functions calls, so they are (probably) may be considered as derivative works from avisynth, plugins and its documentation, and must be under same license (copyleft, shareAlike rule).
This is definitely not true. If I write a Python script I don't have to license it under the Python license.
Fizick
21st January 2007, 00:23
Richard Berg,
may be it is true on some forums, but not at forum.doom9.org,
I do not know any rule for license grant to this forum.
Registration to this forum is free! We do insist that you abide by the rules and policies detailed below. If you agree to the terms, please check the 'I agree' checkbox and press the 'Register' button below. If you would like to cancel the registration, click here to return to the forums index.
Although the administrators and moderators of Doom9's Forum will attempt to keep all objectionable messages off this forum, it is impossible for us to review all messages. All messages express the views of the author, and neither the owners of Doom9's Forum, nor Jelsoft Enterprises Ltd. (developers of vBulletin) will be held responsible for the content of any message.
By agreeing to these rules, you warrant that you will not post any messages that are obscene, vulgar, sexually-oriented, hateful, threatening, or otherwise violative of any laws.
The owners of Doom9's Forum reserve the right to remove, edit, move or close any thread for any reason.
About scripts. It is important question.
I do not know about Python. Probably AvsP editor is written with Python. AvsP code is released under GNU GPL.
What if you use some other script (copyrighted under some copyleft license) as a base for your script?
Usually compilators (like Python or VisualC) have a license permission to create user program under any license (but user can not redistribute documentation).
wonkey_monkey
17th June 2007, 13:32
Could someone post step-by-step instructions on compiling simplesample 1.0b with VC++ 2005 Express Edition? There are some at http://avisynth.org/mediawiki/Filter_SDK/Compiling_instructions but they seem to be out of date, since there is no "file->new->win32 dynamic link library" in VC++ 2005 EE.
I've installed VC++ 2005 EE and the Platform SDK, but when trying to build simplesample (after making some educated guesses on how to get to that point), it can't find windows.h, which is in the Platform SDK - do I have to copy it from somewhere to somewhere else?
Alternatively, since I don't really know C++ but have passable knowledge of C, is there such a thing as a simplesample for C plugins?
David
Fizick
17th June 2007, 15:13
david, please create this step-by step instruction yourself!
It will be useful.
But here is some draft.
Install VC 2005 Express
Enable Win32 C code project options by editing some option files with notepad. see procedure at Miscrosoft VC Express page - http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
Install Platform SDK.
Ther are two ways to compile plugin:
1. Start from existant vc6.0 project and convert it to VC8 project. Siply open SimpleSample.dsw and agree to convert.
2. Start from scratch.
Consider second option: start from scratch.
Start VC express.
Menu: fiIe -> Create new project.
Select Win32 console appication.
Enter name of your new project and press OK.
You will in Win32 Appcilation Wizard.
Press Application Settings (left panel).
Select Application Type as DLL (but it may be console too).
At Additional options select "Empty project"
Add or create files (avisynth.h, simplesample.cpp).
Get to menu: Tools - Options. Open section "Project and solutions", select "VC++ directories".
See list "Show directories for":
Add new items
C:\Program Files\Microsoft SDK\Bin to "Executable files",
C:\Program Files\Microsoft SDK\Include to "Include files"
C:\Program Files\Microsoft SDK\Lib to "Library files"
wonkey_monkey
17th June 2007, 16:50
Thanks Fizick, I'm now able to compile simplesample into a working DLL :cool:
:thanks:
David
Fizick
17th June 2007, 18:43
I updated http://avisynth.org/mediawiki/Filter_SDK/Compiling_instructions a little
please check/correct/ask
I do not use VC8 for plugins. I can use crazy config with VC2005 shell but with vc2003 compler (I hate manifest).
(I added a dirs, and remove unicode options for project service files)
wonkey_monkey
17th June 2007, 21:18
I didn't perform this step:
Update the corewin_express.vsprops file.
But was able to compile SimpleSample with no problems.
David
Fizick
18th June 2007, 05:49
do you convert simplesample.dsw file or create new project?
wonkey_monkey
18th June 2007, 09:54
Ah, I started a new project, it seemed to be the neatest thing to do.
David
wonkey_monkey
8th October 2009, 23:31
So I'm back to developing Avisynth plugins after a long absence, which meant a new install of VC++ 2008 Express.
http://avisynth.org/mediawiki/Filter_SDK/Compiling_instructions is a slightly confusing page, but it indicates (as does http://avisynth.org/mediawiki/Filter_SDK/SDK_necessaries) that the Microsoft Platform SDK (now superceded by Windows SDK for Windows Server 2008 and .NET Framework 3.5) is necessary. As it's a 100mb+ download I decided to give it a try without, and was able to compile simplesample just fine.
Was whatever was needed included in the VC++ 2008 download, or is simplesample so simple that it isn't necessary?
David
Varies
15th March 2010, 10:52
Hi 2 all ^ ^)
Q1:how to return additional variable from generic video plugin?
Q1:how to resize frame (not info like vi) in generic video plugin?
thx!
Varies
IanB
15th March 2010, 21:54
Oh! 2 questions 1's :p Q1:how to return additional variable from generic video plugin?
Generally functions only return 1 AVSValue. It's the way of the script syntax.
It is possible to update the content of a Global variable, use env->GetVar(const char* name) and env->SetGlobalVar(const char* name, const AVSValue& val) to access it, to allow some level of script sanity pass in the name as one of the function arguments, but all this is somewhat clunky.
Although unsupported at the script level it is possible to return an Array type as your 1 AVSValue. Of course this can only be between consenting filters in private, and will require some cleverness to unwrap what the parser does with returned arrays.
Why do you think you need to return more than 1 answer to a script function? :confused:
Q1:how to resize frame (not info like vi) in generic video plugin?
I take it this means you would like to use an internal resizer as part of your processing.
Use env->Invoke(const char* name, const AVSValue args, const char** arg_names=0) within your plugins creator routine to establish additional branches in the graph.
You need to provide some more details of what you wish if you need more help.
Varies
16th March 2010, 04:42
IanB
Thanks man!
I had a problem with internal frame resize, that why i want return variables [left,top,right,bottom] in script and resize there.
also, at filters_sdk_page written thats Invoke not good b'cos filter call its every time when its need (in my way its every frame)...in the end, i try Invoke few weeks ago (http://forum.doom9.org/showthread.php?t=151755) and had only black picture :(
IanB
12th February 2011, 22:53
Below is some commented out code from your source.
Problem 1 is you GetFrame(1) you should be GetFrame(n).
Problem 2 is your Targs array is only 3 it should be 7.
Problem 3 is the subgraph is transient, you make a new one every frame. No point in having the cache.
Problem 4 is the AsClip on the argument causes an extra cast.
AVSValue Targs[3] = { child, width, height, left, top, right, bottom};
PClip croped = env->Invoke("BilinearResize",AVSValue(Targs,3)).AsClip();
AVSValue args[1] = { croped };
croped = env->Invoke("InternalCache",AVSValue(args,1)).AsClip();
croped->SetCacheHints(CACHE_RANGE,3);
dst = croped->GetFrame(1,env);
cretindesalpes
7th June 2011, 00:13
Sorry if the question has already be answered, but I couldn't find any clue on Doom 9:
How avisynth.h for avisynth 2.6.0 (AVISYNTH_INTERFACE_VERSION = 5) is supposed to work?
The functions are no longer defined in the header, so including it leads to big linker complaints. Should I add the .cpp files from the Avisynth CVS to my plug-in projects? It seems there's a lot of dependencies.
Also, what about the compatibility between 2.5 and 2.6 plug-ins/hosts? Some classes have been extended by adding new functions, will they be binary-compatible with the previous versions? In other words, will plug-ins compiled with the 2.6 SDK work on Avisynth 2.5.8?
Basically, I'd just like to fully support the new planar colorspaces. Currently with the 2.5 SDK, I'm comparing the chroma plane sizes to the first plane to determine what is the chroma subsampling, and check the bits per pixel to know if clip is Y8, but this is not very convenient. Moreover, I have to wait for a PVideoFrame to know these information.
How avisynth.h for avisynth 2.6.0 (AVISYNTH_INTERFACE_VERSION = 5) is supposed to work?
Pretty much the same as before. There is supposed to be no more baked code, this code is now supposed to be in Avisynth.dll so as it gets changed, recompiling all of the plugins is not required.
The functions are no longer defined in the header, so including it leads to big linker complaints. Should I add the .cpp files from the Avisynth CVS to my plug-in projects? It seems there's a lot of dependencies.
As yet the linkage component is still being written. For trial purposes you could include interface.cpp to resolve the linkage problem.
Also, what about the compatibility between 2.5 and 2.6 plug-ins/hosts? Some classes have been extended by adding new functions, will they be binary-compatible with the previous versions? In other words, will plug-ins compiled with the 2.6 SDK work on Avisynth 2.5.8?
No, a 2.6 plugin will need a 2.6 environment. The 2.6 environment fully supports 2.5 plugins for 2.5 features.
Basically, I'd just like to fully support the new planar colorspaces. Currently with the 2.5 SDK, I'm comparing the chroma plane sizes to the first plane to determine what is the chroma subsampling, and check the bits per pixel to know if clip is Y8, but this is not very convenient. Moreover, I have to wait for a PVideoFrame to know these information.
The VideoInfo structure is what defines the shape of a clip. The pixel_type bits are pretty stable so you could hoist those bit definitions as a quick work around.
cretindesalpes
7th June 2011, 09:20
OK, thanks for your reply.
I started with SimpleSample and I want to change the output color-space. I do not mean use some avisynth function to convert, but take RGB values, do something with them and then return them as YV12 values.
I´m not sure that only
vi.pixel_type = vi.CS_YV12;
inside the constructor works/is enough. I´m using Avisynth 2.6.
IanB
22nd June 2011, 00:55
...
input_pixel_type = vi.pixel_type; // Remember for later use in GetFrame()
vi.pixel_type = VideoInfo::CS_YV12;
...
Found the problem. I´m using YV24 as output color-space and I expected to have it the same width/height as RGB24, but width of all planes is only the half. What I´m I doing wrong?
Gavino
22nd June 2011, 16:11
I´m using YV24 as output color-space
In that case, are you setting vi.pixel_type to VideoInfo::CS_YV24?
Now I found the solution: I found out it was actually 3 times smaller than the input, then it was clear, the name "src_width" in SimpleSample is misleading, because it is the rowsize not the width.
Wilbert
22nd June 2011, 22:33
Now I found the solution: I found out it was actually 3 times smaller than the input, then it was clear, the name "src_width" in SimpleSample is misleading, because it is the rowsize not the width.
It is the width measured in bytes (instead of pixels) :)
const int src_width = src->GetRowSize();
Mini-Me
1st August 2011, 14:36
I'm trying to learn Avisynth plugin development. My first plugin is compiling and linking correctly, but Avisynth isn't loading the .dll correctly. I'm getting Avisynth open failures with an 0x7e error in LoadPlugin. I tried compiling SimpleSample1.0b, but I get the same error with that too. I'm currently building against 2.5.8* with a 2.5.8 header, and I'm using VC++ 2010. Any idea what I might be doing wrong?
*On that topic: Does it matter what version of the Avisynth .dll that I build against? For instance, is it a problem to use the Avisynth 2.5.8 header but build against 2.6, or vice versa? (What about GPL issues?) If > 1 .dll is in the search path, will the linker just pick the first one it finds?
Update: Actually, I decided to make a new thread about this. (http://forum.doom9.org/showthread.php?p=1517363#post1517363)
jpsdr
3rd August 2011, 09:10
Thanks for this thread and interesting example.
Several questions :
- I have often seen different builds for filters, in case they target either v2.5 or v2.6 of avisynth (with 2.5 version working for both 2.5 & 2.6, but 2.6 version only for 2.6). What the situation here ? If (as i thought) it's targeting v2.5, what difference would be with 2.6 ? (Only the avisynth.h ?)
- Is this exemple x64 compliant ? If not, could it be possible to have an x64 compliant version.
Don't get me wrong, i'm not complaining, this is already a very good things. I just think, the interesting thing to upgrade from a very good thing to an excelent thing would be :
- A 2.5 and 2.6 version, wich explain differences between them.
- An x64 version (for both 2.5 and 2.6), with also eventualy explaination of differences, and what should be done to make a x64 compliant pluggin.
StainlessS
2nd July 2012, 17:31
Here a resource for C/C++ from cppReference.com including STL (Standard Template Library)
http://onnerby.se/~daniel/chm/
And a few posts on a forum about using the cpp.chm in CodeBlocks IDE.
http://forums.codeblocks.org/index.php?topic=5716.0;prev_next=next
EDIT: You would need the CodeBlocks Help Plugin.
StainlessS
27th November 2013, 09:08
Latest SDK for VS6
Source from Wikipedia, http://en.wikipedia.org/wiki/Microsoft_Windows_SDK
Windows Server 2003 R2 Platform SDK, 2006-03-14, "Also suggested by MS to work with VS6"
Here on MS site along with MS rep quote saying works on VS6: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/bf785787-8821-4a46-849d-420cf25ed9ad/platform-sdk-february-2003-installation-ie8?forum=windowssdk
Link to SDK seems missing but can be found below
Download from CNET: http://download.cnet.com/Windows-Server-2003-R2-Platform-SDK-ISO-Download/3000-10248_4-10731094.html
EDIT: Just in case file disappears from CNET, the ISO file name is:-
5.2.3790.2075.51.PlatformSDK_Svr2003R2_rtm.img
Burn to cd/dvd or mount using ISO file mount as CD/DVD, type utility.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.