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 17th May 2016, 13:35   #1581  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Honestly, I wouldn't try to convince the community to rebuild all plugins with AviSynth+ 16-bit support until AviSynth+ itself is good enough to convince the majority of users to use it instead of v2.6

Which brings this question: are there still reasons for people to keep using AviSynth 2.6 at this point?
MysteryX is offline   Reply With Quote
Old 17th May 2016, 14:01   #1582  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
Quote:
Originally Posted by MysteryX View Post
Isn't AviSynth supposed to be written with plain C to work with various compilers?
There are intrinsics, the problem was mentioned recently.

Quote:
Originally Posted by MysteryX View Post
and what would be the advantages over using Stack16 format? 16-bit processing can be done right now with Stack16 format and AviSynthShader.
Ugly and slow. Dead end but exists because of Avisynth limitations.

Quote:
Originally Posted by MysteryX View Post
In terms of major features, there are 2 options for next steps:
1. Getting x64 to work as expected
I think this point now depends on plugin writers.

Quote:
Originally Posted by MysteryX View Post
2. Implementing 16-bit support
Which one is most important?
I believe that fixing the code for x64 might uncover a few hidden issues affecting the x86 build. Working on 16-bit support is definitely more exciting to program.
The second point is more entertaining for me. Personally I don't like coding if there is no fun in doing it.

I wouldn't convince anyone. We are still in the phase of convincing plugin writers to support the avs 2.6 color spaces as a minimum.
pinterf is offline   Reply With Quote
Old 17th May 2016, 14:47   #1583  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,117
Quote:
Originally Posted by pinterf View Post
Then I think we should create a version with real installer. Volunteer needed for this task.
stax76 made installers for r1779 and r1825, maybe he can help out.

Quote:
Originally Posted by MysteryX View Post
Perhaps it would be good to post this list on the first page of this thread? It's difficult to find.

I tried this list and this showed up corrupt
Code:
nnedi3_rpow2(2)
Adding this doesn't help
Code:
SetFilterMTMode("nnedi3_rpow2",         MT_MULTI_INSTANCE)
So the problem must be in one of the other filters being called by NNEDI3; kind of hard to debug.
It seems the output for nnedi3_rpow2 is corrupt for all colorspaces except YV24 and Y8. nnedi3_rpow2 uses the turning functions and resizers (for correcting center shift, only when cshift is enabled). Maybe jpsdr can help out.

Code:
SetFilterMTMode("nnedi3",       2)
SetFilterMTMode("nnedi3_rpow2", 2)

ColorBars()
ConvertToRGB24()
nnedi3_rpow2(2)
Prefetch(4)
Quote:
Originally Posted by MysteryX View Post
You can add this to the list.
ConvertToShader, ConvertFromShader and Shader support MT=1. ExecuteShader supports MT=2.
I'll add it, better yet, maybe you can make your plugin self-register the appropriate MT mode. Take a look here: http://forum.doom9.org/showthread.ph...29#post1667529

Quote:
Originally Posted by MysteryX View Post
Why not use the existing installer? Who produced it? Is the source code available? Ideally we'd have an open source Inno Setup project file that anyone can edit and build. I'd put that Inno Setup file in the same repository as AviSynth+.
Line0 made the installer and it's already in the repository: https://github.com/pinterf/AviSynthP...-pfmod/distrib

Last edited by Reel.Deel; 29th May 2016 at 13:39. Reason: link
Reel.Deel is offline   Reply With Quote
Old 17th May 2016, 21:19   #1584  |  Link
yesmanitsbearman
Registered User
 
Join Date: May 2015
Posts: 18
Just a random note, I have done a first full 64 bit encode with
sanimebob()
srestore(omode=4, cache=10).srestore(frate=23.976)
smam()

Only thing that was missing really is GrunT plugin x64 build. I have made one and posted in appropriate thread. Perhaps someone can add it to the wiki.
yesmanitsbearman is offline   Reply With Quote
Old 17th May 2016, 21:32   #1585  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,084
Quote:
Originally Posted by pinterf View Post
After this I think I will clean the code a bit and merge back all my modifications to my master branch and get rid of the pfmod suffix.
The better way would be to open a pull request for your changes (not with the fixes from Chizuken, etc.) on the upstream git repo, just to keep things clean. Upstream doesn't use master for the MT stuff yet, so it could potentially create all sorts of headaches when/if ultim shows up again.

