Thread: Avisynth+
View Single Post
Old 16th December 2019, 10:02   #5005  |  Link
dREV
Registered User
 
dREV's Avatar
 
Join Date: Jan 2019
Location: Antarctica
Posts: 74
Quote:
Originally Posted by LigH View Post
To access most of your RAM, do you execute it with a 64-bit application? Apart from that, an access violation can have different reasons, maybe also a code error in one of the used plugins, so it's probably worth a closer investigation. Try running it in AVSMeter64, this tool should produce quite verbose error messages. Also don't underestimate that an encoder itself needs RAM too (in this regard, 8 GB can already be "rather low" when processing FullHD content, too little for x265 already).
You mean AviSynth+ 64 bit? No, I'm using the 32 bit version but I use the 64 bit HEVC and H264 encoders using the 10 bit hack pipeline. I lost detail when using jpsdr's ResampleMT/Desample with real.finder's updated DebilinearMscript 2-3 months ago. No clue if it's like the 32 bit now have not done any testings. My RAM is around 70% to 95% depending if I'm idle or watching YouTube (and having opened too many tabs) waiting on my encode to finish and other things. My issue is that if I don't take the precautions when using maa2 I have to wait for the indexing of lsmash to finish and that could take an hour or two and then go into each script and edit out/in "Prefetch(0)" to "Prefetch(1)" which adds to my annoyance and wastes my time especially when I wanna go to sleep.

I've only gotten this Access Violation majority of times when using real.finder's maa2 script in combination with Prefetch(1). It never fails. With older versions of maa2 this issue is non-existent. Maybe cuz real.finder's updated maa2 script uses HBD or something? I've used AVSMeter 32 bit version and it gives no errors just does it as if no issues.

Encoder needs RAM? That's news to me I never heard this before. I'm content with just 720p sources at the moment.

Quote:
Originally Posted by StainlessS View Post
What LigH said,
+, have a look at your Windows logs for both Application and System errors.
My Computer/Properties/Manage/Event Viewer/Windows Logs/
Application, & System

Best update to avs+ v3.4.0:- https://github.com/AviSynth/AviSynthPlus/releases
I'm not sure what that first one is about. My thing says it's not working maybe cuz I turned it off or something when I was turning/blocking telemetry on my PC. What does that have to do with the issue tho? Also, thanks I had no idea there was an update to Avisynth+. I thought pinterf was still doing but nothing kept turning up on his GitHub page and I haven't kept up to reading the AviSynth+ thread. Not sure why but got a lil bit more better details with this and seems the new AviSynth+ updater has included stuff for AMD users like me. I can't tell if I'm getting better speeds since I'm encoding using maa2 at the moment and that usually fluctuates. Ranging from 64 fps to 82 fps at the moment.

Quote:
Originally Posted by FranceBB View Post
Definitely update Avisynth+ like StainlessS said.
As to the lack of RAM, if you're using x86, you might wanna take a look at this: https://forum.doom9.org/showthread.php?t=163281
I successfully made Avisynth x86 use more than 7 GB of RAM on my 32 GB system by splitting each filter into a separate process so that each process can allocate 2 GB of RAM and Avisynth as a whole can allocate as much RAM as possible.
As to the modifications in red, I'll take a look at it later as I'm really in a hurry right now.
Nah, I'm on a 64 bit OS but using 32 bit AviSynth+ as mentioned above and my reasoning.

I've did a few tweaks using your critique if I understood it correctly. However, I cannot use your f3kdb settings cuz I get errors. MeGUI complains that the resolution is not the same plus there was some things that wasn't working out right like when I would use Gradfun3 with mask using lsb as I need it to be the first thing done before applying any other filter to lessen any detail loss. Anyways here's what I been using

Code:
dither_convert_8_to_16()

#Debanding - Gradfun3 16bit lsb with mask=0
#misc filter(s) 16 bit lsb - only if needed like smdegrain
s16 = last
DitherPost(mode=-1)

#line darkening (sometimes)
maa2()

dither_convert_8_to_16())
s16.Dither_limit_dif16 ()
ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

DitherPost(mode=-1)

ConvertBits(bits=16) #I want this here to get more bitrate but at first I did some tests using what you wrote
ConvertToStacked()

# grain
ConvertFromStacked().ConvertToDoubleWidth()
What you think? I got a lil bit more detail like this and not sure on the fps since taking out TurnRight and Left since I didn't know maa2 had it in the script. Could you let me know what this is that you wrote?
Quote:
#Now we're gonna truncate everything to 8bit,
#apply anti-aliasing with maa2 and then use the original 16bit stacked we received from f3kdb
#and apply only the changes made by maa2 thus retaining 16bit precision

#antialiasing 8bit, 16bit stacked output
What do you mean by using the original 16 bit stacked received from f3kdb and apply only the changes made by maa2 retaining 16 bit precision? I understand the 16 bit precision but not the rest you wrote. And the "antialiasing 8 bit, 16 bit stacked output" part? Like adding dither 8 to 16 after maa2? I'm not understanding this if it's not that as I don't think maa2 has 16 bit.

Last edited by dREV; 16th December 2019 at 10:12. Reason: stuff
dREV is offline