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 15th September 2016, 00:24   #2401  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by StainlessS View Post
Possibly connected to AVS Standard MergeChroma problem, here:- http://forum.doom9.org/showthread.ph...31#post1504231
Was originally
Code:
MergeChroma (clip1, clip2, float Chromaweight=1.0)
IanB Added Alias
Code:
MergeChroma (clip1, clip2, float weight=1.0)
Perhaps it did not make it into AVS+

EDIT: And MergeLuma used LumaWeight, also added the Weight alias. [EDIT: About v2.6 Alpha 3, period].
The fork happened right around the run-up to 2.6a5 (the initial patchset was discussed in the Alpha 4 thread only 1 or 2 weeks before Alpha 5 was released), so anything added prior to that would be included automatically and wouldn't need specific porting. Commits from after Alpha 5 have been periodically reviewed and merged if there aren't any conflicts, or if there are few enough conflicts in a commit that the patch can still be updated easily and merged in.
qyot27 is offline  
Old 15th September 2016, 18:05   #2402  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by Motenai Yoda View Post
thanks
the weight part on yv12
Fixed in the development branch. Only 16 bit path worked correctly. MergeLuma and Merge was not affected. Thank you for the report.
pinterf is offline  
Old 16th September 2016, 09:41   #2403  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Don't know where to put information, but Microsoft just released a new VS2015 Updt3 redistribuable : 14.0.24215 (the previous was 24212).
I thought i have to put this information here, as the redistribuable is sometimes critical...

Last edited by jpsdr; 16th September 2016 at 09:45.
jpsdr is offline  
Old 17th September 2016, 18:28   #2404  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Huh, now I can see the end of the tunnel.

Almost all internal filters are ported to native 10-12-14-16 bit, and float formats, Planar RGB(A), RGB48 and 64.
Histogram and Overlay is still under development.

From Histogram only "Levels" is ported, it has a shiny new bits=xxx parameter, you can visualize YUV histogram with 9, 10, 11 or 12 bits precision. Use bits=12 if you have a 8K monitor
From Overlay modes so far only "add" is ported to 10-16 bits. Unfortunately, like Histogram sub-modes, each Overlay mode is a unique filter, so they have to be ported one-by-one.

And now, let's back to work...
pinterf is offline  
Old 18th September 2016, 09:31   #2405  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
Will Overlay still convert everything to YUV444 internally? And what about Layer, will those two be merged at some point and simply be aliases for the same thing?
ajp_anton is offline  
Old 19th September 2016, 08:23   #2406  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by ajp_anton View Post
Will Overlay still convert everything to YUV444 internally? And what about Layer, will those two be merged at some point and simply be aliases for the same thing?
Yes, at some point
Overlay still converts everything to 444 internally. Using 420 and 422 natively (when I was porting "add" method) was more than difficult (=time consuming), it would require rather a rewrite than a patch or conversion.
pinterf is offline  
Old 20th September 2016, 07:50   #2407  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by pinterf View Post
Yes, at some point
Overlay still converts everything to 444 internally. Using 420 and 422 natively (when I was porting "add" method) was more than difficult (=time consuming), it would require rather a rewrite than a patch or conversion.
even in Y8?
__________________
See My Avisynth Stuff
real.finder is offline  
Old 20th September 2016, 08:46   #2408  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by real.finder View Post
even in Y8?
Yes.

I have never used Overlay, but I had the feeling that it would be the ugliest part of the port. No wonder I left it to the last one

