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. |
15th September 2016, 00:24 | #2401 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
|
|
16th September 2016, 09:41 | #2403 | Link |
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. |
17th September 2016, 18:28 | #2404 | Link |
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... |
19th September 2016, 08:23 | #2406 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
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. |
|
20th September 2016, 07:50 | #2407 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
even in Y8?
__________________
See My Avisynth Stuff |
20th September 2016, 08:46 | #2408 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
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. |
23rd September 2016, 15:59 | #2409 | Link |
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 For the former, the compilation stops here: Code:
https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/DirectShowSource/directshow_source.cpp#L112 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 Code:
const char _AVS_VERSTR[] = AVS_VERSTR; const char _AVS_COPYRIGHT[] = AVS_VERSTR AVS_COPYRIGHT; Code:
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/focus.cpp#L558 Code:
'y': redefinition; different basic types AvsCore D:\AviSynthPlus\avs_core\filters\focus.cpp |
23rd September 2016, 16:41 | #2410 | Link | ||
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
This was an old problem, had to put spaces before (around?) __DATE__ and __TIME__ Quote:
(VS2015 is the "official" compiler for the project) |
||
24th September 2016, 04:59 | #2411 | Link |
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. |
24th September 2016, 05:26 | #2413 | Link |
...?
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 |
24th September 2016, 06:23 | #2414 | Link |
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. |
24th September 2016, 07:18 | #2415 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
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. |
|
24th September 2016, 10:04 | #2417 | Link |
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. |
24th September 2016, 11:04 | #2420 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|