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

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 12th November 2013, 08:43   #261  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
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.
Keiyakusha is offline  
Old 12th November 2013, 08:52   #262  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
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.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline  
Old 12th November 2013, 09:17   #263  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
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.
Keiyakusha is offline  
Old 12th November 2013, 09:40   #264  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by turbojet View Post
Looking forward to 64 bit and multithreading. A few questions:
1. Will the installer be able to extract the dll's with 7zip?
2. Will the dll package still be available?
3. At some point in the future, would JincResize (from madvr) be considered?
1. Not sure what you mean. Probably no, but cna you clarify?
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.
ultim is offline  
Old 12th November 2013, 09:50   #265  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Keiyakusha View Post
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.
Briefly flying through what's in the first post of here, the nice thing is it looks like you could implement the filter on the GPU without any of the CUDA or OpenCL GPGPU BS. Possibly all you need is OpenGL with GLSL and FBO extensions. As a result you could use the filter even on older HW, without any special drivers or dependencies, and even be portable to Linux. My investigations will stop here though, and Turbo is right that a GPU implementation might not pay off due to bouncing textures on and off the GPU.
ultim is offline  
Old 12th November 2013, 10:16   #266  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by ultim View Post
Briefly flying through what's in the first post of here, the nice thing is it looks like you could implement the filter on the GPU without any of the CUDA or OpenCL GPGPU BS. Possibly all you need is OpenGL with GLSL and FBO extensions. As a result you could use the filter even on older HW, without any special drivers or dependencies, and even be portable to Linux. My investigations will stop here though, and Turbo is right that a GPU implementation might not pay off due to bouncing textures on and off the GPU.
I see. In other words, it is better just leave it alone and do something else. Because GPU implementation might not pay off due to bouncing textures, CPU implementation might not pay off due to nnedi being much better choice.
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.
Keiyakusha is offline  
Old 12th November 2013, 10:37   #267  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
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?
ryrynz is offline  
Old 12th November 2013, 10:38   #268  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by turbojet View Post
Looking forward to 64 bit and multithreading. A few questions:
1. Will the installer be able to extract the dll's with 7zip?
2. Will the dll package still be available?
1. 7zip can unpack the installer, yes. It's just an update of the NSIS script that classic AviSynth uses for its installer.
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.
qyot27 is offline  
Old 12th November 2013, 10:41   #269  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by ryrynz View Post
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?
No, it won't be easy.
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.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

Last edited by TurboPascal7; 12th November 2013 at 10:48. Reason: licenses
TurboPascal7 is offline  
Old 12th November 2013, 10:42   #270  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by ryrynz View Post
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?
I imagine that high bit depth support in general is a long-term goal, and most likely will emerge as 16-bits first, and then fill in with the in-between pixel formats later. Trying to specifically hack 10-bit support into the current codebase is probably not feasible, and anything described as a hack is certainly not desirable.
qyot27 is offline  
Old 12th November 2013, 11:21   #271  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by qyot27 View Post
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. ...
true, but when i get near a release, i will try to modify the installer to:
- 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?
ultim is offline  
Old 12th November 2013, 11:28   #272  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
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.
ultim is offline  
Old 13th November 2013, 00:36   #273  |  Link
turbojet
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
turbojet is offline  
Old 13th November 2013, 01:20   #274  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
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.
innocenat is offline  
Old 13th November 2013, 09:35   #275  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Keiyakusha View Post
I see. In other words, it is better just leave it alone and do something else. Because GPU implementation might not pay off due to bouncing textures, CPU implementation might not pay off due to nnedi being much better choice.
Well it depends on if you are willing to take the risks. Ofc a GPU implementation will be faster if the time lost by copying textures over the buses is a lot smaller than the time won by the GPU processing. If the filter it very slow, than GPU processing will probably still be a good choice. But this means whether it is worth it or not also depends on the difference in speed between your CPU and GPU. It is well posisble that someone with a slow-ish CPU but modern GPU will see a huge benefit, while another guy with a fast CPU but non-gaming (or old) GPU will be hurt by GPU processing.

Quote:
Originally Posted by innocenat View Post
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.
Exactly. Even if large parts have been rewritten, it is not practical to change the license without permission from previous authors, because without permission, we'd have to track every line which license applies for that particular line number.

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.
ultim is offline  
Old 13th November 2013, 09:38   #276  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
I'm perfectly fine with LGPL or any other more permissive license, if that matters.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline  
Old 13th November 2013, 10:42   #277  |  Link
malmsteen81
Registered User
 
Join Date: May 2012
Posts: 15
hi, with avisynth+ can i use the filter without setmode's istruction (for multi thread)? right?
malmsteen81 is offline  
Old 13th November 2013, 11:46   #278  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Avisynth+ is not multithreaded yet, there are no MT modes.
ryrynz is offline  
Old 14th November 2013, 03:59   #279  |  Link
andybkma
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.
andybkma is offline  
Old 14th November 2013, 09:46   #280  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
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.
qyot27 is offline  
Closed Thread

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 23:34.


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