Trying to recompile filters

[Billy|B-A]

Ok, I am very new to programing. So I really dont understand too much of this.

I am trying to recompile a few filters to work with avisynth 2.5. I got the anisynth.h file and replaced it with the 1 in Decombs src files. All that needs to be done is to just hit the "build" button in visual c++, right? Well if u say know your right. I came up with 50 errors and 16 warnings. What am i suppose to do?

Sory if this is a stupid question, please forgive me.

Error File (http://sugoi_bakayaru.tripod.com/Decomb.plg)

[neuron2]

If you want to recompile Decomb for Avisynth 2.5, get both internal.h and avisynth.h from the new Avisynth 2.5 source distribution and place these two headers in the Decomb build directory. In all the Decomb source files, replace the include of avisynth.h with include of internal.h. Then rebuild all.

You will of course have to convert to YUY2 for now.

Converting Decomb to YV12 is a big job and with my father having taken a turn for the worse in the last few days, it may not be as soon as we all would like. :scared:

[Marc FD]

sorry to hear that don.

i can help you to do some part of the decomb YV12 port if you're short on time. ( and it'ld be a great opportunity for me to understand how decomb's internal works ^^ )

and many users are waiting for decomb YV12 desesperatly. (but i know YV12 porting is not easy ^^).

BTW, i hope you'll only convert C code first, because changing the whole MMX code may really take a while.

in topic :
For avisyth 2.5 filters, just add a windows.h include in avisynth.h and everything'll work flawlessly.

Cheers,
MarcFD

[neuron2]

Thank you, Marc, for the kind words.

I do plan to release a C version first, then I may well accept your offer to help with the low-level optimization.

[Marc FD]

>I do plan to release a C version first,

if you have some time, could you please send me the code in it's current state ?

thanks.

i want to read all the decomb source, and starting with the last ones will be more instructing. i could see if i can convert some parts.
it's not a problem if i doesn't compile, i don't think i'll use it before YV12 and SIMD is finished ^^

>then I may well accept your offer to help with the low-level optimization.

no problem ^__^

BTW, after my little experiment in sharpen filters, i'm playing with interlacing. i'm trying to reduce blend fields due to bad NTSC->PAL convertions on many french anime DVDs. decomb solved partially the problem, but i'll try a more hardcore method (bobing and selective decimation)

and i'll try some kind of motion compensated smart bob.

for smart bobing, is it a good idea to bob a field, and then compare with is partner, than taking his pixels if they are close to the reconstructed (bilinear) lines ?

[hakko504]

@MarcFD

I just made some tests of different methods of how to handle those *%¤!#"%¤/¤&/ NTSC->PAL animes, and I think you are on the right track. My best results were achieved with Xesdeeni's Smooth-deinterlacer combined with SpatialSmootherMMX. Telecide also produced very good results, but it also made the video very jerky, almost like it was reduced to 12.5fps. I'm about to make a few more special tests, along with testing on a new clip that I got today. Me and manono is going to use the results for an update of the IVTC/deinterlacing guide, and any input would be valuable. If you PM me and tell me your email address I can send a copy of the final results to you, probably early next week.

EDIT: Forgot to mention that SmoothDeinterlace has a doublerate feature that will do smartbob instead of deinterlace.

[scmccarthy]

@Billy|B-A

neuron2 told you to put interal.h in the directory where you have avisynth.h and change all the #include "avisynth.h" statements with #include "internal.h"

Mark told you you can add an #include <windows.h> in avisynth.h.

Neither of these methods would work for me because I have a simple commandline development environment that came with the WINDDK for XP: cl.exe. What works for me is modifying avisynth.h in two ways:

1) Replace All BYTE with unsigned char, checking the 'Match case' box.
2) Add the statement
#define _ASSERTE (expr) ((void)0)
after the first enum statement.

Stephen

[Billy|B-A]

Thanks for repling. Looks like neuron2 is hard at work on it. So far its working flawlessly, great work :D .

Also, i didnt want to start another thread about this, nor rush anybody. But is there a chance of adding ssa subtitle support in avisynth? Or is there a Yv12 compliant subtitle filter? Or is it already there and I am not seeing it?

Edit: And mabe the ability to read d2v files. For example:

video = Mpeg2Source("D:\Poly Matrix\Poly Matrix.d2v")
audio = WAVSource("D:\Poly Matrix\audio.wave")

Pause = Trim(282,379)

Movie1 = Trim(380,50475)

Movie2 = Trim(50476,100570)

Credits = Trim(100571,105865)
Credits = Credits.Greyscale()