Overlay used internal converters for the basic color spaces (Y8, YV12, YUY2, RGB (PC.601/rec601) and YV24, that (at least for YV12 and YUY2) were much faster than simply doing "Invoke" for the similar avisynth core converters. I have the feeling that all this was programmed before YV24 color space have emerged.

Since in Avisynth plus we have much more possible input/output formats than before, first I simply replaced the internal converters with Invoke ConvertToYUV444. But it was slow, very slow (2-4 times slower than before) for YV12 and YUY2. I can live without YUY2, but you know, the goal is "not slower than before". At least not _that much_ slower.

Because core converters are generic, e.g. for YV12 the chroma gets properly resized with the appropriate method (using a generic avisynth resizer: bilinear AFAIK as default). YUY2 conversion in avisynth core first converts the frame to YV16 than converts it further to YV24, again: chroma resize takes place here, another Invoke, caching, etc. It has simply too much overhead.

Overlay's internal resizer is fast, because it is specific, simply spreads YV12 chroma to double size for YV24, and averages back when converting to YV24 again. In one simple pass. Y8 conversion to the internal 444 format is a simple luma copy plus fill chroma with neutral grey.

On the other side, the 444 format of Overlay filter has (had) special internal buffers holding the frame, so it even copied a standard YV24 frame to this internal 444 representation, and back when output was YV24.

This latter case is optimized now a bit, using avisynth's standard YV24 (now YUV444P8..16) frames, so at least the YV24 double conversion (from and to) is omitted now and the filter is a bit faster in general.

But because of that speed difference, I had to put back the YUY2 and YV12 conversions to use the existing converters of Overlay. All other conversions use avisynth's core converters.

Because of the speed difference experienced (why convert 4:2:0 to 4:4:4 then back?) I tried to implement a conversionless method, to have Overlay work with native 420 and 422 formats, but it would need more time.

Last edited by pinterf; 20th September 2016 at 08:48.
pinterf is offline  
Old 23rd September 2016, 15:59   #2409  |  Link
THEAST
Registered User
 
Join Date: Apr 2009
Posts: 76
I am trying to manually build the latest version of Avisynth+ from the github repository using MSVC2015. I know that it is probably not officially supported but I thought I'd try anyway. I am using this build:

Code:
https://github.com/pinterf/AviSynthPlus/commit/547f536d28039c79bfb76d777701b83d9188cb8a
Everything seems to compile fine except the main stuff: the DirectShow plugin and Avisynth.dll.

For the former, the compilation stops here:

Code:
https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/DirectShowSource/directshow_source.cpp#L112
And this is the error:

Code:
user-defined literal suffix does not match the earlier "__DATE__"	PluginDirectShowSource	d:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
cannot concatenate user-defined string literals with mismatched literal suffix identifiers	PluginDirectShowSource	D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
invalid literal suffix '__DATE__'; literal operator or literal operator template 'operator ""__DATE__' not found	PluginDirectShowSource	D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
For the latter the compilation stops here:
Code:
const char _AVS_VERSTR[]    = AVS_VERSTR;
const char _AVS_COPYRIGHT[] = AVS_VERSTR AVS_COPYRIGHT;
This is from "AviSynthPlus\avs_core\core\main.cpp", line 113 and 114, but doesn't exist on the copy on github; I guess it is generated by cmake. It seems in my case, "AVS_VERSTR" seems to be undefined. I am probably doing something wrong here since I would expect cmake to define it. I tried defining it manually and the compilation went forward but still stopped here:

Code:
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/focus.cpp#L558
The error is:

Code:
'y': redefinition; different basic types	AvsCore	D:\AviSynthPlus\avs_core\filters\focus.cpp
Any idea how to fix these issues?
THEAST is offline  
Old 23rd September 2016, 16:41   #2410  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by THEAST View Post
For the former, the compilation stops here:

Code:
https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/DirectShowSource/directshow_source.cpp#L112
And this is the error:

Code:
user-defined literal suffix does not match the earlier "__DATE__"	PluginDirectShowSource	d:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
cannot concatenate user-defined string literals with mismatched literal suffix identifiers	PluginDirectShowSource	D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
invalid literal suffix '__DATE__'; literal operator or literal operator template 'operator ""__DATE__' not found	PluginDirectShowSource	D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
Are you sure that you have switched to the MT branch?
This was an old problem, had to put spaces before (around?) __DATE__ and __TIME__

Quote:
Originally Posted by THEAST View Post
Code:
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/focus.cpp#L558
The error is:

Code:
'y': redefinition; different basic types	AvsCore	D:\AviSynthPlus\avs_core\filters\focus.cpp
Any idea how to fix these issues?
The same for this. This compilation error was fixed already. Check the function, the loop variable should be y0 for the current source and not y.

(VS2015 is the "official" compiler for the project)
pinterf is offline  
Old 24th September 2016, 04:59   #2411  |  Link
THEAST
Registered User
 
Join Date: Apr 2009
Posts: 76
Ouch, you are right, I was on the master branch. I knew I was making an obvious mistake. I will switch to MT and try again, sorry for the inconvenience.

P.S. The compilation guide on the first page recommends MSVC 2013, that is why I thought 2013 is the maximum version that is officially supported.

Last edited by THEAST; 24th September 2016 at 05:01.
THEAST is offline  
Old 24th September 2016, 05:09   #2412  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
You will need Chikuzen's pull request for turn.cpp and .h. that I simply copied for my mt branch w/o properly using git.
See them in the current avs+ pull request list
pinterf is offline  
Old 24th September 2016, 05:26   #2413  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Or for ease of use:
Code:
git clone git://github.com/pinterf/AviSynthPlus.git
cd AviSynthPlus
git checkout MT
git remote add chikuzen git://github.com/chikuzen/AviSynthPlus.git
git fetch chikuzen
git checkout -b turn chikuzen/turn
git checkout MT
git merge turn
and then go about compiling.
qyot27 is offline  
Old 24th September 2016, 06:23   #2414  |  Link
THEAST
Registered User
 
Join Date: Apr 2009
Posts: 76
Right on time, I just got to the part where Avisynth still didn't compile because the turn functions were undefined. :p

Edit: Okay, it finally worked, thank you for the help. :)

