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 January 2014, 09:33 | #490 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
So here is a small update on the status of the MT version of avs+. I'm planning on stabilizing this ASAP now, merging it to my usual main branch this week. This also means that all pull requests and even non-MT work will end up in an MT-enabled build from now on.
I spent most of my development time last weekend hunting down the source of some uninitialized memory, so I got somewhat delayed, but hopefully by the end of this week I'll publish a new experimental build, and for plugin developers most importantly, I'm also pushing the whole work to GitHub. There are only a couple of things left on my to-do list, with one exception (addressing a theoretical deadlock) just build- or performance enhancements. A slight difference to previous plans is that I'm splitting the current threadpool into two, one for the core threads and one for filter-initiated threads. This is made necessary to avoid the previously mentioned theoretical deadlock, 'coz any other alternative (instead of the threadpool split) that comes to my mind would involve some sophisticated (and error-prone!) locking trickery with questionable benefits. The split will simplify code a lot compared to other fixes, and should not hurt performance. It would be nice to have the new documentation ready by then, extended with all the Avs+ and new MT-specific stuff, so that interested developers could consult it at once, but that won't be done by this week for sure. That's because even though qyot has done most of the hard work on converting the docs format (oh Lord it's awesome), there is still some left to be done, and coupled with my other to-do items, the weekend just won't be enough. One way you guys can help me to make MT usable as soon as possible now, is to help collect what MT modes existing filters need. The three supported MT modes are the same as for SEt's version, 1 - no protection needed at all, 2 - multiple filter instances per call (one per thread), and 3 - just one filter for all threads but protected by exclusive area. It'd be our collective interest to collect what each filter needs, or if there is maybe already a list like that, to extend/update it. The rules could ship with avs+ then to make it readily usable. So can I leave you to assemble this list? Maybe on a Wiki page? Active plugin developers can include the rules for their filters inside their own plugin, so those do not need to be on the list. They will be able to start including the functionality as soon as I push the new avisynth.h this week. Moreover, they can do so while still staying compatible with classic (non-plus) Avs.
__________________
AviSynth+ Last edited by ultim; 15th January 2014 at 10:17. |
15th January 2014, 13:03 | #493 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
for me mode 2 work in 90% of filters, Especially in the last SEt builders, by now I use mode 2 only even with tdecimate 2pass vfr Which were not compatible in the past
Waiting for the new header and MT thanks |
15th January 2014, 22:38 | #494 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
As I understand due to new way of auto loading plugins (pending them to the later time) avs_function_exists from C-interface fails to find out that DirectShowSource is available. This result in fail to open video files in x264 when you specify as input media file (any mkv file and --demuxer avs to be sure not to use lavf input) and not the avs script file. Is there is way to fix it from AviSynth+ side or what have to be added from x264 side so avs_function_exists will work?
|
16th January 2014, 00:23 | #495 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
Code:
>x264 --preset ultrafast --crf 18 -o test.mkv "Qyot27 - Daybreak [XviD+MP3].mkv" --frames 10 --demuxer avs --verbose avs [debug]: using avisynth version 2.60 avs [info]: trying FFmpegSource2... not found avs [info]: trying DSS2... not found avs [info]: trying DirectShowSource... not found avs [error]: unable to find source filter to open `Qyot27 - Daybreak [XviD+MP3].mkv' x264 [error]: could not open input file `Qyot27 - Daybreak [XviD+MP3].mkv' |
|
16th January 2014, 11:29 | #497 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Avs+ autoloads plugins if any of the following happens:
- AutoloadPlugins() is called - LoadPlugin() is called - A yet unknown (non-internal) function is called avs_function_exists does not find the external source filter in this case because none of the above happened. So MasterNobody's patch is the right thing to do.
__________________
AviSynth+ |
16th January 2014, 11:50 | #498 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
|
|
16th January 2014, 13:02 | #499 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
On the other hand, the reason I'm not perfectly satisfied with FunctionExists() autoloading is because FunctionExists() has the semantics of a getter function. It is pretty unexpected that it changes the internal state greatly (even if we are talking about non-observable state). I have to conclude though that this rather ideological argument is outweighed by the proposed solution's practical relevance. So I guess I will correct this in Avisynth+ after all.
__________________
AviSynth+ |
|
17th January 2014, 17:52 | #500 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
hi
I have two aWarpSharp in autoload folder, aWarpSharp and aWarpSharp2 by SEt In normal avs if I use Code:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\aWarpSharp.dll") someSource("E:\New.mkv") aWarpSharp but in avs+ only aWarpSharp2 will be used I use this method in other cases also |
Thread Tools | Search this Thread |
Display Modes | |
|
|