Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th April 2012, 10:25   #41  |  Link
shark000X
Real Harper's Mockingbird
 
Join Date: Mar 2012
Posts: 14
Hi AMSS0815,

Please review the edited part of my previous post. The main idea and all the rest remains unchanged, but due to 42hoursnonsleeping I just got confused with some results of another experiment, then showed the images that are ill-fitting there and gave them assumptions accordingly; so the images and their explanation are changed now to avoid the further confusions for you and other possible readers.
Quote:
Originally Posted by AMSS0815 View Post
...a simple YUV->RGB conversion clips U and V values?? Maybe there is some shifting going on, like [0,255]-->[-128,127] or similar, but I cannot imagine that YUV wastes halve of its color range.
Well, my English played a wrong game with me again... To be more precise further, I start with some third-party explanations here (http://www.tek.com/zh/education/PDF/25W_15618_3.pdf):
Quote:
  1. Gamut – The range of colors allowed for a video signal. Valid color gamut is defined as all colors represented by all possible combinations of legal values of an R'G'B' signal. Signals in other formats may represent colors outside valid gamut, but still remain within their legal limits. These signals, when transcoded to the R'G'B' domain, will fall outside legal R'G'B' limits. This may lead to clipping, crosstalk, or other distortions.
  2. Legal/illegal – A signal is legal if it stays within the gamut appropriate for the format in use. An illegal signal is one that is, at some time, outside the limits in one or more channels. A signal can be legal but still not be valid.
  3. Valid signal – A video signal where all colors represented lie within the valid color gamut. A valid signal will remain legal when translated to R'G'B' or other formats. A valid signal is always legal, but a legal signal is not necessarily valid. Signals that are not valid will be processed without problems in their current format, but may encounter problems when translated to another format.
I don't mean that YUV wastes exactly a halve of its color range when going to RGB. When the non-valid colors go under convertion from YUV to RGB space, their U and V values aim to be shifted to the valid range but this can not be done totally if we use a simple YUV->RGB conversion: the colors are clipped out when U/V is still to remain below zero for PC-range or below 16 for TV-range and so on. To avoid this generally, the technique is proposed (see my previous post, variant II).
Quote:
Originally Posted by AMSS0815 View Post
...all color channels that get analyzed (R,G,B, maybe A, or Y,U,V) get shifted [0,255]-->[-128,127]... This shift keeps the squares a bit smaller and allows more frames to be summed up before the buffer runs full. No information is lost here, no clipping occurs. And the shift is reversed before the color part of the logo is returned to the user.
It is good, but not enough if we use the same color-table for both spaces when computing and creating our alpha-color-map. Let us examine the color-tables (http://multimedia.cx/eggs/yuv-and-rgb/):
YUV> RGB>
YUV> RGB>
So, all the minimum and maximum YUV components do not generate similar to RGB results, they should have negative R and B values out of gamut. In fact, all zeros in the YUV colorspace result in a dull green rather than black, because we get a conventional approximation by clipping the negative values (Y=0,U=-128,V=-128) to 0.

As I understand, the AnalyzeLogo always produce a result stored in RGB space (at least, *.ebmp looks as RGB file). So, an assumption here is that the RGB table is used for both spaces when analyzing, storing and deblending. This is why, proceeding from the above, the AVSinpaint may operate the U and V restricted each to 0-128 range when having a non-valid YUV input.
Quote:
Originally Posted by AMSS0815 View Post
Anyway, up to programming bugs (which might always exist)...
IMHO, the above can not be directly named as a bug. We just may say the deblending function of AVSinpaint is not better than the Delogo's one existing since 2001 -- it is able to help with RGB-originated sources or with the old analog PAL's YUV color space, but is not modern enough in most other cases.

Quote:
Originally Posted by AMSS0815 View Post
...maybe you can: Apply AnalyzeLogo+Deblend to YourClip.Grayscale.Levels(0,1,255,0,127). This clip should have all pixel values in permitted ranges, and I expect you to observe the same (glass-like) problem. On the other hand, if this works well (and you have thus solved your problem at least for a Grayscale'd version of your clip), you have a point and I will have a closer look at my code.
Considering the conclusions above, the Greyscale function is a bad test for YUV space in this situation, because its inner computations are totally based on valid RGB range, as a result the output clip "should have all pixel values in permitted ranges" of RGB for sure.

After some other experiments I think the "32-bit integer for each pixel" may be also not a good idea for YV12 sources if it is accompanied by chroma interpolation errors. I just examined the differences (see images below, grey shows no change) that occur as a result of convertions, running the Subtract function:
Code:
FILM_a = inputMovie
FILM_b = FILM_a.ConvertToRGB24.ConvertToYV12
Subtract(FILM_a,FILM_b).Levels(127,1,129,0,255)
YV16> YUY2>
YV24> RGB_>
The more interpolation is involved, the less chance we have to invert the process of blending two images. The RGB convertion (maximum interpolation) seems to be most of all similar to the resulting glass-like effect (see B2 http://forum.doom9.org/showthread.ph...17#post1569517). If a similar non-precise algorythm is used in the AVSinpaint, it's a bug for sure because affects the main functionality. And here I go with one more suggestion for a possible imrovement:

III. If the appropriate AVSinpaint algorythm allows, to avoid any chroma interpolations. In other case, to improve the chroma interpolation algorythm (some interesting ideas for precise interpolation and rounding control attached to this post).

I'm out of further ideas at this moment, so the "Eureka!" voiced at last

Thank you
Have a good inspiration
Attached Files
File Type: rar Chroma_interpolation.rar (187.2 KB, 72 views)

Last edited by shark000X; 28th April 2012 at 02:33. Reason: one more suggestion added
shark000X is offline   Reply With Quote
Old 28th April 2012, 22:56   #42  |  Link
AMSS0815
Registered User
 
Join Date: Aug 2006
Posts: 29
Hi shark000X,

I'm a bit lost. You convinced me that conversions RGB<-->YUV cause clipping. Thanks for this enlightment, I didn't realize that although it is obvious to me now.

Yet I don't see the connection with AVSInpaint. There are no colorspace conversions happening inside AVSInpaint, which the following far-fetched exceptions (n=number of color channels):
  • InpaintLogo: Generation of one common structuring tensor out of n. In YUV, this is controlled by the ChromaWeight parameter, in RGB(A), it's just the mean value. (The structuring tensor decides the direction of inpainting, btw.)
  • AnalyzeLogo: Generation of a logo's alpha mask out of each channel's alpha masks. This is controlled with the *Weight parameters.
Both exceptions do not really convert a picture, but they compute a common quantity for all channels out of per-channel-quantities. They are convex combinations and hence cannot cause any clipping.

Quote:
Originally Posted by shark000X View Post
As I understand, the AnalyzeLogo always produce a result stored in RGB space (at least, *.ebmp looks as RGB file).
No. AnalyzeLogo's output has the same colorspace as it's input (except the A in RGBA if you don't provide a separate mask), please check the colorspace table in the doc. AnalyzeLogo doesn't even know what an (ebmp-)file is.

Quote:
Originally Posted by shark000X View Post
After some other experiments I think the "32-bit integer for each pixel" may be also not a good idea for YV12 sources if it is accompanied by chroma interpolation errors.
These 32-bit integers serve the sole purpose of summing up the squares of the raw (8-bit) color values of each channel and each pixel (one 32-bit integer per pixel per channel). There is no interpolation going on here, no round-off, no floating-point arithmetic. When one of the 32-bit intergers reaches its limit AnalyzeLogo procedes with the next step.

If you suspect that the generation of the common alpha mask out of the channels alpha masks is the problem, then please try this: Start with you YUV clip, use Grayscale, UtoY and VtoY to create three independent grayscaled clips which contain the Y, U and V of your original clip as Y values. This step should not cause any clipping and also no round-off errors (Grayscale just sets U and V to 0x80, *toY just copies values around). Up to this point, there is hence no distorsion of any kind (ok?). Then apply AnalyzeLogo to each of those. Because U=V=0x80 are constant on these clips, AnalyzeLogo will not take U- and V-channel data into account when computing alpha masks (see DeviationWeight parameter). Unless there is a bug (behaviour deviant to documentation), AnalyzeLogo will also not clip anything. It will produce round-offs: After all the 32-bit integers are summed up, further computation is done with floating-point arithmetic and the final alpha mask has to be represented by 8-bit unsigned integers. Yet I don't see a problem here. At this point, AnalyzeLogo will give you three alpha masks (one for Y, one for U, one for V), and three logo color parts of course. Try to deblend each of the channels (the three clips you created with *toY etc) separately.

If you do not suspect that the generation of the common alpha mask is the problem, let me assure you: There is nothing else going on inside AnalyzeLogo which might be tantamount to a colorspace conversion.

-- AMSS0815
AMSS0815 is offline   Reply With Quote
Old 14th August 2012, 07:18   #43  |  Link
Iron Yuppie
Registered User
 
Join Date: Aug 2011
Posts: 6
Hi, need some help with an opaque logo. I just put in some preliminary functions to test out the plugin and to see if my .bmp mask was correct, and all it seems to be doing is remove the lettering inside the red logo itself which makes the whole area red. Am I doing something wrong already or is this logo too solid (which I didn't figure would be correct considering that's what I understand the whole Inpaint process is about in the first place, right?)

Here is the quick test code:
InpaintFunc(last, mask="logo0.bmp",loc="164,0,-1624,-766", mode="both")

Here are the masks:


And here's what it looks like afterwards:
Iron Yuppie is offline   Reply With Quote
Old 15th August 2012, 13:36   #44  |  Link
AMSS0815
Registered User
 
Join Date: Aug 2006
Posts: 29
Quote:
Originally Posted by Iron Yuppie View Post
Am I doing something wrong already or is this logo too solid (which I didn't figure would be correct considering that's what I understand the whole Inpaint process is about in the first place, right?) [...] Here are the masks:
From what I can see in your first mask (what is the second one?) is that the logo area is white and red. The comments in InpaintFunc state
Quote:
The mask is a black and white picture. Parties where the logo is are white, the others are black.
It is possible that the AVSInpaint function treats the red area in your mask as black and inpaints the red rectangle into the white text (as it is supposed to do with this mask). You will have to change your logo0.bmp such that there is a small (all-white) rectangle in the logo place and all black around.
-- AMSS0815

P.S.: Nevertheless, the logo is quite big, so when you get it going, I would expect ugly discontinuities in time.
AMSS0815 is offline   Reply With Quote
Old 11th December 2015, 00:43   #45  |  Link
BoobieNoobie
Registered User
 
Join Date: Oct 2015
Posts: 6
Virtualdub

Is there a plugin for virtualdub too?
BoobieNoobie is offline   Reply With Quote
Old 11th December 2015, 03:22   #46  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
Is there a plugin for virtualdub too?
https://www.google.co.uk/?gfe_rd=cr&...ogo+virtualdub

Above is one, there are probably a few more de-logo plugs for Vdub.

EDIT: Try a search on "logo' in Vdub forum.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 11th December 2015 at 10:26.
StainlessS is offline   Reply With Quote
Old 11th December 2015, 19:09   #47  |  Link
AMSS0815
Registered User
 
Join Date: Aug 2006
Posts: 29
As far as I know, AVSInpaint was never ported to VirtualDub, so you can't use it there (directly).
Karel Suhajda's DeLogo filter for VirtualDub (also mentioned in my original post) does essentially the same to semitransparent logos as AVSInpaint does, for opaque parts of a logo, however, it produces strong blurs. Nevertheless, for VirtualDub it's the most flexible logo removal tool I know off.
AMSS0815 is offline   Reply With Quote
Old 11th September 2016, 20:25   #48  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Hello AMSS0815,

First i want to say thank you for this tool, used it many times in the past and it always done a great job.

Now I'm trying to use it with StaxRip x64 version and the dll does not work there as apparently it's not compatible with x64 needs.

Is it possible for you to update or port it to be compatible with x64 please ?

Thanks a lot in advance.
Yanak is offline   Reply With Quote
Old 11th September 2016, 21:15   #49  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Amss0815, was last online December 2015, don't hold your breath waiting for an answer.

Edit: source is available, I think.
If you don't code, now is you opportunity to try.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 11th September 2016 at 21:19.
StainlessS is offline   Reply With Quote
Old 11th September 2016, 23:39   #50  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Yeah i know it have very slim chances, need him to see this and then modify the stuff, if possible.

Sadly I don't code no, will probably take ages to get into this and get a result if i try it myself, don't even know where to start :/

Well i tried to ask, will see if he see this one of those days, it is a nice tool and can be of good use for all of us in need of a x64 version too, not only for me i mean.

Thanks for the answer.
Yanak is offline   Reply With Quote
Old 12th September 2016, 02:01   #51  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Quote:
Originally Posted by Yanak View Post
Now I'm trying to use it with StaxRip x64 version and the dll does not work there as apparently it's not compatible with x64 needs.
I believe that Stax is a little too much obsessed with being at the frontier of technology. Insisting on 64-bit only means excluding a plethora of useful plugins which are only available in 32-bit versions. And the speed benefit of 64-bit is quite small IMO.

After many tests I decided for myself to revert back to the 32-bit version of StaxRip. I did not like version 1.2.2.0 all that much so I went all the way back to version 1.1.9.0, and I never looked back...


Cheers
manolito
manolito is offline   Reply With Quote
Old 12th September 2016, 03:53   #52  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Quote:
Originally Posted by manolito View Post
I believe that Stax is a little too much obsessed with being at the frontier of technology. Insisting on 64-bit only means excluding a plethora of useful plugins which are only available in 32-bit versions. And the speed benefit of 64-bit is quite small IMO.
I'm genuinely curious what useful plugins are only available in 32-bit in this day and age. This one is the first I've seen anyone ask for in a while (disregarding rean and his general craziness, but he's a nutjob so he doesn't count).

This particular plugin seems to be fairly clean C with no inline assembly, compiler intrinsics or other weirdness so chances are you can just recompile it with the Avisynth+ C-interface header and it'll work. It's a single source file, shouldn't take you more than maybe ten minutes to give it a try, so what are y'all waiting for?

Last edited by TheFluff; 12th September 2016 at 03:55.
TheFluff is offline   Reply With Quote
Old 12th September 2016, 09:38   #53  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
I won't argue about the utility or futility of a full x64 program, StaxRip x64 in the last versions brings some options very useful for me, making my life way easier when it comes to encode videos, that's all

@TheFluff,
you give me some hope man , searched briefly on the net for converting x86 stuff to x64 but i don't understand fully the part about inline assembly and other potential weirdness you speak about, seems like a good sign tho.

The source code is in the AVSInpaint.c file right ? I checked it a bit his content and saw "#include "AviSynth_C.h"" , if this the thing you speak about when you say " just recompile it with the Avisynth+ C-interface header" ?

If so and if i understood correctly changing this part to use Avisynth+ x64 equivalent file and recompile the dll may work ?

I don't know yet how to recompile this or even what program to use to do this but might spend some time searching the web in the next days to try figure this out and do it, hopefully i will not screw up everything, or maybe a good soul having more knowledge about this will have pity of me and do it, if like you said it takes 10 minutes to do someone may be kind enough to try it

Thanks a lot.
Yanak is offline   Reply With Quote
Old 12th September 2016, 16:28   #54  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Yanak, I see AMSS0815 on-site right NOW, perhaps you will be lucky.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 12th September 2016, 17:09   #55  |  Link
AMSS0815
Registered User
 
Join Date: Aug 2006
Posts: 29
Hi Yanak,

thanks for your posting. I'm still watching this thread, and from time to time I'm wondering if someone (still) uses this thing...

Unfortunatelly I can only be of little help: I'm not running Windows anymore, and the only Windows I can access right now is a 32bit-XP-installation.

Here is what I know:
  • The code of my plugin is completely architecture-independent, so it should compile cleanly on 64bit or whereever.
  • "My" code is in AVSInpaint.c; in order to compile it into a dll, you need at minimum the files AviSynth_C.h and AviSynth.lib. The former is -- apparently -- also architecture-independent, but I have a very bad feeling about the latter. Quickly searching the web, I just found this little tutorial, which doesn't mention architecture at all. If you can find this AviSynth.lib somewhere, and it is advertised for 64bit systems, that would be very helpfull. But I'm not sure if this file is architecture-dependent at all.
  • If you have these files, you need the compiler. I used gcc from mingw32 when I compiled this plugin, but I guess something like the 64bit-version of gcc is necessary. I'm not sure if I can run this on 32bit Windows and still compile 64bit binaries. Skimming the mingw-w64 site I wasn't able to find anything that looks like a gcc which runs on 32bit and produces 64bit binaries. Maybe someone can help? Since your OS is 64bit maybe it's easier for you to compile this than it is for me.
  • As soon as you find a Windows-64bit-version of gcc, you can just invoke the commands in AVSInpaint.Makefile.gcc.txt manually, i.e.
    Code:
    gcc  -fdiagnostics-show-location=once  -funsigned-char -mthreads  -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls  -O2 -fomit-frame-pointer -malign-double -s -march=x86-64  -c  -o AVSInpaint.obj  AVSInpaint.c
    gcc  -fdiagnostics-show-location=once  -funsigned-char -mthreads  -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls  -O2 -fomit-frame-pointer -malign-double -s -march=x86-64  -shared  -o AVSInpaint.dll  AVSInpaint.obj AviSynth.lib
    Mind the "-march=x86-64" , I hope that is sufficient for 64bit binaries.

With this (non-)knowledge, I downloaded a file called i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z somewhere near the mingw64-project and recompiled the dll with the commands from above. Surprisingly there were no errors (but many warnings .. gcc grew quite strict within the past years). As I can't test that file I just attach it here for you to test. I'm doubting it will work. If it does: Celebrate, otherwise please try to find some 64bit-on-64bit-version of mingw, look for a 64bit-version of the lib-file, then follow the recipe outlined above. There is no real coding involved, the hardest part is probably searching for the requisites.

I'm running linux on x86-64. Maybe I can get some linux-version of mingw for my cpu, then I might be able to compile it myself, but this probably won't happen this week.

If someone around here has any hint on compiling C-plugins for 64bit-AviSynth, please let us know
Attached Files
File Type: zip AVSInpaint.dll.zip (35.0 KB, 71 views)
AMSS0815 is offline   Reply With Quote
Old 12th September 2016, 20:11   #56  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Thanks a lot for the answer, really happy to see this, the dll can't be downloaded for now as it seems to need some approval, not sure how it works on the forum and how long it will take but I'm really impatient to test it.

I am on a limited network for the moment and can't really browse efficiently the net to look into all the procedure you explained, but if the .dll doesn't work I'll try to search for the needed files as soon as possible, maybe someone else passing by will know already how to find those too.

Thank you very much for taking the time to make it, really appreciate it, hope it will work so i can continue to enjoy your great work .

Thanks a lot.
Yanak is offline   Reply With Quote
Old 13th September 2016, 01:19   #57  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Tested quickly and doesn't seems to work , i cannot get it to load in StaxRip, getting a error message

Cannot load file 'C:/Users/Yanak/Desktop/AVSInpaint.dll'. Platform returned code 193:
%1 is not a valid Win32 application.


Using Megui it still loads on my avs and does the job perfectly to remove the logo while under x86 avisynth, even combined with InpaintFunc.avs this new dll still works nicely under x86 and still do an awesome job on removing the logo .

Almost 2am here so i will search tomorrow for AviSynth_C.h and AviSynth.lib in x64, the first one might be available at avisynth+ , Avisynth.lib for x64 might take a bit more time, first searches were not conclusive.

I'll also give a try at your instruction to compile the dll directly under x64 and see how it goes too, will have to go step by step as this is not really something i'm used to

Thanks again for having took the time to do it and help on this.
Yanak is offline   Reply With Quote
Old 13th September 2016, 15:32   #58  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Not sure but I think I remember some kind of problem with an app (Yasm I think) where it would not work compiled with
later versions of a compiler (maybe gcc), where the platform ID had changed from upper to lowercase, ie Platform
should be (I think) 'win32' not Win32', or win64 not Win64. Hope AMSS0815 sees this.

EDIT: See here:- http://forum.doom9.org/showthread.ph...75#post1742975
EDIT: In above link seems to apply to win32 Visual Studio build, but perhaps applies to win64 gcc too (maybe worth further examination).
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 13th September 2016 at 16:19.
StainlessS is offline   Reply With Quote
Old 14th September 2016, 01:07   #59  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
I tried to compile by myself with mingw-w64 , after some tries i could do some tests but no luck for me.

In mingw-w64 install options i can select i686 or x86_64 :


Tried the second one and doing the obj file works but getting the dll gives me this message :

[spoiler]
Code:
E:\test>gcc  -fdiagnostics-show-location=once  -funsigned-char -mthreads  -Wextra -pedantic -Wall -Wdeclarati
n-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls  -O2 -fomit-frame-pointer -ma
ign-double -s -march=x86-64  -shared  -o AVSInpaint.dll  AVSInpaint.obj AviSynth.lib
AVSInpaint.obj:AVSInpaint.c:(.text+0x6c): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xdd): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xef): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x137): undefined reference to `__imp_avs_copy_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x149): undefined reference to `__imp_avs_add_function'
AVSInpaint.obj:AVSInpaint.c:(.text+0x885): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x91c): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x934): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xa0c): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xba7): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xbd5): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x16a3): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x16c0): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x1837): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x1aee): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x2a1a): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x399c): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x3c09): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x3e59): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x4bf6): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x51bd): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x53b4): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x557d): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x55e7): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x55fe): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x586a): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x588e): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x5fc7): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6017): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6134): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6dca): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6e55): undefined reference to `__imp_avs_copy_value'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7077): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0x711f): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7195): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x71d0): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x71e5): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x776a): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x77ca): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x79b5): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x79cb): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x79e1): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7bfe): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7c14): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7e6d): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7e81): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7ed9): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x839e): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x83ff): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8442): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8492): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x84a0): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x85f1): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8695): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8762): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x87b4): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x87e3): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8b60): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8b7e): undefined reference to `__imp_avs_set_cache_hints'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8b99): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8be9): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8bff): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8c0d): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8e22): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8e4c): undefined reference to `__imp_avs_set_cache_hints'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8e57): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8edf): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8faa): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x93f4): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x9597): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x9c02): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x9f85): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xa824): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaa6a): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaa8f): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaaec): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xab0d): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xab3a): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xab4c): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xabff): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xac75): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaf45): undefined reference to `__imp_avs_set_cache_hints'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaf6c): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaf85): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xafe2): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xafec): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb230): undefined reference to `__imp_avs_new_video_frame_a'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb2df): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb359): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb383): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb3e8): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb428): undefined reference to `__imp_avs_get_frame'
collect2.exe: error: ld returned 1 exit status