Last edited by THEAST; 24th September 2016 at 06:38.
THEAST is offline  
Old 24th September 2016, 07:18   #2415  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by THEAST View Post
Right on time, I just got to the part where Avisynth still didn't compile because the turn functions were undefined.

Edit: Okay, it finally worked, thank you for the help.
When you find something strange, don't hesitate to report it.

If someone is curious about what has been done in the past month, read my comments here: https://github.com/AviSynth/AviSynthPlus/pull/101 since I comment the changes in the pull request of the mainstream project.
pinterf is offline  
Old 24th September 2016, 09:15   #2416  |  Link
kypec
User of free A/V tools
 
kypec's Avatar
 
Join Date: Jul 2006
Location: SK
Posts: 826
Quote:
Originally Posted by THEAST View Post
P.S. The compilation guide on the first page recommends MSVC 2013, that is why I thought 2013 is the maximum version that is officially supported.
Not that I would be compiling Avisynth+ myself but the recommended tools usually mean the minimum supported version. Compilers should be mostly backward compatible.
kypec is offline  
Old 24th September 2016, 10:04   #2417  |  Link
THEAST
Registered User
 
Join Date: Apr 2009
Posts: 76
@kypec, bad assumption on my part. ;p

Anyway, I built the latest revision with both MSVC 2015 Update 3 and ICC 2016 Update 4 and compared with r1689 that I was using before using AVSMeter. For a SD video with QTGMC (medium options) and prefetch(12), the latest revision built with MSVC is 0.5-1% faster than 1689. The iCC version is actually slower than both which is very surprising. For another script with a 1080p video resized to 720p using Spline36 and running with one thread, latest revision built with MSVC and r1689 have the same speed while the ICC version is again slower than both. Fortunately, unlike the revisions after 1689 that I tested before Avisynth+ development was resumed, the latest build does not run into a deadlock with QTGMC.

Other than these, I am also experiencing the "Only a single prefetcher is allowed per script." error when using DGDecode_mpeg2source, which was reported by bilditup1 a few pages ago. Is there any fix or workaround for this?

I also remember that somewhere after r1689, "SetFilterMTMode("", 2)" stopped working and had to be replaced by "SetFilterMTMode("DEFAULT_MT_MODE", 2)" for MT to work correctly, but it seems both work as expected in the latest revision. Can somebody comment which one is considered the official syntax now?

Last edited by THEAST; 24th September 2016 at 12:27.
THEAST is offline  
Old 24th September 2016, 10:07   #2418  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
Why posting an URL as CODE insted of a link?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline  
Old 24th September 2016, 10:14   #2419  |  Link
THEAST
Registered User
 
Join Date: Apr 2009
Posts: 76
@LigH, sorry, bad habit. I have Linkification installed which makes all links clickable, didn't realize others have to copy/paste the link into address bar.
THEAST is offline  
Old 24th September 2016, 11:04   #2420  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by THEAST View Post
The iCC version is actually slower than both which is very surprising.
Not at all. AVS+ has lots of the performance critical code already in SIMD intrinsics which means that the Intel compiler can't improve anything - probably make it worse by being overzealous in its optimization efforts.
__________________
Groucho's Avisynth Stuff

Last edited by Groucho2004; 24th September 2016 at 11:20.
Groucho2004 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 11:48.


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