I have no clue if anyone else (tp7?) has commit privileges to the main repo; because it would make things a lot easier if more than one person had the ability to push and were more easily contacted, just in case. Worse comes to worst, a new organization and repo setup would be needed to make sure there's always someone to commit (I could do that, I just would prefer not to until there's no other choice).

And remember when cleaning up that AviSynth+ uses four white spaces for indentation, not tabs.

Quote:
There are still many interesting tasks, qyot27 mentioned the possibility for using non MSVC compilers (clang?). Or playing with preparing the core for 16bit/float support, this will require an extended interface later.
ultim started adding stubs for a newer AviSynth+-specific API, but it's never stabilized. High bit depth likely would have been part of that.

The non-MSVC compiler thing would mostly be when targeting non-Windows. Linux and OSX support in particular (clang is OSX's and FreeBSD's default compiler).

Quote:
Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future? Can we expect a more dynamic development cycle there or we can experiment with it freely? I could ask them (who?) directly but maybe you, old guys here with broader knowledge on the avs history and developers can give some informations about it.
Generally, we've been caring less and less about what classic AviSynth does, if only for the fact that the entire reason Plus exists is because Classic (or rather, IanB, who is pretty much the only active dev to classic aside from Wilbert occasionally fixing things) was resistant to ultim's changes - partly because there were so many of them at the time*. But 2.6 development has been moving at a snail's pace for years; last I checked, the CVS for it hasn't been touched since last September.

*somewhere around 56 commits; but after the fork happened, Plus development rocketed forward with several hundreds of commits in a very short timeframe. And then Plus entered a hiatus for about a year, then another sprint of activity in March 2015, and that's more or less where we are today.

In the wake of 2.6's RC1 and RC2/RC3/Final updates, I've taken the CVS history, compared it against AviSynth+, determined to the best of my ability what can be merged, and opened a pull request containing those changes. The RC1 integration was what started things up again in March 2015, which eventually left off at r1825. RC2/RC3/Final was so meager that it still hasn't been merged (also, there was a bit of a back-and-forth about the issues of Plus' changes to avisynth.h during the restricted license era and moving them up into the restored-clause header; the C interface header, avisynth_c.h, never had this problem - it's completely unique to the C++ interface AviSynth traditionally focused on).

Quote:
Originally Posted by MysteryX View Post
Isn't AviSynth supposed to be written with plain C to work with various compilers?
AviSynth is written in C++. AviSynth+ moved this requirement to C++11. It's only ever been expected to be compiled on MSVC or MSVC-compliant compilers (like ICL), so things like portability weren't that big of a concern.

The problem isn't actually the code, it's the fact that the main AviSynth API was written in C++ as well, which means that C++ plugins have to be built with the same compiler as the core or else they'll fail to load. This stems from VC++ and g++ not being compatible with each other's addressing and name mangling and all sorts of other things. For plain C, cl and gcc are [mostly?] compatible, and is why the C interface exists.

At least what I hoped (and the talk seemed to be leaning toward) was that any new AviSynth+ APIs would be written in C or the C interface would be mainlined and focused on (especially with a potential move to Linux/OSX), which would erase the portability problem from the start. The C++ problem doesn't matter on non-Windows, though, since they don't have the VC++/g++ divide to worry about.

Quote:
Originally Posted by pinterf View Post
There are intrinsics, the problem was mentioned recently.
The intrinsics issue has less to do with whether it will build and far more to do with not causing grief for users with even slightly older computers to use them. It was also specifically in regard to building with GCC; if Clang truly does not require the same 'intrinsics must be split' nonsense, then dealing with them is not the dealbreaker for cross-platform support that it is with GCC.

