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 Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th January 2012, 09:22   #21  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by librarian View Post
A (not too quick) experiment. I created a virtual machine with Virtual Box (latest available version, freshly downloaded) and installed Windows XP SP3 professional, Avisynth 2.5.8 and Xvid 1.3.2.
I run your script, the result is the expected one (see linked image)
Therefore there are at least 3 machines which can run your plugin:yours,mine,a virtual XP (but I think there are many more):-)
If I find the time I'll try with linux and wine.
Thank you, Librarian. It is very good of you to take the time to verify this. Are your machines 64bit or 32? Mine is 64, and I could believe that there are portability issues between the two (though it is a long time since I have had any dealings with those deep layers, so I could easily be wrong).

I will check my wife's machine which may be 32 bit (XP) and if so give it a run on there.

When I get some quiet time (later today?) I will create a SourceForge project (is that the preferred vehicle?) , upload the source code and executable, and add a note on this forum (new plugin thread?).

Phill
DrPhill is offline   Reply With Quote
Old 27th January 2012, 11:16   #22  |  Link
librarian
Registered User
 
Join Date: Nov 2011
Posts: 63
Real machine win7 64 bit
Emulated machine win XP SP3 32 bit
On both computers Avisynth 32 bit 2.5.8, Virtualdub 1.9.11, xvid 1.3.2
librarian is offline   Reply With Quote
Old 27th January 2012, 14:40   #23  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
I have created a project on SourceForge for this:

https://sourceforge.net/projects/watermarkplugin/

I will add a note to the new plugin thread
DrPhill is offline   Reply With Quote
Old 27th January 2012, 17:50   #24  |  Link
librarian
Registered User
 
Join Date: Nov 2011
Posts: 63
Tested on linux Ubuntu 10.04 LTS 32bit, Wine 1.2.2. , usual versions of Avisynth, Virtualdub, Xvid.
See output here.
librarian is offline   Reply With Quote
Old 28th January 2012, 01:47   #25  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
I have not tested the filter but here are some source comments. I haven't really read all of the source, I mostly just skimmed it looking for suspicious things.

moveit.cpp
  • You #include "Watermark.h" but this file isn't actually included in the source archive.
  • File is called .cpp but you use no C++ functionality except the "new" operator. You use the Avisynth C interface rather than the C++ interface, too. Why not use plain C and replace new with malloc()? The problem with this is that you can't really compile C with MSVC, since it'll enforce C89 strictly (have to declare all local variables at that very top of the block, etc).
  • struct moveit_Params is pretty weird; it's mostly a subset of the Avisynth VideoInfo struct (AVS_FilterInfo->vi). Several of the values are hardcoded and never changed; they should probably be enums or defines instead.
  • Related to the above, since curX and curY depend on dx/dy and are calculated iteratively each time moveit_GetFrame() is called, behaviour will most likely not be what you expect it to be if frames are requested out-of-order. Since Avisynth doesn't have a way of guaranteeing linear access, filters must support random access. In other words, your filter must support delivering any given frame without being dependent on having the state for the frame preceding it in the video cached, since that frame might not have been requested yet.
  • Still related: since you only initialize moveit_Params once, you set the source pitch upon filter initialization and never again after that. That means you assume the source has constant pitch. This is not a safe assumption and will lead to crashes if the surrounding script is sufficiently complicated in the right way. You must call avs_get_pitch() on the source frame every time you get it.
  • On line 96 you write y++, but on line 97 you write x += 1. It's nice to be consistent.
  • The loop on lines 118-120 might possibly be faster if you copied a 32-bit word at a time instead of a byte at a time, but this is just speculation. I suggest you test it.
  • The memory allocated for the moveit_Params instance in the filter constructor is never freed when the filter is destroyed.

Watermark.cpp
No comments except again the .cpp/.c debate.

Watermark3.cpp
  • Any and all variables that have something to do with the size of an array (that is, a memory block) or an offset thereof should probably be declared as size_t rather than int. This guarantees it'll work properly in 64-bit mode too. You may have to include stddef.h to get the size_t typedef.
  • wm3_Params: most of the things that apply to moveit_Params apply to this as well, including the constant pitch assumption.
  • wm3_Params->hLight and wm3_Params->vLight: you should probably use #defines to avoid the magical numbers here.
  • Lines 45-46: while it's not strictly wrong to allocate an array of integers in C++ with new int[size]; it's usually not done that way. If you want a plain array of a basic datatype, use malloc(). Operator new is generally used only for class instantiations.
  • Lines 84-85: all-caps identifiers in C++ are generally reserved for typedefs, enums and preprocessor defines. Again, it's not wrong to use them, it's just that it's usually not done that way.
  • The loops in wm3_buildMask are extremely deeply nested; the innermost loops should probably be broken out into their own functions (the logic is very similar in many of the loops and it could most likely be generalized). Or you could rethink your algorithm.
  • Sorta stopped reading there; got sleepy. Sorry.

