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. |
26th January 2011, 08:42 | #141 | Link | |
Registered User
Join Date: Feb 2003
Location: Russia, Moscow
Posts: 854
|
Quote:
Can You confirm error for nnedi3_rpow2 for YUY2 colorspace under Set 2.6 build? yup. |
|
26th January 2011, 13:19 | #142 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Maybe when I learn how to make sure code is Win64 compliant and when a friend of mine gets through porting Avisynth's asm into x264ASM usable via yasm .
Also, added a VS2008 build onto the original post .
__________________
[I'm human, no debug]
|
27th January 2011, 01:34 | #144 | Link | |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Quote:
|
|
27th January 2011, 07:02 | #145 | Link |
Registered User
Join Date: Jan 2011
Posts: 107
|
Well, I can now happily report that I have completely resolved my bizarre KERNELBASE and unknown exception crashes with Avisynth 2.6. It occurred to me to go back and check to make sure that there weren't any memory access issues since this is 32-bit softwares. I found Avisynth crashing with these errors after running up to 1.6GB of RAM used. At first I didn't get it because previously I had tested my script with SetMemoryMax and had gotten the same errors. But I thought I'd test again with a very low limit at 1.2GB and when I did it worked flawlessly, zero crashes. I tested different values and got it up as far as 1500MB without crashing. I took a look at the script with which I had previously tested SetMemoryMax (I kept a record of all the scripts I had been testing) and found that the lowest I had gone in setting the memory limit was 1600MB, which turned out to be lowest level at which the crashes occur If I just tried the script with 100MB less memory it would have worked.
And now I can report some preliminary test results. The script I've been posting, without invoking SetMTMode processes with 2.6 at about 2.5fps. This is comparable to what I was getting with JoshyD's. When I invoke SetMTMode(5,4) at the top and SetMTMode(2) just before QTGMC I get over 5fps This is about twice as fast as JoshyD's running the same script with SetMTMode! Although that's a little unfair as I had tested JoshyD's with QTGMC 2.51 the v3.0 wasn't speed related so I don't think there would be much difference. Thanks to everybody who tried to help with this. It made sense to me when I first started testing with SetMemoryMax to leave some slack between the limit and 2GB but I had no idea it needed to be that large. |
10th February 2011, 10:37 | #146 | Link |
Registered User
Join Date: Feb 2003
Location: Russia, Moscow
Posts: 854
|
YToUV() do not work for YUY2
Hi all!
I find that YToUV() with YUY2 do not work for Set 2.6 build. VirtualDub try show half horizontal size frame and crash. This reason why do not work nnedi3_rpow2(). yup. |
21st February 2011, 17:11 | #147 | Link |
Big Bit Savings Now !
Join Date: Feb 2007
Location: close to the wall
Posts: 1,545
|
Just playing around:
SEt's avisynth.dll 32 MT Build 2.6.0 2009 09 19 in sysWOW64 on a Win7U64. CPU i7920XM, 8GB RAM, SetMemoryMax=1536 Uncompressed PAL SD YUV source AviSource() RemoveDirtMC() BlindDeHalo3(...) MedSharp2(strength=6) GrainFactory3(....) Feeding VirtualDub 1.9.10 to render as uncompressed YUV. Renders 50 frames in VirtualDub 1.9.10, then raises unknown exception. No matter if script uses SetMTMode or not. Lowering SetMemoryMax to 768 did not help. The same script on same engine, same system with straight avisynth.dll 2.5.8.5 non-MT in sysWOW64 : Both MemoryMax values run properly. VirtualDub uses ~600MB. Different system (WinXP32 SP3, CPU T7600G, 4GB RAM), same script with straight avisynth.dll 2.5.8.5 non-MT in system32: Both MemoryMax values run properly. VirtualDub uses ~600MB. Edit: Now finally I could catch the error message on Win7U64. On WinXP it disappeared too quickly to even be read... This time the script was Code:
#---------------------------------------------------------------Sourcefilter-Calls--------------------------------------------------------------------------- AviSource("K:\E.32.00.avi") #/*#-------------------------------------------------------------AnimeIVTC--------------------------------------------------------------------------------- ComplementParity()#Parity is vital for AnimeIVTC when performing fieldblend PAL to fullframe IVTC ! #ReverseFieldDominance(shiftup=false)#(PAL Only ! YUY2 oder RGB only) ...Like CCE's shift lines by 1 #RevFieldDom: PAL DV is expected to be sampled bottom field first. #In case of a device sampling top field first this filter can reverse field dominance #by simply shifting each line up (or down) by one line and duplicating the bottom (respectively top) line. ConvertToYV12(interlaced=true)#AnimeIVTC needs YV12 ! AnimeIVTC(mode=2, aa=4, precision=3, killcomb=0, cache=15, normconv=true\ , bbob=4, omode=1, dark=0.2, thin=10, sharp=150, smooth=-1, stabilize=false, aablk=8, aaov=4, aatype="EEDI2") #(clip i, int "mode", int "aa", int "precision", int "killcomb", int "cache", bool "ifade"\ # , bool "chrfix"\ # , bool "blend"\ # , bool "normconv"\ # , int "pattern"\ # , int "pass", bool "rendering" \ # , int "bbob", int "cbob", string "edimode", int "degrain", int "omode"\ # , int "i1", int "i2", int "e1", int "e2", int "e3", int "p1", int "p2" \ # , int "overlap", int "pel", int "search", bool "nnedi2pel", string "credconv"\ # , float "dark", int "thin", int "sharp", int "smooth", bool "stabilize", int "tradius"\ # , int "aapel", int "aaov", int "aablk", string "aatype") #*/#--------------------------------------------------------End of AnimeIVTC------------------------------------------------------------------------------- #/*#--------------------------------------------------------Spatial Frame Pre-Alignment------------------------------------------------------------------- # Before Roll-Decimating a film scan, you may have to align the borders first ! Often film scans are skewed ! # VCMohan's plugins needed here: Grid, Perspective, Spinner, Reform=deskew+skew. Avoid Reform, poor resizer ! #grid(sf=0, ef=framecount, lineint=10, bold=5, vbold=2, grid=true, axis=true)#Comment grid in to see where the transformations end up ConvertToRGB#Perspective needs RGB ! Addborders(2, 2, 2, 2)#Perspective has to discard 2 border pixels for calculations and makes these black, we pad up borders before with 2 pixels black perspective(a=-0.00001, b=0.0, x=+1400, y=0)#Perspective needs RGB ! Crop(2, 2, -2, -2)#Perspective introduced a 2 pixel black border, we padded these up, now we crop them off #grid(sf=0, ef=framecount, lineint=10, bold=5, vbold=2, grid=true, axis=true)#Comment grid in to see where the transformations end up #ConvertToYV12(interlaced=true)#(RGB was needed for Perspective only) #spinner(check=false, angle=+0.7, q=4)# sometimes exceptions thrown... # Deskew transforms a Quadrilateral part of the frame (source at least 1 pixel per side smaller than frame) # into a Rectangle within the frame (at least 1 pixel per side smaller than frame) Result shows stairstepping ! Poor resizer (point??) #deskew(last, blankclip, ltopx=2, ltopy=2, lbotx=12, lboty=height-2, rtopx=width-2, rtopy=2, rbotx=width-2, rboty=height-2, resize="cubic") #/*#------------------------------------------------------End of Spatial Frame Pre-Alignment------------------------------------------------------------- #--------------------------------------------------Intermediate Conversions, Resizing, Assumptions------------------------------------------------------ AssumeFPS(25)#If the result of any Pulldown-Removal into 24p is to be fed into an Edius PAL-Project. Otherwise Edius will reblend 24p->25p !!! #------------------------------------------------End of Intermediate Conversions, Resizing, Assumptions------------------------------------------------
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain) "Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..." Last edited by Emulgator; 9th March 2011 at 08:47. |
18th April 2011, 08:22 | #148 | Link |
partially-informed layman
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
|
I haven't tried this myself but I understand that AviSynth 2.6 MT will not accept RGB24 input. Is this so and has it been permanently dropped? If I move to 2.6 MT I would miss RGB24 support as RGB32 is slower than RGB24 in my workflow (Sony Vegas > Debugmode Frameserver > AviSynth).
|
18th April 2011, 13:02 | #149 | Link | |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Quote:
but that's a complete lie: It's still supported. |
|
19th April 2011, 00:38 | #150 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
AviSource() had RGB24 borked some time ago. There was a 2.58 alpha with this bug. May be SEt's build has that bug, I don't track 3rd party build, so you will have to do some archaeology to confirm or refute the issue.
Working file: avi_source.cpp ---------------------------- revision 1.14 date: 2008/07/15 06:23:21; author: ianb1957; state: Exp; lines: +10 -3 Fix RGB24 processing, add guard bytes to decompression input buffer ---------------------------- |
20th April 2011, 17:57 | #151 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Quote:
For 7+ years I have been frameserving out of Sony Vegas Pro into AVISynth scripts. I use the frameserver available from Debugmode. When you start the frameserver from Vegas, you get this dialog: For seven years, I have chosen either RGB24 or YUY2, depending on my workflow, plugins used in the AVISynth script, etc. I never had a problem. For the past several years I have been using AVISynth 2.5.8.5 multi-threaded. The DLL is dated 8/16/2009 and has the name "Jeremy Duncan August 16, 2009" in the Special Build section. This has worked very well, and works with the RGB24 option shown above. However, in order to get better stability with the QTGMC script in multithreaded usage, I updated to AVISynth 2.6 multithreaded. The DLL is dated 8/16/2009 and is MUCH larger (1,676 KB vs. 339 KB). There is no identifier in the DLL. When I attempt to open an RGB24 output from the frameserver, using an AVISynth script that is just one line: AVISource("e:\frameserver.avi") I get this error message: RGB32 and YUY2 continue to work as they always have, but RGB32 is MUCH slower (2-3X slower) than RGB24 (or YUY2) because of the conversions done out of Vegas and perhaps because of the larger data set created. It does work just fine. Because of subtle color shift errors when serving out using YUY2 into a script that uses QTGMC that don't happen when serving out RGB24, I would prefer to use RGB24. But, if I go back to the earlier version of AVISynth, I get stability issues in multi-threaded mode (although only with QTGMC). Typical engineering tradeoff. So, in support of what nhope says above, I too have found that AVISynth 2.6 -- at least this particular build -- does not handle something that has worked for over seven years (for me). Perhaps there is a different 2.6 MT build somewhere that doesn't have this problem? Last edited by johnmeyer; 20th April 2011 at 17:57. Reason: Added "2.6" in the last line, for clarity. |
|
3rd May 2011, 08:15 | #153 | Link |
Registered User
Join Date: Jun 2010
Posts: 443
|
Hey guys,
I just added version information to this build because of some programs (like SVP) that read the AviSynth version. Feel free to grab it from here. It is exactly the same as the 2009.09.19 build from the first post, but with the added version information. |
4th June 2011, 15:54 | #154 | Link |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
AVS 2.6.0 Alpha 3 __MT__ anyone?
|
4th June 2011, 19:42 | #155 | Link | |
Registered User
Join Date: Apr 2006
Posts: 299
|
Quote:
|
|
5th June 2011, 16:34 | #156 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
MT was removed from the trunk, and, unless one of you wants to start developing a more working "multithreading" Avisynth, I think you should stop calling it out as if it was something easy to do.
Also, if you think the current multithreading model in Avisynth is good, I'd like to slap both of you a few times to drop you back into reality.
__________________
[I'm human, no debug]
|
5th June 2011, 19:46 | #157 | Link |
typo lover
Join Date: May 2009
Posts: 595
|
plus one
__________________
my repositories |
6th June 2011, 01:37 | #158 | Link |
Registered User
Join Date: May 2007
Posts: 220
|
I wonder if ThreadRequest could be utilized in lieu of native multithreading capability? I know I saw a script somewhere that used it to emulate the SetMTMode functionality (though it is not limited to such use). Might be worth considering.
|
6th June 2011, 13:34 | #160 | Link | |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Quote:
B) the MT model that was developed is flawed, that's the reason IanB pulled it out of the code in the first place. C) MT models are generally not that easy to develop and it will take a lot of thought and discussion to get one that is simultaneously useful and stable, which may or may not end with requiring a break in backwards compatibility. |
|
|
|