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. |
12th November 2013, 08:43 | #261 | Link |
契約者
Join Date: Jun 2008
Posts: 1,576
|
There were examples of gpu resampling in avisynth and they worked quite well (old and not compatible with recent avisynth versions). I imagine today with better gpus and better drivers it'll be fine too. I guess one should try some simple resampling and see how it goes.
Edit: of course it is probabably pointless for something like bicubic, but JincAR is gonna be slowest resampling yet. Last edited by Keiyakusha; 12th November 2013 at 08:49. |
12th November 2013, 08:52 | #262 | Link |
Registered User
Join Date: Jan 2010
Posts: 270
|
It's not like you can't implement a GPU resizer in avisynth, it's that performance improvement you might get out of it is not worth it in most cases unless your resizer is really complex and slow to do on CPU. I don't think it's a good idea to include slow filters like that into the core.
Things might change if avisynth suddenly becomes GPU-aware, but I'm not aware of any efforts/plans in this area. |
12th November 2013, 09:17 | #263 | Link |
契約者
Join Date: Jun 2008
Posts: 1,576
|
The thing is, I don't care about GPU that much, but rather...
All filters can be roughly divided into 2 groups: fast, average speed - your "go to" filters and slow filters - when you don't care about speed but want to get the most out of it. If it'll turn out that Jinc+AR falls into the second group, there will be no reason to prefer it over nnedi. But at this point probably no one except madshi can estimate possible speed. Maybe even madshi doesn't know, unless he tried to implement it in CPU 1st. On the other hand, unlike nnedi, it was proven that JincAR can be done in GPU and works quite nice. This is where my "make use of GPU" idea comes from. Plus this way madshi probably will be able to give better assistance. Last edited by Keiyakusha; 12th November 2013 at 09:23. |
12th November 2013, 09:40 | #264 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
2. Haven't decided yet. Is there any use to a zip if you can update an existing installation by just simply installing over it? 3. I won't work on it personally, if anyone is interested in porting it to Avisynth though, that'd be cool. |
|
12th November 2013, 09:50 | #265 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
|
|
12th November 2013, 10:16 | #266 | Link | |
契約者
Join Date: Jun 2008
Posts: 1,576
|
Quote:
BTW that discussion you link to is TL;DR but I think it does not includes anti-ringing which is something madshi made on his own. Also I remember madshi was saying something that he tried to implement sigmoidal algorithm but didn't liked it, so his Jinc might be something a bit different. |
|
12th November 2013, 10:37 | #267 | Link |
Registered User
Join Date: Mar 2009
Posts: 3,650
|
Would it be easy to allow for filters that currently work only on YV12/NV12 to work with PO10? And if that was the case, would anyone be willing to hack ffdshow a bit to allow untouched 10bit frame serving
for the processing of that content? Perhaps even a ffdshow raw replacement for interfacing with Avisynth so that 10bit content can be enhanced without any color space conversion? |
12th November 2013, 10:38 | #268 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
2. I would wager any third-party builds would still use a non-installer-based package. So, probably? The big caveat here is that the installer is assumed to be used by those choosing to rely only on AviSynth+, such as first-time users. It installs to %ProgramFiles%\AviSynth+ and sets the plugins and plugins+ directory targets in the registry to the ones residing in the AviSynth+ directory. This means that - unless some other solutions arise to allow classic and avsplus to coexist - you should only use the installer for either classic or avsplus, but not both. Using the avsplus installer over top of the classic one will more than likely reset the plugin directory locations in the registry and that means you'd have to move/copy the plugins over to AviSynth+'s plugins directory (and if you ever uninstalled AviSynth+, you'd have to be sure to either reinstall classic or fix the registry so it points at AviSynth 2.5\plugins again). Currently, it cannot install both 32-bit and 64-bit versions, so separate installers for each one would be necessary unless/until a proper solution for that is found. I saw some references on StackOverflow to getting NSIS to use one installer for both, but since I don't have access to any Win64 setups I can't really do any work on that and test it (the closest is 64-bit Wine, but that still means nothing because I can't compile AviSynth+ itself as 64-bit - unless there's some CMake trick to make a Win64 target available to a 32-bit MSVC...if cross-compiling 64-bit stuff with 32-bit MSVC is even possible, that is). One thing that I have been thinking about in regard to licensing as SEt brought up way earlier in the thread: since several parts of the AviSynth+ source code would be brand-new, I propose that anything brand-new could be put under a more permissive but still GPL-compatible license. The ISC license and Expat license are both popular and GPL-compatible, for instance. Arguably, the refactoring process on the old stuff might eventually render many of those parts completely rewritten and open to relicensing, but since IANAL I won't say anything definitive on that front. The end result is that AviSynth+ (in binary form?) would still be distributed under the terms of the GPL (with the plugin linking exception intact), but at least on those brand new parts, it could encourage more source contribution from those that would otherwise not because of the GPL. |
|
12th November 2013, 10:41 | #269 | Link | |
Registered User
Join Date: Jan 2010
Posts: 270
|
Quote:
No, no one will be hacking ffdshow since the project is dead. We do have a few ideas about avisynth in directshow, but that will wait. Oh and I agree on the license part. Last edited by TurboPascal7; 12th November 2013 at 10:48. Reason: licenses |
|
12th November 2013, 10:42 | #270 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
|
|
12th November 2013, 11:21 | #271 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
- prevent installation if it detects classic avisynth already installed, and give meaningful instructions to the user. - install both 32- and 64-bit versions (on a 64-bit OS) - install the required vc++ runtime unattended if needed qyot's work is a very good start on an avs+ installer, and even if none of the above points get realized right now, his installer can still be used to make releases. but i will try to implement my points soon based on his work, coz i find them important for a seamless user experience. my experience lies in Wix rather than in NSIS though, so someone more experienced with NISIS could probably do it in half the time than me. any volunteers? |
|
12th November 2013, 11:28 | #272 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
the licensing issue might be worth its own topic. it's a complicated thing, both in practice, both legally, and both in reaching a consensus between all past contributors. i'm all for changing the license, but it only makes sense if we can do it legally properly. otherwise there is little point in having one at all.
|
13th November 2013, 00:36 | #273 | Link |
Registered User
Join Date: May 2008
Posts: 1,840
|
Extractable installer makes standalone dll package not very useful, at least for me. The reasoning behind it is portability or being able to use/update avisynth without admin rights.
Nnedi is limited to multiples of 2 resizing, which doesn't make it a replacement for a general resizer. While it's subjective I think Jinc performs just fine without anti-ringing, imo it's does a better job of detail retention. I can't find it now but in another thread I had asked madshi about Jinc downsizing and he said it could be effective just not implemented. I'm not sure it would be more effective than lanczos when encoding however, during playback lanczos seems to be stay closer to the source. DGNV's gpu resizing is very fast but I believe it's baked in cuda code and limited to bilinear. It would be interesting to see if a resizing is faster with gpu pixel shaders or cpu.
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650 PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0 |
13th November 2013, 01:20 | #274 | Link |
Registered User
Join Date: Dec 2011
Posts: 77
|
I agree that license is complicated thing, and while many parts of avs+ are rewritten and could be put under, say , LGPL, many part also don't. At least on core filter I have been working on, the C++ files are rewritten but header file mostly remain the same. And it's very hard to track which piece of code are written by whom.
|
13th November 2013, 09:35 | #275 | Link | ||
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
Quote:
On the other hand, the current "GPL+public header exception" is practically the same as the accepted interpretation of the LGPL, so we might be able to pull that change off. It will only work with LGPL though, not with other licenses like MIT. Also note that the 2.6 header is not under the exception right now. To summarize, trying to get ALL the code under LGPL could be possible, but we'll need other opinions on the matter than just mine, coz I'm not sure if even that is okay. Any other target license surely requires getting in contact with all the previous contributors. Last edited by ultim; 13th November 2013 at 09:40. |
||
14th November 2013, 03:59 | #279 | Link |
Registered User
Join Date: Sep 2006
Posts: 212
|
Greets, can Avisynth+ also be used for realtime script post processing with ffdshow raw filter? Reason being, I swapped out the dll file with the + version and now I get a conflict with mVR which didn't happen before when using the "official" 2.6.0 Alpha 5 avisynth.dll file.
The problem is that I get an error code: "madVR reports: resetting Direct3D device failed 8876017c" when coming out of mVR Fullscreen Exclusive Mode back into window mode after playing a video in FSE for more that 10minutes or thereabouts. Not sure what the cause is, all I know is that it happens when using the avisynth+ dll file and not with the official. Just thought I would let you know. Cheers AviSynth+ 2013.10.16 + mVR Deband 14 version Last edited by andybkma; 14th November 2013 at 13:13. |
14th November 2013, 09:46 | #280 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
A couple of suggestions for the plugin writing tutorials and/or general explanation about the core: an explanation of what needs to be considered in order to support 64-bit properly, and how to deal with the topic mentioned above with moving to being high bit depth aware (also if relevant to the HBD discussion, anything about adding new pixel formats and/or colorimetries). I'm certainly interested in knowing what the nuts-and-bolts of these are, even if only for educational purposes.
Last edited by qyot27; 14th November 2013 at 09:49. |
|
|