In general it seems like the effects of this filter could be duplicated fairly easily with existing filters, for example FluaG.

Regarding portability: it's not very meaningful to try to make Avisynth plugins portable, since Avisynth itself is so extremely unportable and the plugins aren't useful without it. Still, your code seems portable enough. It doesn't include any Windows headers at all and there are no particular MSVC-isms that I could spot.

Quote:
Originally Posted by DrPhill View Post
Seemed to work alright in AVISynth. I am not sure what to do now - I have no idea how to debug a plugin.
If you have Visual Studio (you really should, if you are writing Avisynth plugins), it's pretty easy. Make sure your plugin isn't getting autoloaded (i.e. remove it from the Avisynth autoload directory), then create an Avisynth script that explicitly autoloads the debug build with LoadPlugin(). Make sure you load the output file generated by Visual Studio and not a copy you made yourself.

Now go to the project properties in Visual Studio. Hit the debugging tab, set the debug command to run to X:\path\to\virtualdub.exe and the commandline to X:\path\to\debug.avs. Set a breakpoint on AvisynthPluginInit2 (or the Avisynth C equivalent, or just your GetFrame implementation) and hit start debugging. When you do that VS will warn you that it can't find debugging symbols for virtualdub.exe; don't worry about that and just tell it to continue. You'll hit your breakpoint and now you're running your plugin in interactive debug mode. Go hog wild.

Last edited by TheFluff; 28th January 2012 at 05:25.
TheFluff is offline   Reply With Quote
Old 28th January 2012, 08:10   #26  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Thank you TheFluff, for taking the time to examine my code and to comment here. There is a lot that is very helpful.

Forgetting the header file is a big blooper - I will correct that soonest.

If codeblocks will compile *.c files in exactly the same way as *.cpp files, then I will change the names. I only used .cpp as I followed instructions on how to write a C interface plugin and that is what it said. That means that I will also have to use malloc and free rather than new and delete, but that is fine with me.

Not freeing the params block is a definite blooper.

The moveit funtion was just there to demonstrate that the watermark was dynamic, and that the algorithm could cope with edges. Anything problems specific to if can be documented.

I did not realize that sourcePitch could change, and I am not sure that my algorithm would handle that gracefully... will change the code.

The comments about size_t make a lot of sense - I vaguely remember them from an embarrassingly long time ago. They could easily be the source of crashes.

#defines for vLight and hLight are a good idea

the uppercase was left over from when the values were constant - will change.

The nested loops are fairly ugly. - they just sort of grew. I will think about rewriting the algorithm - that is the bit I like doing the most.
--------------------------------------------------------
I actually wrote the thing because the learning curve for the non-built-in filters seemed steeper than coding my own! Some scripts were suggested by experience folk here, but it seemed that things that I did not understand failed in ways that I could not describe for reasons that were unfathomable to me.

I understand what you are saying about portability - so that is one less goal to aim for. I did try to keep my C as simple as possible so that others could use/compile it should they wish.

As far as debugging goes - thanks for the info, but I will try to avoid that. :-)
-----------------------------------------------

So in summary, thank you, you comments are greatly appreciated and will guide me to improve the code. I am working this weekend, but hope to have the improvements up by the end of Monday (but likely before if the weather is bad).

Phill

Last edited by DrPhill; 28th January 2012 at 08:11. Reason: To correct a typo
DrPhill is offline   Reply With Quote
Old 28th January 2012, 10:50   #27  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
I just tried changing the files to *.c, and started getting a compilation error that I do not understand:
Code:
C:\Users\Phill\VideoProject\Watermark\Watermark.c|26|error: conflicting types for 'avisynth_c_plugin_init'|
Added to the possibility of getting irritated by strict C89 enforcement I think I will revert to using a C++ compiler.