The intrinsics themselves are portable; in fact, they replaced the extremely non-portable SoftWire assembly that classic AviSynth relies on (and improved performance over SoftWire in most cases as well).
qyot27 is online now   Reply With Quote
Old 18th May 2016, 01:11   #1586  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,073
Quote:
Originally Posted by pinterf View Post
Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future?
Quote:
Originally Posted by MysteryX View Post
Isn't AviSynth supposed to be written with plain C to work with various compilers?
The current Avisynth 2.6 development effort (alpha release earlier today!) is dedicated to making it possible to build Avisynth with any Microsoft Visual C++ version newer than 6.0. Up until now, it was not possible to build "official" Avisynth builds with any compiler other than VC6. Microsoft Visual C++ 6.0 was released in 1998. I don't call Avisynth software for the previous millennium only to provoke people - it's the literal truth.

Official Avisynth development is as dead as a doornail. You don't need to care about what happens with it. You don't even need support its plugins if you don't want to (but you can if you want to; if VS can fake the plugin interface so can you). Fork away - there are already like five commonly used variants competing for attention so one more can hardly hurt.

Last edited by TheFluff; 18th May 2016 at 01:15.
TheFluff is offline   Reply With Quote
Old 18th May 2016, 06:38   #1587  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Quote:
Originally Posted by TheFluff View Post
Official Avisynth development is as dead as a doornail. You don't need to care about what happens with it. You don't even need support its plugins if you don't want to (but you can if you want to; if VS can fake the plugin interface so can you). Fork away - there are already like five commonly used variants competing for attention so one more can hardly hurt.
To be honest, the advantage of AviSynth over VapourSynth is mainly the vast library of available plugins.

If you create a custom interface for AviSynth+, I think it is very unlikely that plugin developers will get back in the game years after they wrote their plugin to support the new interface. Working on porting those plugins to VapourSynth would be a better path for them.

But then VapourSynth has these limitations:
- No ffdshow support for SVP
- No audio support yet
- Limited library of plugins

In which cases AviSynth+ comes to the rescue.
MysteryX is offline   Reply With Quote
Old 18th May 2016, 06:41   #1588  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
btw, AviSynth 2.6 requires DevIL. Does AviSynth+ depend on that same library?
MysteryX is offline   Reply With Quote
Old 18th May 2016, 06:59   #1589  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Bug: NNEDI3 simply doesn't work with MT. It causes image corruption.

Code:
SetFilterMTMode("DEFAULT_MT_MODE", 3) #neither 2 nor 3 works
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3_rpow2(2, Threads=1)
Prefetch(8)
So this looks like a bug in AviSynth+. Without MT, it works.
MysteryX is offline   Reply With Quote
Old 18th May 2016, 07:19   #1590  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by qyot27 View Post
I have no clue if anyone else (tp7?) has commit privileges to the main repo; because it would make things a lot easier if more than one person had the ability to push and were more easily contacted, just in case.
I have full repository rights and unless something unexpected happens will be there to (at least lazily) review the changes and merge the PR, assuming debug/blogging commits will be cleaned up.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline   Reply With Quote
Old 18th May 2016, 09:33   #1591  |  Link
Groucho2004
Cantankerous Fossil
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Location: A wretched hive of scum and villainy
Posts: 4,470
Quote:
Originally Posted by MysteryX View Post
Bug: NNEDI3 simply doesn't work with MT. It causes image corruption.

Code:
SetFilterMTMode("DEFAULT_MT_MODE", 3) #neither 2 nor 3 works
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3_rpow2(2, Threads=1)
Prefetch(8)
So this looks like a bug in AviSynth+. Without MT, it works.
Try this:
Code:
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3(dh = true, Threads=1)
fturnleft()
nnedi3(dh = true, Threads=1)
fturnright()
Prefetch(8)
Groucho2004 is offline   Reply With Quote
Old 18th May 2016, 09:41   #1592  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
Quote:
Originally Posted by TurboPascal7 View Post
I have full repository rights and unless something unexpected happens will be there to (at least lazily) review the changes and merge the PR, assuming debug/blogging commits will be cleaned up.
Yes, that's why I still left my original master branch untouched, did not want to mess it up with excessive comments that were important for me at that time.
pinterf is offline   Reply With Quote
Old 18th May 2016, 10:04   #1593  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Quote:
Originally Posted by Groucho2004 View Post
Try this:
Code:
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3(dh = true, Threads=1)
fturnleft()
nnedi3(dh = true, Threads=1)
fturnright()
Prefetch(8)
This one is working; and with turnleft instead of fturnleft it works too. Strange that the standard function is failing.

