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. |
22nd April 2016, 08:00 | #1441 | Link | |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
Plus VapourSynth doesn't support audio processing yet, nor can it be integrated with ffdshow. Correct me if I'm wrong, but VapourSynth still needs a lot of work to be a replacement to AviSynth. |
|
22nd April 2016, 08:13 | #1442 | Link |
Registered User
Join Date: Mar 2012
Location: Saint-Petersburg
Posts: 239
|
We're talking about Avisynth+ port for Linux
__________________
SVPflow motion interpolation |
22nd April 2016, 13:56 | #1443 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Oh... for Linux. Getting into politics here.
Would all the standard AviSynth filters work on Linux or have to be rewritten and recompiled? My opinion is that if all the plugins would work on Linux, porting AviSynth+ to Linux would be a great idea. If the plugins are window-specific, then the development may be better spent on VapourSynth. Based on my limited C understanding, I do believe most plugins are limited to Windows but could be made cross-platform quite easily. Except my AviSynthShader that is and will always remain Windows-only (unless someone wants to port the dead DX9 API to Linux?) All GPU-accelerated plugins may require more work to port. |
22nd April 2016, 14:21 | #1444 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
New AVS+ build: r1849 and vdubfilter.dll
x64/x86, including XP versions r1849 MT-pfmod (20160422) - Tweak internal FrameRegistry - [VDubFilter.dll] Fix: VirtualDub filter x64 crash - [VDubFilter.dll] Add: VirtualDub filter parameter type double This build primarily aims to fix virtualdub x64 issues. Special thanks to jpsdr for providing the test environment. Although avisynth.dll was not affected, since r1847 I put a minor tweak into the FrameRegistry logic (list->vector internally), sometimes it was faster a bit. So I included it also. Download r1849 and vdubfilter.dll: http://www.mediafire.com/download/fb...-vdubfilter.7z or https://github.com/pinterf/AviSynthP...r1849-MT-pfmod |
22nd April 2016, 19:38 | #1445 | Link | |
unsigned int
Join Date: Oct 2012
Location: 🇪🇺
Posts: 760
|
Quote:
__________________
Buy me a "coffee" and/or hire me to write code! |
|
22nd April 2016, 20:22 | #1446 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Clang may not require it, but GCC definitely does if you want a binary that's usable on anything older than the newest SIMD instruction set used in the intrinsics. Which means that AVX/AVX2 paths could not be added to the filters as soon as they're ready, because it would make CPUs older than Sandy Bridge/Haswell unable to run GCC builds of AviSynth+.
http://www.virtualdub.org/blog/pivot/entry.php?id=363 The 'workaround' for that (by littering __attribute__ or #pragma overrides throughout the file) is entirely either GCC-specific or messy, and thus, ineligible from how I understand the project coding guidelines. Not because it wouldn't work, but because it would also mean potentially adding tons of ifdefs just to make sure MSVC doesn't choke on them. The only option that leaves us with is to split the intrinsics per-SIMD into discrete files, and then use the build system to add the correct -mSIMD flags when building the files that need them and omit them otherwise. In fact, x265 did just what I described when they still relied on intrinsics rather than on yasm. Several autotools-based projects in the FFmpeg dependency chain also segregate their intrinsics this way, likely for the exact same reason(s). The thing that actually causes the problem is the inclusion of the intrinsics headers, which require the application of the -mSIMD flags in order to not fail compilation. But applying those project-wide means that codepaths that don't even use those SIMD sets will get optimized by the compiler for those sets, and become unable to run on anything lower. And the way to apply them per-file is to make sure the intrinsics are split into separate files so they don't contaminate each other. At which point it might as well be stated that GCC won't be supported, only Clang (if it doesn't require these contortions to make the intrinsics and runtime detection work right). |
22nd April 2016, 20:46 | #1447 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
*which is far from true; most plugins don't rely on Windows system calls (something IanB mentioned in the AvxSynth thread, as part of a musing that a thunking layer could make the Windows plugin *.dlls usable on Linux without recompiling them) and would only need to be able to be built by GCC or Clang with some fixes for how Linux expects libraries to act. And there's always the option of adding AviSynth+ interfaces to existing VapourSynth plugins that work better than their old AviSynth counterparts on Windows. Last edited by qyot27; 22nd April 2016 at 20:49. |
|
22nd April 2016, 20:47 | #1448 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Huh, it's not easy. I'd better stay in the background regarding any multiplatform things. Two month ago I even could not recognize that these codes were written in CPP. It was in 2000 when I was last using C In DOS I didn't need fancy constructor syntaxes. So I just listen and learn.
|
23rd April 2016, 18:46 | #1449 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
OK I've done some testing. The most stable with SVP is to use SVP 4.0.0.60 and MPC-HC 1.7.9 with AviSynth+. The latest SVP appears to crash more, so does MPC-HC 1.7.10 (maybe?)
After loading 20-30 videos in MPC-HC while playing with SVP, the player will freeze which requires to kill the process manually. |
23rd April 2016, 19:05 | #1450 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Also, have a look at this thread. I'd refuse to look into anything related to SVP. Last edited by Groucho2004; 23rd April 2016 at 19:11. |
|
24th April 2016, 06:17 | #1451 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
It's hard to identify where the bug is coming from when there are various components linked.
I've also been getting freezes on load when loading simple AVS+ scripts without SVP, although I haven't tried this latest version but I don't think the bug has been resolved since the last stable build. As for that thread, I refuse to go into GPL politics here. |
24th April 2016, 07:02 | #1452 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
OK I did some more testing. I have this script file.
Code:
P="Encoder\" LoadPlugin(P+"LSMASHSource.dll") LoadPlugin(P+"TimeStretch.dll") file="INNA - Endless.mkv" LWLibavVideoSource(file, cache=false) AudioDub(LWLibavAudioSource(file, cache=false)) ResampleAudio(48000) TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484) |
25th April 2016, 08:05 | #1455 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Prefetch(100) nightly MT stress-test.
15 cycles, w/o problem Script: Code:
SetFilterMTMode("DEFAULT_MT_MODE",2) SetFilterMTMode("AviSource",3) SetMemoryMax(6000) Avisource("Tape02_Hi8.avi").killaudio().assumefps(25,1) AssumeBFF() QTGMC(Preset="Fast") prefetch(100) Code:
AVSMeter 2.2.2 (x64) AviSynth+ 0.1 (r1849, MT-pfmod, x86_64) (0.1.0.0) Number of frames: 278762 Length (hh:mm:ss.ms): 01:32:55.240 Frame width: 720 Frame height: 576 Framerate: 50.000 (50/1) Colorspace: YV12 Frames processed: 278762 (0 - 278761) FPS (min | max | average): 3.365 | 1226976 | 110.3 Memory usage (phys | virt): 4773 | 4950 MiB Thread count: 918 CPU usage (average): 96% Time (elapsed): 00:42:06.507 |
25th April 2016, 13:13 | #1458 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
- MPC-HC 32 bit 1.7.9 and 1.7.10 - TimeStretchPlugin found here: http://avisynth.nl/index.php/TimeStr...#Audio_Filters linked to here http://forum.doom9.org/showpost.php?...2&postcount=20 - LSMASHSource.dll LSMASHSource-AviSynth-plugin-r859-msvc-32bit.7z and LSMASHSource-AviSynth-plugin-r877-msvc-32bit.7z - Avs+ 1841 and 1849 (32 bit) No freeze here. Which version of LSMASHSource are you using? Maybe you could send me the source mkv, or you can trim it if it is too large (and the trimmed version also produces the freeze) |
|
25th April 2016, 16:20 | #1459 | Link |
Please, DeInterlace me!
Join Date: Jan 2007
Location: Portugal, Porto
Posts: 81
|
Hi there, I've installed avisynth+. I've windows 7 x64.
I'm trying just to do the basic of the basics. To be able to run FFVideoSource, but I got the message "There is no function". I got here the ffms2: https://github.com/FFMS/ffms2/releases If I use the folder plugins, and put the x86 version on it, all runs well. BUT, if I put the x64 dll on the plugins64, it doesn't work, why? (I am trying to work with the fastest plugins, for the same results) And I've a clean install, so if I put x86 ffms2 on plugins+, it will work too. But which is the difference between plugins and plugins+?(I presume the + will be faster?) How do I know it will work on plugins+? (just testing it?) But for 64 bits, I am not able to put this working. If I put only the ffms2 x64 version on the plugins64 or plugins64+ it doesnt work :/ And where can I find plugins for plugins+? And for x64? Cheers!
__________________
Who am I?! I'm GOD... 8for it... father of my godchilds. Last edited by Leinad4Mind; 25th April 2016 at 16:40. |
25th April 2016, 16:43 | #1460 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
plugins+ is intended to be for AviSynth+-specific plugins. Currently, there really aren't any because the AviSynth+ API hasn't matured yet and developing plugins against it is still officially discouraged. The plugins built from the AviSynth+ source code are a plausible set to place there, but in the end it really doesn't matter - the reason for the directory separation was for cleanliness (because unlike classic AviSynth, avsplus can use multiple plugin directories), not for some magical purpose.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|