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.

 Doom9's Forum Avisynth+
 Register FAQ Calendar Search Today's Posts Mark Forums Read

 21st February 2014, 14:14 #642  |  Link pinterf Registered User   Join Date: Jan 2014 Posts: 1,691 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 mark0077 Registered User   Join Date: Apr 2008 Posts: 1,088 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 hank315 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) Source can be found here. 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, 01:26   #645  |  Link
TurboPascal7
Registered User

Join Date: Jan 2010
Posts: 270
Quote:
 Originally Posted by hank315 Is it correct frame->GetPitch is mod32 in Avisynth+ ?
Most of the times - yes. But you still can get unaligned input after crop(align=false) for example.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

Last edited by TurboPascal7; 22nd February 2014 at 02:23. Reason: clip->crop

22nd February 2014, 10:38   #646  |  Link
Zathor
Registered User

Join Date: Nov 2009
Posts: 2,408
Quote:
 Originally Posted by http://forum.doom9.org/showpost.php?p=1669533&postcount=3987 Code: ClearAutoloadDirs() AddAutoloadDir("C:\Program Files\MeGUI\tools\avs\plugins") LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\NicAudio.dll") RaWavSource("E:\audio.wav") SSRC((AudioRate()*25)/24).AssumeSampleRate(AudioRate()).TimeStretch(pitch=Float((AudioRate()*25)/24)*100.0/Float(AudioRate())) return last "An error occurred: Input audio sample format to SSRC must be float."
Quote:
 Originally Posted by http://forum.doom9.org/showpost.php?p=1669533&postcount=3988 Seems portable version is AviSynth+ (ClearAutoloadDirs(), AddAutoloadDir()), and I think have a new version of SSRC but maybe without the automatic conversion of input data type than AviSynth 2.5.8 have. When source was decoded from AC3, DTS, etc. with NicAudio or BassAudio the audio samples are float, but from losless sources the audio samples are int, and SSRC from AviSynth+ show the Error.
It seems that the SSRC filter in AviSynth+ cannot accept int audio while the AviSynth filter does. Reason seems to be that the automatic conversion mentioned here seems to be not working. Is that a missing feature/intended or a bug?

22nd February 2014, 13:37   #647  |  Link
Zep
Registered User

Join Date: Jul 2002
Posts: 587
Quote:
 Originally Posted by TurboPascal7 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).
Thanks turboPascal your post was exactly the info i was looking for from a high level users eyes. For me I don't need the super low level details but I do want to know enough so i can tweak performance or at least a good guess as where to start/try.

thanks

22nd February 2014, 16:09   #648  |  Link
qyot27
...?

Join Date: Nov 2005
Location: Florida
Posts: 1,228
Quote:
 Originally Posted by Zathor It seems that the SSRC filter in AviSynth+ cannot accept int audio while the AviSynth filter does. Reason seems to be that the automatic conversion mentioned here seems to be not working. Is that a missing feature/intended or a bug?
It's by design:
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.

 22nd February 2014, 20:04 #649  |  Link Zathor Registered User   Join Date: Nov 2009 Posts: 2,408 Thanks, I have added ConvertAudioToFloat() to the script logic.
 23rd February 2014, 13:36 #650  |  Link zerowalker Registered User   Join Date: Jul 2011 Posts: 1,116 Here is a Bug Report, a Script that fails for no reason while it works on AVS 2.6 according to another user. http://forum.doom9.org/showthread.php?p=1670117#post1670117 Hope that helps.
 24th February 2014, 09:42 #651  |  Link innocenat Registered User     Join Date: Dec 2011 Posts: 77 Just stating in this topic also: the above issues happens in r1561 but not r1576. No fix needed. Refer to linked topic for more information. __________________ AviSynth+
24th February 2014, 11:23   #652  |  Link
TurboPascal7
Registered User

Join Date: Jan 2010
Posts: 270
Quote:
 Originally Posted by tormento Some testing done this afternoon with 1080P material. The following hangs in MeGui preview: PHP Code:  LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")SetFilterMTMode("", 2)SetFilterMTMode("DGSource", 3)DGSource("E:\in\something.dgi")#CompTest(1)ChangeFPS(last,last,true)SMDegrain (tr=6,PreFilter=2,thSAD=600,contrasharp=false,refinemotion=true,lsb_out=true,plane=0,chroma=false,Globals=2)SMDegrain (tr=6,            thSAD=600,contrasharp=false,refinemotion=true,lsb_in =true,plane=0,chroma=false,Globals=1,mode=6)Prefetch(3)   Both works ok under AviSynth_MT from Set, which is even a bit faster.
I can confirm it being very slow (on 1080p) and probably unstable but it doesn't hang out completely for me in avspmod. Please try to remove SetFilterMTMode("", 2) line and see if it works (performance aside). This is most likely caused either by some globals magic or wrong mt mode specified for some filters.

Quote:
 Originally Posted by lansing mpeg2source doesn't seem to work with avs+ mt on. I have a 1080p mpeg2 video which I indexed with dgindex, and trying to test with mt on, it gave me a green screen onload with avspmod, and when I try seek, the program just hangs. All three mt mode will hang. Code: SetFilterMTMode("MPEG2Source", 2) MPEG2Source("sample.d2v", cpu=0) Prefetch(4)
Can't reproduce. Mode 1 is indeed broken but that's to be expected. Modes 2 and 3 work without issues here. Does it happen with some specific source or any sources in general?

Quote:
 Originally Posted by hank315 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. Used script: Code: s = AVISource("part2.avi") s = ConvertToYV12(s) return(s) Source can be found here.
Reproduced, reposted on github. Avisource indeed can't handle mod32 pitch in this case. I will look into later this week.

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.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

24th February 2014, 18:57   #653  |  Link
ultim
AVS+ Dev

Join Date: Aug 2013
Posts: 359
Quote:
 Originally Posted by TurboPascal7 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.
I kindly disagree and will keep it this way even in the future. Hopefuly I will also find why Prefetch(1) is the same as Prefetch(0) and fix it.

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 ultim 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
TurboPascal7
Registered User

Join Date: Jan 2010
Posts: 270
Quote:
 Originally Posted by ultim I kindly disagree and will keep it this way even in the future.
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)
Prefetch(4)
My answer is 4. It's perfectly reasonable that you like your implementation (you wouldn't write it this way in the first place otherwise), but I believe it's non-obvious for anyone without programming experience.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

25th February 2014, 00:35   #657  |  Link
TurboPascal7
Registered User

Join Date: Jan 2010
Posts: 270
Quote:
 Originally Posted by MasterNobody 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.
There's nothing wrong with having five or even more threads if all but four of them are idling most of the time, that's a minor implementation detail. But I thought the plan was to have main thread doing the same kind of stuff prefetch threads are doing (e.g. main thread requests frame 0, prefetch threads request frames 1, 2, 3 and 4).
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

25th February 2014, 01:03   #658  |  Link
lansing
Registered User

Join Date: Sep 2006
Posts: 1,350
Quote:
 Originally Posted by TurboPascal7 Can't reproduce. Mode 1 is indeed broken but that's to be expected. Modes 2 and 3 work without issues here. Does it happen with some specific source or any sources in general?
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, 01:45   #659  |  Link
TurboPascal7
Registered User

Join Date: Jan 2010
Posts: 270
Quote:
 Originally Posted by lansing 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.
Reproduced, thanks for the report.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

 25th February 2014, 08:29 #660  |  Link lansing Registered User   Join Date: Sep 2006 Posts: 1,350 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()