edi_rpow2 works though.
MysteryX is offline   Reply With Quote
Old 18th May 2016, 10:33   #1594  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,764
Quote:
Originally Posted by Reel.Deel View Post
Maybe jpsdr can help out.
Sorry, but not realy. I don't see anything suspcious in the code, but and all the MT thing is not realy my stuff.
I think the code for nnedi3_rpow2 is linear (and clear i hope...) enough to reproduce all the steps/functions used in an avs script, if someone want to investigate.
jpsdr is offline   Reply With Quote
Old 18th May 2016, 12:20   #1595  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
This nnedi_rpow2 thing happens in YV12 and YV16. No Prefetch and Prefetch(1) is OK. Nice task.
pinterf is offline   Reply With Quote
Old 18th May 2016, 13:45   #1596  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,764
In that case, it probably also happen in YV411 and YUYV.
As it can easely be seen in the code, there is two paths : (RGB24,YV24,Y8) and (YV16,YV12,YV411,YUYV).
The only major difference between them it's that in case of YV16 and others, planes are extracted and processed separately.
But again, i see absolutely nothing wrong.
If the MT mode is not happy with the way i do things, you'll have to explain me where and why.
The code is avaible on github, so anyone is free to take a look.
jpsdr is offline   Reply With Quote
Old 18th May 2016, 14:00   #1597  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
If MT doesn't like it, the question remains: why does it work with AviSynth 2.6 and not in AviSynth+?
MysteryX is offline   Reply With Quote
Old 18th May 2016, 15:37   #1598  |  Link
Groucho2004
Cantankerous Fossil
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Location: A wretched hive of scum and villainy
Posts: 4,470
Quote:
Originally Posted by jpsdr View Post
In that case, it probably also happen in YV411 and YUYV.
As it can easely be seen in the code, there is two paths : (RGB24,YV24,Y8) and (YV16,YV12,YV411,YUYV).
The only major difference between them it's that in case of YV16 and others, planes are extracted and processed separately.
But again, i see absolutely nothing wrong.
The problem is the same in the original nnedi3 from tritical. I don't think your changes have anything to do with it.
Groucho2004 is offline   Reply With Quote
Old 18th May 2016, 18:06   #1599  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 597
Interesting information was written on comment space of this page by Takuan (Oh, he is my internet friend).
http://archive.fo/DvrEB
Quote:
Takuan 2014/3/22 05:37

DGDecode_MPEG2Source returns 'env->Invoke(“crop”, AVSValue(CropArgs,5));' when crop is needed.
avs+ recognizes this filter as Crop(), not MPEG2Source() in this case.
avs+ tries to make MPEG2Source() work as MT_NICE_FILTER because Crop() is set as MT_NICE_FILTER internally.
This is why MPEG2Source crash on avs+'s MT mode.

Thus, you should set SetFilterMTMode("Crop", MT_SERIALIZED, force=true) when MPEG2Source requires Crop().
Probably, nnedi3_rpow2 will be recognized as internal resizer(MT_NICE_FILTER).
So you should use user script function instead of nnedi3_rpow2 when you want to set prefetch() if my guess is correct.
__________________
my repositories

Last edited by Chikuzen; 18th May 2016 at 20:17.
Chikuzen is offline   Reply With Quote
Old 18th May 2016, 19:29   #1600  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,117
Interesting information chikuzen. I saw that too when I asked about the force parameter in SetFilterMTMode, I didn't quite understand it though. The MPEG2Source issue was fixed so maybe there's hope for nnedi3_row2. More information here: https://github.com/AviSynth/AviSynthPlus/issues/37
Reel.Deel 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 23:07.


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