Last = Pause + Movie1 + Pause + Movie2 + Credits

Return Last

This way we can add/cut the audio during encoding. Instead of having to cut/paste or reencode the final avi to have proper cuts.

[ErMaC]

There is already a part of VobSub called TextSub which supports several text-based subtitle formats including SSA and its variant ASS. It's in the VobSub package. However Gabest has not released an AVISynth 2.5 version yet, because he says he doesn't want to have 2 separate DLLs. Unfortunately it sounds like this is impossible (at least that's what Marc said in another thread, and Don seemed very iffy about it too) so it may be a while til we see an AVIsynth 2.5 version of it. He's already got YV12 colorspace support implemented in the DirectVobSub code so I imagine it's not that work, but i'm not much of a programmer.
Anyways, I'd bug him about it. A YV12 TextSub is the only thing keeping me from ditching 2.07 altogether and moving to 2.5 for all my subbing work.

And Don, I wish your father the best of luck with his health. I'm sure despite how eagerly many of us here would like ports of your filters, we all realize personal matters, especially those like yours, should come before video processing.

[gabest]

Well, seeing the "TODO"s they seem to know what and where to change:

Look here: (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/plugins.cpp?rev=1.3.2.7&only_with_tag=avisynth_2_1&content-type=text/vnd.viewcvs-markup)// TODO: Implement rejection of 1.x and 2.0x plugins

AVSValue LoadPlugin(AVSValue args, void* user_data, IScriptEnvironment* env) {
...
AvisynthPluginInitFunc AvisynthPluginInit =
(AvisynthPluginInitFunc)GetProcAddress(plugin, "AvisynthPluginInit");
// TODO: Change this to reject 1.0!!
And here: (http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html)Todo for 2.5 beta:
...
Change PlugInInit to PlugInInit2!!

[hakko504]

@gabest
I believe sh0dan said something about changing this at the moment 2.5 goes beta, because it would break the plugins already compiled for 2.5alpha. Quite understandable: that would keep those plugins alpha only, and we would get a new set of plugins that would be for the new beta. Still, in most cases it would only mean a recompile to get alpha plugins to become beta plugins.

I also am very much in favour of getting a 2.5 version of vobsub, but I do understand if you want to wait until 2.5 goes beta. There still seems to be some unresolved issues with the alpha that needs to be corrected before it can go beta. sh0dan has said that the alpha should not relly be used by end-users but is intended for developer who wants to help with debugging and that normal users should wait for the beta. It does seem like the beta is approaching rapidly, and I wouldn't be surprised if it arrives just after the new year. Depends on how much time sh0dan has to code during christmas :)

[gabest]

You could still add that new entry point and look for both (for the new one first of course) until everyone recompiles for the new one. This would at least make it possible to have one dll which the old and the new avisynth can load without crashing. I have many other things to code already, and I don't want to answer several emails per day regarding vobsub/textsub variations and avisynth versions.

[hakko504]

sh0dan has answered this better elsewhere, but I'll try to summarize it: The thing is that avisynth.h has changed dramatically. There is a whole new structure on how to handle filters and it won't be possible for filters to work in both 1.0x/2.0x and 2.5. The thing about adding the '2' to PlugInInit is just a way of making sure that 1.0x/2.0x won't be able to load new filters as they don't recognize PlugInInit2 and 2.5 can identify and reject older filters.

I'm sorry Gabest, but the moment 2.5 goes final you should consider dropping support for the old version completely, and tell people to use DVobSub instead if they want to use the old versions of AviSynth.

[gabest]

Originally posted by hakko504
sh0dan has answered this better elsewhere, but I'll try to summarize it: The thing is that avisynth.h has changed dramatically. There is a whole new structure on how to handle filters and it won't be possible for filters to work in both 1.0x/2.0x and 2.5.It would be if every version had a different entry point. For example: "AvisynthPluginInit" for 1.x, "AvisynthPluginInit2" for 2.0x and "AvisynthPluginInit25" for 2.5.The thing about adding the '2' to PlugInInit is just a way of making sure that 1.0x/2.0x won't be able to load new filters as they don't recognize PlugInInit2 and 2.5 can identify and reject older filters.Exaclty, what's wrong with it? That would help plugin makers to pack more versions into one dll.

[scmccarthy]

Gabest - It sounds intriguing.

How are you going to implement both versions of AviSynthInit? Throw an error that calls the other function?

Even YUY2 has changed to CS_YUY2 in the VideoInfo. I trust you that it is possible, but it sounds like a lot of trouble:confused:

Stephen

[gabest]

One included avisynth.h per cpp file or namespace can solve the ambiguity, they won't interfere that way.

[hakko504]

Interesting.

If you can make it work, then please post your method here, I'm sure a lot of other developers would be interested to know how you did it. (I don't mean that you must release your source code, but a good explanation of how you managed to solve it would be nice)

[trbarry]

It would certainly be nice if it could be made to work.

I worry that folks won't be able to switch to 2.5 because of all the version compatibility problems. And there are probably a lot of filters out there that won't be recompiled for a long while.

It is a nightmare to have a bunch of things on a system with the same name but incompatible versions. Every time something fails we will be doing the version chase.

- Tom

[gabest]

http://download.vobsub.edensrising.com/avisynthtest.zip

[gabest]

Everybody gone to sleep or just suffered a hart attack after seeing how simple it was? :confused:

[neuron2]

Originally posted by gabest
Everybody gone to sleep or just suffered a hart attack after seeing how simple it was? :confused: Tell me in simple words what it does. The readme is, as I like to say, less than satisfying. Thank you.

[scmccarthy]

Allowing 2.0x and 2.5 versions to coexist in the same dll is definitely worth checking out. I'm filing it away for now however under must investigate later. Even assuming that it is a simple technique; the question of whether we want to adopt it for our own filters is a lot to digest.

Stephen

[hakko504]

Originally posted by gabest
Everybody gone to sleep or just suffered a hart attack after seeing how simple it was? :confused: Well, I'm still not totally satisfied with your example, but it really looks like it could work.

If you haven't already done so, PM sh0dan and tell him to look at this thread (he seems to be away at the moment). I'm quite sure the two of you should be able to solve this matter quite easily.

[gabest]

neuron2:Tell me in simple words what it does. The readme is, as I like to say, less than satisfying. Thank you.It was an example that one dll could be loaded by 1.x/2.0x and 2.5 at the same time if 2.5 were looking for AvisynthPluginInit2 first. But you could have also readed backwards a few posts to find it out (the readme was an auto-generated readme.txt by vc7, if you haven't seen such before)

scmccarthy:Even assuming that it is a simple technique; the question of whether we want to adopt it for our own filters is a lot to digest.If one wants to make a plugin only for either version of the avisynth, then this is not needed at all. But if AvisynthPluginInit2 was checked first, as I already said, then there would be the possiblity for those who want to make a dll for both version.

[neuron2]

Originally posted by gabest
neuron2:It was an example that one dll could be loaded by 1.x/2.0x and 2.5 at the same time if 2.5 were looking for AvisynthPluginInit2 first. So as it stands, then, it won't work unless and until Avisynth 2.5 is modified?

[gabest]

That's correct. And the modification would NOT affect the current filters. But of course it would be the preferable to use a different entry point in the future since the new and old filters can't be loaded by the other versions.

[neuron2]

Great!

Where is sh0dan? :D

[sh0dan]

This is a delicate matter.

As I discussed earlier with Gabest, changing the entry point to AviSynthPluginInit2 is a very good solution, and it _may_ allow filters to coexist. However i haven't done this yet, since it will break all 2.5 plugins.

My plan is to change this, when the beta is released. That way it'll be easier to distinguish the versions. Beta will probably be released in the Christmas holiday.

How does that sound?

[gabest]

Why would it break compatibility with 2.5 plugins? You can first check AviSynthPluginInit2 and if it's not there you can still look for AviSynthPluginInit as before.

[sh0dan]

If there is only an "AviSynthPluginInit", you cannot see if it is 2.0 plugin (which will crash AviSynth) or a 2.5 alpha plugin (which will work).
The only reason for changing to init2 is to make AviSynth 2.0x reject 2.5 filters, and make 2.5 reject 2.0 filters, and having the possibility to include support for both (even though I'm not sure if that will work at all).

[sh0dan]

ok, the solution (for now).

IMPORTANT INFO FOR FILTER WRITERS:
For your next release of you filter, you should change AvisynthPluginInit to AvisynthPluginInit2.

What this means is, that until we reach beta, you have time to make this change. When we reach beta, AviSynth 2.5 will no longer accept your filter, if it only contains a AvisynthPluginInit.

The updated binary with these changes will be uploaded tomorrow. But don't panic - your filter will still work for some time.

I think this is a reasonable solution - remember, we're dealing with alpha software!

[Richard Berg]

I agree, that's a good compromise -- keeps the Avisynth core clean and prevents lots of bugs that might result if we were less strict.

The steps necessary for dual interfaces on the filter author's end is kind of kludgy, but for the people who need compatibility, it's better than nothing.