Phill
DrPhill is offline   Reply With Quote
Old 28th January 2012, 12:11   #28  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,420
Quote:
Originally Posted by DrPhill View Post
I just tried changing the files to *.c, and started getting a compilation error that I do not understand:
Code:
C:\Users\Phill\VideoProject\Watermark\Watermark.c|26|error: conflicting types for 'avisynth_c_plugin_init'|
To be consistent with avisynth_c.h, it should be defined as
Code:
AVSC_EXPORT const char * AVSC_CC avisynth_c_plugin_init(AVS_ScriptEnvironment* env) {
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 28th January 2012, 12:14   #29  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by Gavino View Post
To be consistent with avisynth_c.h, it should be defined as
Code:
AVSC_EXPORT const char * AVSC_CC avisynth_c_plugin_init(AVS_ScriptEnvironment* env) {
OK, thanks Gavino, I will go back and do that when I revisit c++ --> c conversion of the source code.

Phill
DrPhill is offline   Reply With Quote
Old 28th January 2012, 14:13   #30  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,420
Quote:
Originally Posted by DrPhill View Post
If codeblocks will compile *.c files in exactly the same way as *.cpp files, then I will change the names. I only used .cpp as I followed instructions on how to write a C interface plugin and that is what it said. That means that I will also have to use malloc and free rather than new and delete, but that is fine with me.
Another change you will have to make if moving to a pure 'C' source is you can't use struct tags as type names, eg
Code:
struct wm3_Params {
    ...
};

void wm3_initialise(wm3_Params* params, ...
You would have to add typedefs, eg
Code:
typedef struct wm3_Params {
    ...
} wm3_Params;
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 28th January 2012, 18:24   #31  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Thanks, Gavino..... it just gets better.

Phill

Last edited by DrPhill; 28th January 2012 at 21:20. Reason: Removed off-topic comment
DrPhill is offline   Reply With Quote
Old 29th January 2012, 18:42   #32  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
I have done some code tidying and put the results (source and dll) up on SourceForge as 'second cut'.
For convenience I have added the files as an attachment to this note (Moderators: If this is frowned upon, then my apologies, and please feel free to remove them).

Changes - I have:
  • Used malloc/free instead of new/delete.
  • Used size_t where it seemed appropriate.
  • Set the values in params for each frame get.
  • malloced memory for the duration of frame get (is this a good or bad idea?).
  • Used some #defines to clarify code.
  • Reorganised the main algorithm to make it clearer (an a little slower, probably).

While doing this I removed a bug that could cause a memory access violation, so the problems seen by Emulgator may, just may, have gone away. I cannot promise anything though, but it did need fixing......

I think I addressed most things in the list by TheFluff. I will look at converting the files to *.c from *.cpp next.

I am not sure that I can improve the algorithm - I need to do work around boundaries between watermark and not watermark. It seems to me the quickest way to reduce workload is to detect the boundaries first, and work from them. I would be perfectly happy to be shown to be wrong, though.

Thanks all.
Attached Files
File Type: zip Release.zip (42.5 KB, 83 views)
File Type: zip WatermarkSource.zip (16.5 KB, 61 views)
DrPhill is offline   Reply With Quote
Old 29th January 2012, 18:59   #33  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
I think I have spotted a blooper. Can someone confirm that increasing pixel coordinates go from left to right and bottom to top? I had assumed left to right and top to bottom, so I may need to change some of my comments/constants..........

Thanks
DrPhill is offline   Reply With Quote
Old 29th January 2012, 19:57   #34  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,420
For RGB clips (but not YUV), frames are stored 'upside-down', so yes, there the coordinates do go from bottom to top.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 29th January 2012, 20:04   #35  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Quote:
Originally Posted by Gavino View Post
For RGB clips (but not YUV), frames are stored 'upside-down', so yes, there the coordinates do go from bottom to top.
Thanks Gavino..... so if I comment it correctly for one it will be incorrect when(if) I implement the other . Ah well, I will comment it correctly for the RGB. And make a note when (if) I implement YUV. Since my algorithm is almost entirely symetric about the vertical and horizontal axes it probably matters little.
DrPhill is offline   Reply With Quote
Old 21st October 2017, 13:48   #36  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Old thread and plugin but does some very interesting things, digging in this forum is full of surprises, the author have not logged since years apparently but i have 2 little questions, maybe one of the knowledge guru's of this forum can help :

- Is there a x64 version of this of this available somewhere please ? It will be really great.
For now i have to use MP_Pipeline to make it work in my x64 workflow:
Code:
MP_Pipeline(""" 
### platform: win64
LoadPlugin("H:\LSMASHSource.dll")
LSMASHVideoSource("H:\00.mp4", format = "YUV420P8").ConverttoRGB32
### ###
### platform: win32
LoadPlugin("H:\test\Watermark.dll")
myWatermark = ImageSource("H:\03.png", pixel_type = "RGB32") 
Watermark(watermark = myWatermark, displace = 20, light = 200, depth = 6, softEdge = true, lightFrom = "NE")
### ###
""")
Result : https://s14.postimg.org/7wl2fcvwx/18...thr1858x64.jpg

- The input video needs apparently to be converted into RGB32 which isn't always the best thing, so I'm wondering if it is possible with avs+ to do something like :
LSMASHVideoSource("H:\00.mp4", format = "YUV420P8").AddAlphaPlane()

Tried this quickly but i get a returned message telling me the video needs to be on a single plane, maybe i am using the AddAlphaPlane incorrectly... i don't know

Too bad the part about moving the watermark was not finished apparently, this could really have been a great plus if we could have set some coordinates to define a part of the video where the watermark had to move inside, this could have been a terrific thing but even without this option it's a nice little tool.

For now i will be more than happy with a x64 version of this plugin to bypass MP_Pipeline and a way to convert my input sources with the minimal quality loss possible or no loss of quality at all with something like like adding only an alpha channel to it ( i maybe misunderstood how exactly this function is supposed to work tho)

If anyone have any infos about a possible x64 version of this little thing or ideas to bypass the ConverttoRGB32 step with no loss of quality i will be really grateful.

Thanks in advance for any help.

Last edited by Yanak; 22nd January 2018 at 23:59.
Yanak is offline   Reply With Quote
Old 21st October 2017, 14:12   #37  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Long time since anyone posted on this thread...... I have not thought of this stuff for ages.

The source code is up on sourceforge - link in a post above.

Note that TheFluff said 'In general it seems like the effects of this filter could be duplicated fairly easily with existing filters, for example FluaG.'. This may be a better route as I am/was a novice at this type of coding in this type of environment, and C is not my strongpoint.

I eventually gave up on trying to do the video project using AviSynth and wrote my own tool in Java. Once I had achieved my goal with the java tool I forgot all about it. Where did the years go?

Good luck with your endeavours.

Phill
DrPhill is offline   Reply With Quote
Old 21st October 2017, 14:29   #38  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Good to see you here
Like i said there is sometimes surprising things to discover digging this forum, the plugin does exactly what i needed with the few parameters it have, just perfect in terms of results.

There is indeed probably other ways to do this now, i'm not a avisynth knowledge guru like many around so i'll have to dig more into all this. I saw the FluaG plugin too but have no tried it yet, it's also not updated since like 6 years on his github page...

I just needed exactly what the watermark plugin does with the parameters it offers, it's perfect for me so i did not bothered much more once i saw the results obtained on my tests.

I saw there was the source code published but I don't know how to convert nor re-compile this into a x64 version sadly, maybe someone around will be kind enough and take a look at this.

This plugin had a nice potential, the option to make it move had been a blast if finished, at worst i will continue to use it with MP_Pipeline and the rgb32 conversion if i don't find any other way to obtain the same effect or if nobody tries to convert it into a x64 version + a way to byapss the converttorgb32, will have to dig into all this in the next days and see what i can do.

Thanks for the reply and for this plugin, still helpful years after

Last edited by Yanak; 21st October 2017 at 14:35.
Yanak is offline   Reply With Quote
Old 21st October 2017, 14:37   #39  |  Link
DrPhill
Registered User
 
Join Date: Dec 2011
Location: West Somerset, UK
Posts: 130
Glad the plugin is of help - sorry I cannot be!

Making the code work on 64-bit might just be a case of choosing the right data types as indicated by an earlier post. (size_t instead of int)

Building the thing is a different matter, and part of the reason I went off the C/C++ languages quite early. For someone who does this regularly it probably raises no sweat, but to do it occasionally means a bit of set up.

If you do decide to jump into the development then take heart from the fact that I managed to do it and produce a pluggin.

Good luck.
DrPhill is offline   Reply With Quote
Old 21st October 2017, 14:42   #40  |  Link
Yanak
Registered User
 
Join Date: Oct 2011
Posts: 275
Yeah i will probably not put my hands into this , tried a few things in the past but it's a bit too much for me :/ Will cross fingers in hope a good soul will find it interesting as i did and find it worth a x64 version based on the source code (and why not add finish the options to animate it, you never know ).

Thanks again.
Yanak 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 05:21.


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