E:\test>
[/spoiler]

Strangely enough when i tied the second command line given without the AviSynth.lib file at the end the message ended in being almost the same if not the exact same error message, i'll have to try this again tomorrow and compare both, using this command missing the AviSynth.lib at the end ( i tried without it, who knows ) :
Code:
gcc  -fdiagnostics-show-location=once  -funsigned-char -mthreads  -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes 
-Wredundant-decls  -O2 -fomit-frame-pointer -malign-double -s -march=x86-64  -shared  -o AVSInpaint.dll  AVSInpaint.obj
I removed the program and installed it again, selected the i686 setting and this time it worked and got the dll done, also gave a try to mingw in normal version , not the mingw-w64 one, and got the dll done there too, both working nicely under Megui and avisynth x86 but same error message on Staxrip x64 as before,

Will test and try more tomorrow but seems like mingw-w64 with x86_64 setting the file AviSynth.lib might be the problem, searched a while for x64 version of it and only thing i could find is this discussion :
http://forum.doom9.org/showthread.ph...91#post1389791

Sadly i could not find the lib file in the link of the second post and got lost in JoshyD's explanation to be honest, all this is new to me.

Well, no luck for me but managed to compile my first dll and it's working in megui under x86, that's something already

Last edited by Yanak; 23rd January 2018 at 00:24.
Yanak is offline   Reply With Quote
Old 14th September 2016, 05:46   #60  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Yanak, Avisynth standard installer installs Avisynth.lib in Extras folder when you tick the 'Select Extra Files' tick box.
I assume that AVS+ 64bit does the same (If that is what you are using).

JoshyD post from 2010 MT 64 bit, so unlikely to be of use for AVS+ 64 bit (I think, unless that is what you are using).
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.