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. |
21st February 2014, 05:18 | #641 | Link |
Registered User
Join Date: Jan 2010
Posts: 270
|
Note to all people having any kind of issues with mt build: first of all, try removing SetFilterMTMode("", MT_MULTI_INSTANCE) from your script. I have absolutely no idea why this was introduced in the first place since it only creates problems. Yes, this will cripple performance but no one promised you it'll be easy.
Second - setting any MT mode on script functions does nothing. For example, SetFilterMTMode("Dither_Crop16", MT_MULTI_INSTANCE) doesn't change anything. You can put any other MT mode there and it will still work they way it works by default. Only plugin functions matter. Third - situation where one plugin works with mode 1 when used before filter X and only with mode 2 when X is not present is pretty much impossible (assuming there are no bugs in the core of course ). MT mode is a property of a filter and it doesn't depend on where it's used, only on filter implementation and input parameters (unless the filter is completely broken). I understand this is not helping much and thank you for posting scripts with this kind of problems, but most likely it means that MT mode of one of the filters was not "guessed" right. Hopefully we can get authors of some plugins who are still alive (dither for instance) to supply correct MT modes for every function in their plugins, either as a registration routine in the plugin itself, or SetFilterMtMode line. If we can't, well... we'll be guessing. EDIT: as innocenat pointed out on IRC, it's actually possible to have filters changing their behavior if they're called before a filter with MT mode 3. All filters are getting serialized and any MT mode you're applying to them should not matter. This is an implementation detail though and you should not rely on it in any way since it might get changed without notice. Now, to Prefetch(1)/Prefetch(0) issue. As ultim explained (no one bothered to read the full MT implementation tbh because it feels a bit (over)complicated), the number that you supply to prefetch is the number of prefetching threads. So in theory Prefetch(1) should give you two threads - one main thread and one prefetching thread. Prefetch(0) should disable any multithreading. As usual, practice doesn't match theory very well and Prefetch(1) actually gives you one working thread (dunno if it's the main or the created one). Yes, this is a bug and it most likely will be fixed. But if you think about it, this API design is very bad. Most users don't know and don't need to know the difference between prefetching threads and the main thread. Adding Prefetch(4) to their script, they absolutely reasonably expect it to work in 4 threads, trying to explain to them that it's actually 5 would be silly. So this bug kinda makes the API better. In short - yes, currently Prefetch(1) and Prefetch(0) are almost equivalent. In the future one of these might error out, or this behavior will be kept (probably more reasonable). Last edited by TurboPascal7; 21st February 2014 at 07:43. |
21st February 2014, 14:14 | #642 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
TurboPascal7, thank you the script function vs mt mode note, although I knew it, did not check which Dither function was implemented in script.
Luckily I have cought an error message displayed for a few tenth of seconds (then made a screenshot video) "Dither_resize16: resizing ratio too low or kernel support too high." In MT_SERIALIZED mode it does not occur. (v1.24) |
21st February 2014, 21:05 | #643 | Link |
Registered User
Join Date: Apr 2008
Posts: 1,106
|
Guys maybe this is a stupid question, but has someone (or is it even possible) to use this with SVP? I have been trying with no luck to replace my SetMTMode calls with SetFilterMTMode calls towards SVP functions. Maybe its not even possible unless SVP add support in their dlls?
|
22nd February 2014, 01:22 | #644 | Link |
HCenc author
Join Date: Nov 2003
Location: Netherlands
Posts: 570
|
Just installed Avisynth+ to run some tests as frame server for HCenc.
Most tests finished OK but the most basic test failed: Avisource input only. Frames seem to have a wrong pitch. Source is RGB in an AVI container. Probably I'm doing something stupid because if this is a bug it should have been reported earlier I guess. Used script: Code:
s = AVISource("part2.avi") s = ConvertToYV12(s) return(s) BTW, Avisynth 2.6.a5 and 2.5.8 handled the source OK. Is it correct frame->GetPitch is mod32 in Avisynth+ ?
__________________
HCenc at: http://hank315.nl |
22nd February 2014, 10:38 | #646 | Link | ||
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Quote:
Quote:
|
||
22nd February 2014, 13:37 | #647 | Link | |
Registered User
Join Date: Jul 2002
Posts: 587
|
Quote:
thanks |
|
22nd February 2014, 16:09 | #648 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
https://github.com/AviSynth/AviSynthPlus/commit/d40f4a2e833998199dec0e0e4737cf69c4607b6c There was also a forum post that mentioned it or explained the rationale (that it shouldn't do that kind of conversion without the user's knowledge), but I can't find it right now. |
|
24th February 2014, 11:23 | #652 | Link | |||
Registered User
Join Date: Jan 2010
Posts: 270
|
Quote:
Quote:
Quote:
pinterf Firesledge added functions from dither here and they all seem to be NICE_FILTERs, so I guess the issue is somewhere in mvtools2. I'll probably play with it some time soon but wouldn't mind anyone testing it before me. |
|||
24th February 2014, 18:57 | #653 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
Why I think it is better this way? First, the name of "Prefetch" is well chosen, because it describes exactly what the filter does: it prefetches frames. When inserted into a script, the user is basically telling the core a command to "Prefetch me frames in addition to the one you are working on now!". So the name is fine. So when you see the function declared as "Prefetch(nThreads)", what is the most intuitive way to interpret it? Isn't the first thing you think of "prefetch using nThreads threads"? I think it is, and this is exactly what AviSynth+ is doing now. Going TurboPascal's way would mean "Prefetch frames for me using one less threads than what I told you"! That is way more counterintuitive than the current implementation. I do agree with TurboPascal that users shouldn't need to concern themselves with implementation details. They shouldn't, which is why I find it odd at all that he explained this. A higher number gives more threads: that is IMHO no less and no more than what a user must know in this case to find the optimal parameter for his number of cores, for best performance on his computer. As for bugs, please remember, there is a reason this was published as a test build.
__________________
AviSynth+ Last edited by ultim; 24th February 2014 at 18:59. |
|
24th February 2014, 20:04 | #654 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Well, bad news folks, we didn't get accepted for GSoC this year. Of course our "staff" will remain available for anybody wishing to pick up one of the projects, for help. There is always a next year, and we continue to hack around AviSynth ourselves too.
The preparation for GSoC was not all in vain though. We discussed a lot of things about the future of AviSynth's ecosystem. Thanks to GSoC, we managed to define what we want to do, defined our priorities and wishes clearly. As "by-products", we even got ourself a nice set of coding guidelines for future contributions, and improved our infrastructure just a bit further. Also, now that GSoC isn't playing for us in 2014, I can extend our ideas list with all those that we did discuss and want to have, but for various reasons deemed unfit for Google.
__________________
AviSynth+ Last edited by ultim; 24th February 2014 at 20:21. |
24th February 2014, 20:45 | #655 | Link |
Registered User
Join Date: Jan 2010
Posts: 270
|
We can go full democracy and ask users to vote. Question is: "how many threads do you expect the following script to have? Assuming no filters are multithreaded internally."
Code:
DgSource("commie.dgi") tfm().tdecimate() debilinear(1280, 720) gradfun3() Prefetch(4) |
24th February 2014, 21:13 | #656 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
I don't see anything bad with having 5 threads when using Prefetch(4) if all hard work is done by this prefetch threads and one more (main) light thread is only needed to orchestrate other threads. That is mostly semantic of what x264 have for --threads and the only exception is --threads 1 when main thread and working threads become the one and the same thread.
|
25th February 2014, 00:35 | #657 | Link | |
Registered User
Join Date: Jan 2010
Posts: 270
|
Quote:
|
|
25th February 2014, 01:03 | #658 | Link |
Registered User
Join Date: Sep 2006
Posts: 1,657
|
mode 2 and 3 were fine with 480p source, but not for 1080 mpeg2 videos, I tried on a few clips already. This time only prefetch(0) work, all other prefetch would gave a green screen, and then after a few jumps in timeline, the program would hang.
|
25th February 2014, 08:29 | #660 | Link |
Registered User
Join Date: Sep 2006
Posts: 1,657
|
Another problem, I tired running mctd script on a 1080 avc stream. I loaded the script into virtualdub and ran analysis pass, and it returned an error "could not allocate video frame. Out of memory".
Code:
dgsource("test.mkv", engine=1) mctd() |
|
|