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. |
1st August 2016, 14:05 | #2241 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
So, I certainly wouldn't call avisynth.dll a "standalone" DLL (whatever that means). Don't forget the first axiom for developers: "Assumption is the mother of all f*ck-ups"
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 1st August 2016 at 14:10. |
|
1st August 2016, 14:39 | #2242 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Still, I assume ... that he may mean: The avisynth.dll does not necessarily need to be installed and hooked into the VfW API; an application may as well load it dynamically and use it via native interface.
|
1st August 2016, 14:51 | #2243 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Semantics - perhaps.
__________________
Groucho's Avisynth Stuff |
|
1st August 2016, 14:57 | #2244 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Well, yes ... maybe rather call it "indirect use" (using a system-wide registered DLL via VfW API) versus "direct use" (using a local DLL via native AviSynth interface, regardless of its system-wide installation into the VfW API).
|
2nd August 2016, 01:38 | #2245 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Yeah, just copy AviSynth.dll and Devil.dll into either the system folder or the app folder and you're good to go.
Or more common, AviSynth 2.6 (or perhaps even 2.5.8) was installed and the DLL got replaced by AviSynth+ (before the new installer got released). In that case I wouldn't rely on the way the installer sets things up. |
3rd August 2016, 21:33 | #2246 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
The robust way to do feature detection is to try it and see if it works. Doing it this way also gives you graceful error handling unless you're being actively terrible about it. Last edited by TheFluff; 4th August 2016 at 00:05. |
|
4th August 2016, 03:41 | #2247 | Link | |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
"Try and see" won't tell me this. Plus in .NET, I cannot instantiate the DLL to call its API unless there is a DLL wrapper to expose its interface, and I don't use it directly in my code. I generate the script, then call avs2yuv or x264 or ffmpeg |
|
12th August 2016, 22:37 | #2248 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
As we are with internal mode creations (like uint16 and float), i would like to make a suggestion : An RGB planar mode.
This could be interesting for people who work with RGB video, don't want to convert them in YUV, but want good speed processing, because RGB32/RGB24 mode are not the easier data storage mode to process. The work will be minimal, because an RGB planar mode is somehow exactly the same thing than YV24. Your picture has 3 planes of the same size. You call for YV24 and RGBplanar exactly the same functions with the exact same parameters. Except, of course, format convertion functions. What do you think ? |
12th August 2016, 23:44 | #2249 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
The big pixel type pull request, opened on July 26th. Not everything in there is working yet, but Planar RGB was there from the start. |
|
14th August 2016, 12:31 | #2251 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
r2150 integrates work from chikuzen, pinterf, and qyot27. The colorspaces are further extended with initial support for planar RGB and alpha channel, new SSE2 and other optimizations are available, support for building with VS2013 is improved, there are some small fixes here and there, and of course a bunch of cleanups. API support for negative ("forced") alignment of video frames is deprecated and disabled, we think this is safe and have seen no regressions during testing, but just in case, there is a new diagnostic warning in the recently added logging system if a plugin is found relying on it.
Code for the new colorspaces added in the past weeks is still in a flux, so keep in mind this is a work in progress. Still, large and usable parts are already done, like support in the API, in various conversion functions, and in many-many internal filters. As always, please write to this thread if you see any regressions or have any other feedback.
__________________
AviSynth+ Last edited by ultim; 14th August 2016 at 13:11. Reason: added missing info to list of changes |
14th August 2016, 13:41 | #2252 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Perhaps the one thing missing to make the new 16-bit code actually usable is dithering back to 8-bit. Until then, it's academic work that can't be used for production.
P.S. Slightly off-topic but... Ultim, I find it a strange coincidence that our avatar is the same circle with the same border width. Yours is empty though. |
14th August 2016, 13:47 | #2253 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 14th August 2016 at 14:08. |
|
14th August 2016, 14:49 | #2254 | Link |
typo lover
Join Date: May 2009
Posts: 595
|
I updated RawSourcePlus and avs2pipemod to support r2150 new features.
RawSourcePlus avs2pipemod These are also experimental because the new features are still experimental. When input and output aren't supported, it isn't possible to be a victim. Therefore I announce to only the people watching this thread.
__________________
my repositories Last edited by Chikuzen; 14th August 2016 at 16:38. |
14th August 2016, 16:02 | #2255 | Link | ||||
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
Quote:
Quote:
Code:
16-bit source ConvertToStacked() DitherPost() Code:
16-bit source ConvertToStacked() f3kdb(input_mode=1, input_depth=16, output_depth=8) MysteryX, did you ever fix this? Quote:
|
||||
14th August 2016, 16:11 | #2256 | Link | |
typo lover
Join Date: May 2009
Posts: 595
|
Quote:
Code:
16-bit source ConvertToDoubleWidth() f3kdb(input_mode=2, input_depth=16, output_depth=8) You shoudn't use Stack16 if filter support DoubleWidth(Interleaved) formats.
__________________
my repositories |
|
14th August 2016, 17:38 | #2257 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
It seems that CreateScriptEnvironment() is not exported for 64 bit.
Edit: I see it's fixed in r2151, thanks.
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 14th August 2016 at 17:43. |
14th August 2016, 18:00 | #2258 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
ConvertToStacked()/ConvertToDoubleWidth() provide a hack to be able to interface existing dither functions. I'd like to kill these two (and their counterparts) ASAP, so if any of you can find the time, please consider adding proper high bit-depth support to dithertools and f3kdb, at least to the functions for dithering down.
edit: give a note if you decide to help out with these, so that others won't start on it too.
__________________
AviSynth+ Last edited by ultim; 14th August 2016 at 18:04. |
15th August 2016, 00:56 | #2260 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
Code:
f3kdb_dither(mode=1, stacked=false, input_depth=16)
__________________
See My Avisynth Stuff |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|