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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd June 2011, 04:02   #1  |  Link
Bexley
Registered User
 
Join Date: Mar 2005
Posts: 64
AviSynth MT keeps crashing

I do a lot of heavy AVISynth filtering (with MC denoisers largely) and my life is too short to spend it at 2-3fps, so I've just built myself a shiny new Intel 990x Extreme system with 12GB of Corsair Dominator GT, Radeon HD 6900.... the whole nine yards. The absolute best of everything. Only problem is, it is TOTALLY useless with AVISynth on this shiny new system because it keeps crashing every single time I use anything multithreaded.

So to start.... I have burned the system in thoroughly with lots of different tools, and everything appears to be rock solid. I have no reason to suspect hardware issues. AVISynth is the ONLY program that is misbehaving, and it only misbehaves when I use MT. (It sometimes crashed during MT on my old Q6600, but not EVERY time like it does now.)

I started with a clean install of Win7 Ultimate 64, followed by AVISynth 2.5.8. Then I installed the modified 2.5.8 MT dll into SysWOW64 and the MT plugin. Then I dropped in plugins as needed... dgdecode.dll, decomb.dll, nicac3audio.dll, and just a couple of others. So far so good:

SetMTMode(5,12)
video=MPEG2Source("movie.d2v")
audio=NicAC3Source("audio.ac3")
AudioDub(video,audio)
AssumeTFF().Telecide().Decimate()

Then I drop in my first moderately big function - RemoveDirtMC. I absolutely cannot load any version of removegrain.dll or removegraint.dll past version .9. 1.0 beta, 1.0 prerelease, the 1/24/08 unofficial binaries... nothing. Virtualdub just throws an error about "cannot load removegrint.dll" And I have both msvcr70.dll and msvcr71.dll installed, so I don't think that's it. So I stick to .9 SSE3 and it seems to work OK.

RemoveDirtMC(20)

Then I drop in my main workhorse - MCTemporalDenoise. Error right off the bat because removegrain .9 doesn't support Mode 20. So I drop in removegrain 1.0 beta but leave RepairSSE3.dll from the .9 package, and amazingly... it works with MCRemoveDirt!

RemoveDirtMC(20)
#MCTemporalDenoise(settings="medium")

When I try MCTemporalDenoise again, it just crashes as soon as VDub opens with "Microsoft Visual C++ Runtime Error! This application has requested the runtime to terminate in an unusual way." I have tried SetMTMode with every mode from 2-5 and every number of threads from 4-12, same result. I can comment out the SetMTMode line, and it works perfectly.

I've been wrestling with this for over a week now, and it's time to ask for help. I'm fairly well pissed off because the main reason I spent upwards of $2500 on this system was to run these functions at a reasonable speed, and what I have is an expensive pile of hardware that makes a LOT of noise and does nothing I need it to.

Does anybody know why AVISynthMT refuses to work on this box? TIA!
Bexley is offline   Reply With Quote
Old 2nd June 2011, 06:07   #2  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Settting SetMTMode before the source filter can cause big problems, so the first thing you should do is move it after the sources! Also, SetMTmode (5,12) is a bad idea, the mode 5 of SetMTMode is so slow that even if it is multithreaded it will probably run slower than its single thread counterpart! Ideally you use SetMTMode 1 for the filters where it works, then progressively try 2 and 3 for the others. Anything below 3 is really not worth it. The other thing is setting it to 12 threads may be an issue, remember this is a complete hack method! Running it at 6 threads would be safer, and remember hyperthreading so 2 threads run on 1 core doesn't mean twice the speed, its really not worth it in this case!

Instead of using Mpegsource2, which is actually a really old decoder, try using FFmpegsource2. Its under current development.
See the thread here: http://forum.doom9.org/showthread.php?t=127037&page=59
Current version (direct link): http://warpsharp.voodoo-powered.net/...ms2-mt-r469.7z

It is already multithreaded, DO NOT specify SetMTMode before using it! Then try SetmtMode (3,6) (as I said before, setting the threads to 12 won't be faster and just leaves you open to potentially more crashes) directly after the source filter, then see if it works. Then, if it does, try setmtmode (2,6), which will also hopefully work with all the filters. If that doesn't work, put setmtmode (2,6) before the first filter, then setmtmode (3,6) after it. You can set setmtmode as many times as you like, so you can have:
Setmtmode (3,6)
filter 1
Setmtmode (1,6)
filter 2
Setmtmode (2,6)
filter 3
Setmtmode (1,6
filter 4
filter 6
etc...


Basically find the combination of lowest Setmtmodes that each filter supports. Probably the best way to do it is set the ffmpegsource2 filter up, then just add ONE of the avisynth filters in the script, with Setmtmode before it. Then, starting from (1,6) find the most stable mode with the lowest number first. When you work that out, make note, remove that filter from the list, then do that for the second one, and progress through until all are done. Then collate that information in the final script like I have 'exampled' above (in the order that you want the filters to take place). When you try it out, also try moving the slider back and forth in preview, as sometimes the filters may not be completely stable.
burfadel is offline   Reply With Quote
Old 2nd June 2011, 09:59   #3  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Avisynth-MT is like REALLY DUMB and extremely crash-prone. I suggest not using it if you want to actually do stuff rather than staring at stack traces. I also wonder what you're going to do with 12GB of RAM since 64-bit Avisynth isn't exactly useful in its current form either. One thread and 3 GB of RAM was enough for everyone who came before you, so it should be enough for you too.

Also, lol ATI.
TheFluff is offline   Reply With Quote
Old 2nd June 2011, 13:26   #4  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
Avisynth is sadly rather buggy with multi-threading and limited to 2GB memory use. There are an unfortunate few whose systems just won't play nice and can never get multi-threading working effectively. However, for many, multi-threading can be made stable and it is worth it for any moderately complex script. I have made a collection of tweaked plugins that give me perfect stability for my QTGMC related processing, they might help you too. This collection includes some of the key plugins you need, including the correct versions of RemoveGrain and its friends; picking the working versions of those plugins is a bit tricky [make sure you delete all old versions from you autoload plugins folder]

Going to x64 is the only solution to the memory issue, but many plugins don't exist in 64-bit land and there are further stability issues. However 2Gb is enough unless you're doing very complex processing on SD or moderately complex processing on HD.

This is the multi-threading information I provide for QTGMC, simplified to the general case:
____

For best script performance try going multi-threaded. You will need an "MT" version of avisynth and there are several versions. I recommend one of SEt's versions but if you get stability problems (crashes) then try the others. These are the options: Standard 2.57MT, SEt's 2.58MT or SEt's 2.6MT. Or you can convert to a completely 64-bit workflow (must also get 64-bit versions of all plugins): x64-2.58MT.

You need to tweak multi-threaded scripts to suit your system. Here is a basic template - read and follow the comments carefully and provide the values noted (you cannot use this code just as it is):
Code:
SetMemoryMax(M)  # Optional line. Leave it out at first. See below for value M
SetMTMode(5, X)  # See below for value X
YourSource("yourfile")  # DGDecode_mpeg2source, FFVideoSource, AviSource, whatever your source requires
SetMTMode(2)

# Your filters / processing goes here

Distributor() # This line may or may not be necessary, try removing it and see if that fixes crashes / gives more speed
Setting X
- Start at the number of logical cores in your machine (note: with HyperThreading enabled, logical cores = 2x physical cores)
- If it crashes, decrease 1 at a time
- Otherwise increase 1 at a time until CPU usage just reaches 100%, don't go too far or it will actually slow things down.

Setting M
- First try without the SetMemoryMax line
- However, selecting a good SetMemoryMax value might better utilise memory and increase stability. Particularly important for very complex scripts or HD
- Try values 400,600,800,1000 etc. Sometimes reducing this value can allow you to increase X for a speedup

Last edited by -Vit-; 2nd June 2011 at 13:45.
-Vit- is offline   Reply With Quote
Old 2nd June 2011, 13:48   #5  |  Link
Bexley
Registered User
 
Join Date: Mar 2005
Posts: 64
burfadel - Thanks for those tips! I will try those tonight and see if they work. I was under the impression (from way back) that SetMTMode had to be called very first thing in the script. I will move it and see what happens. I know that mode 5 is impossibly slow, but I was using it just for troubleshooting purposes since it is supposed to be the most compatibile. Mode 2 is my normal mode.

TheFluff - I have 12GB because I went with a 3x4 RAM kit to take advantage of triple channel DDR3. Premiere and After Effects will chew up 8GB in a heartbeat, so 12 was the best option. And considering what I was already spending and where the price of RAM is now, why would I not?

-Vit- - I downloaded your plugins and it looks like it may actually work! I will play with them tonight and see what happens. Thanks!
Bexley is offline   Reply With Quote
Old 2nd June 2011, 14:03   #6  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
Quote:
Originally Posted by Bexley View Post
I was under the impression (from way back) that SetMTMode had to be called very first thing in the script. I will move it and see what happens.
Your were under the right impression. But only one half of it.


Code:
SetMTmode(5,[threads])

VideoSource(...)

SetMTmode(2)

...rest-of-script...
That's the generally-working concept.
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 2nd June 2011, 14:43   #7  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Hmmm, I haven't used setmtmode for a long while but when I did use to use it I could put setmtmode after the source filter... For example, in a fairly simple script I was able to utilise setmtmode (2,4) directly after the source script, then further down put setmtmode (1,4) for the filters that worked with it, and that worked perfectly. If I moved setmtmode (2,4) to above the source filter, it didn't work...

These days I just use Avisynth v2.6 (latest builds) and fore'go using MT entirely. Instead, I just encode 2 things concurrently and that leads to 100 percent utilisation across the 4 available threads on my q9400.
burfadel is offline   Reply With Quote
Old 2nd June 2011, 14:53   #8  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
Quote:
Originally Posted by burfadel View Post
Hmmm, I haven't used setmtmode for a long while but when I did use to use it I could put setmtmode after the source filter.
Number of threads is defined only before any video frames are created. When the first / the only SetMTmode appears after the source call, then the whole script runs singlethreaded.

Multiple conversions in parallel are a valid workaround, but not a solution. Plenty of scenarios where the "multiple sources" premise isn't given to start with.
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 2nd June 2011, 16:42   #9  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
I might have had SetMTmode(4,4) before the source filter come to think of it...! as I said, I hadn't used it in a long time. Its much better for the filters to be natively multithreaded (most aren't), the benefit of setmtmode really only comes about if you use anything below 4? but even so, Bexley still won't get 100 percent usage.
burfadel is offline   Reply With Quote
Old 2nd June 2011, 16:58   #10  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
Quote:
Originally Posted by burfadel View Post
Its much better for the filters to be natively multithreaded (most aren't)
There's not much multi-threaded filters to experiment with. However, with NNEDI3 as an example,

NNEDI3(threads=whatever)

is always slower than

SetMTmode(2,threads=whatever)
NNEDI3(threads=1)


Quote:
but even so, Bexley still won't get 100 percent usage.
Can't actually speak for MCTemporalDenoise ... but with QTGMC as an example for a "very complex script", I definetly can reach 95~100% CPU usage by using SetMTmode.
TDecimate is a bit of a weak point in the chain, since it's kind of "inherently single-threaded", or sth like that. (tritical once explained it, but I don't remember well.)
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 3rd June 2011, 01:07   #11  |  Link
Bexley
Registered User
 
Join Date: Mar 2005
Posts: 64
Quote:
Originally Posted by Didée View Post
Your were under the right impression. But only one half of it.
OK, thanks. That's pretty much what I've always thought.

I can easily get 100% CPU utilization with MCTemporalDenoise. I was getting it using 4 threads on my old Q6600, and I can get it using 12 threads on my 990x. It just won't run more than a few hundred frames before it crashes.

So here's the latest using everyone's suggestions: I installed Vit's plugins and they seem to work much better. I can at least load the function now. I filtered a 90-min movie with (2,4) and got no crashes at 10-12 fps and 25% total CPU utilization. I increased that to (2,6) and it crashed about 75% of the way through at about 17fps. Looks like 4 threads is about it for useful performance.

Not to go too far OT, but honestly, this is a rather sad state of affairs.... all this screaming horsepower and can't use it. Just what exactly is the future of AVISynth? Something is clearly going to have to give, or else it's going to become obsolete in a hurry. AVISynth 3.0 appears to be dead as near as I can tell, and there doesn't seem to be much happening on the 2.6 or 64-bit fronts, either. There are a few moderately useful 64-bit plugins on squid80's page but nothing that provides any of the functions I really need.

And to be honest, there doesn't seem to be a lot of plugin and function development going on like there used to be. The state of affairs today doesn't appear to me to be much different than it was 2 or 3 years ago. Browsing through the forum (which I only visit occasionally) it looks like everybody is still using pretty much the same old stuff - Seesaw, MC_Spuds, MCTemporalDenoise, MVDegrain, LRemoveDust, etc.

What's going to happen with this state of affairs? Where are we going here? What's the road map?

Last edited by Bexley; 3rd June 2011 at 01:12.
Bexley is offline   Reply With Quote
Old 3rd June 2011, 01:45   #12  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
Well, the facts are: Avisynth 64bit is a buggy hack, period. Avisynth 32bit is always facing the process memory limit. When the threadcount is increased, the memory requirements are increasing too. In particular when MVTools are in the mix ... try scripts that do _not_ use MVTools, and I'm pretty sure you'll not experience crashes when using "many many threads".

Seems you're pretty much sold on MCTemporalDenoise, nay? - Can't tell much about MCTD actually (Im a non-user of it), but it's quite possible that MCTD is just too blown-up / not enough optimized to sparse ressource usage. (-Vit- can tell you a story about reducing ressource usage -> see QTGMC thread). Sure enough, any script that forces an additional temporal relation on a 1st-stage MVTools computation is prone to have "exploding" ressource requirements. Which is a problem when trying to use 8, 12, or 256 threads.

Sorry that I don't have any real solution for you. I'm just trying to make understandable where the problems are located. It is important to have an understanding for ressoruce requirements...

... Like the chessboard/rice - problem: one ricegrain on the first field, 2 grains on the 2nd field, 4 grains on the 3rd field, and so further and so on. Why should this be a problem? It sounds so easy! - Well, the problem is that there is not enough rice in the whole darn world that you possibly could populate th 64th field. It definetly is a major problem, even if it seems so harmless at first glance. It is surprising when the hidden complexity is not understood. However IF the complexity is understood, the problem is obvious.
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 3rd June 2011, 01:53   #13  |  Link
Bexley
Registered User
 
Join Date: Mar 2005
Posts: 64
Quote:
Originally Posted by Didée View Post
Seems you're pretty much sold on MCTemporalDenoise, nay? -
Not necessarily.... I just haven't found anything as flexible that delivers the kind of quality it does. I know you're not a fan of it.... I saw your Swiss knife analogy.

Is there something else comparable that would work better in a multithreaded environment?
Bexley is offline   Reply With Quote
Old 3rd June 2011, 02:04   #14  |  Link
Bexley
Registered User
 
Join Date: Mar 2005
Posts: 64
Quote:
Originally Posted by Didée View Post
Well, the facts are: Avisynth 64bit is a buggy hack, period.
I suppose that's really my question.... is there ever going to be something that isn't a buggy hack? Because right now that's all that end users like myself have to choose from. It's a case of 'pick your poison.'
Bexley is offline   Reply With Quote
Old 3rd June 2011, 12:18   #15  |  Link
markanini
Registered User
 
Join Date: Apr 2006
Posts: 299
Lucky you. I get good results from vanilla MDegrain with FFT3DGPU pre-filtering and runs runs stable for me with SET's 2.6 MT build. Here's the script I use: http://forum.doom9.org/showthread.ph...52#post1478652
markanini is offline   Reply With Quote
Old 11th June 2011, 11:05   #16  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,462
Quote:
Originally Posted by Bexley View Post
Not necessarily.... I just haven't found anything as flexible that delivers the kind of quality it does. I know you're not a fan of it.... I saw your Swiss knife analogy. :)

Is there something else comparable that would work better in a multithreaded environment?
Well, I am a huge fan of MCTemporalDenoise, but it's often hard to find the sweet spot. Currently I'm rendering Solaris like this:


SetMTMode(5,4)

FFVideoSource("f:\jobs\sol.mkv")

SetMTMode(3)

Crop(0, 134, 0, -134)

MCTemporalDenoise(settings="medium")
GradFun2DBmod(thr=1.4,thrC=1.0,mode=0,str=1.2,strC=0.0,temp=50,adapt=64,mask=false,show=false)

Crop(0, 0, 0, -2)

SupTitle("f:\jobs\00274.track_4608_exp.sup", forcedOnly=false, swapCbCr=false, relocate=true, relocOffset="0,0,0,0")


Often running MCTemporalDenoise non-threaded just makes it crash quickly (something just requires too much rescources, it would seem; I have 6G, btw).

Running MCTemporalDenoise within an MT"" call is even worse: it's superfast (ca 100% CPU), but super-unstable, too.

Splitting a single huge process up using SetMTMode is usually the only way for me to have it not crash. I have an i7 980X, btw.

If someone knows of a better way of doing it, I'd be very interested. :)
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 13th June 2011, 06:06   #17  |  Link
Mini-Me
Registered User
 
Join Date: Jan 2011
Posts: 121
Are you still having problems running the scripts you want with multithreading, without crashing?

I don't have an elegant solution, but there's a brute force workaround that will allow you to use all of your cores and potentially all of your memory. Short version: Split your result into pieces, concurrently render the different pieces to lossless intermediate files, then concatenate them afterwards and encode.

Long version:

First, do not return the whole result at the end of your script. Instead, split it into N sections with Trim (or stickboy's excellent Trim2), where N is the number of cores on your system (or hardware threads, if you want to try hyperthreading). Write a line for returning each section, e.g. (for four sections in a clip ~200000 frames long):
Code:
input = Avisource("TheFellowshipOfTheLanczosRings.avi")

result = MCFilterOfObsceneSystemPunishment(input)

return result.Trim2(0, 50000)
#return result.Trim2(50000, 100000)
#return result.Trim2(100000, 150000)
#return result.Trim2(150000)
Second, notice that I commented all but the first section. Load the first section in Virtualdub, and render the section to a lossless file (Fast Recompress, Huffyuv). While that's running, comment out the first return line, uncomment the second one, and resave the .avs script. (Changing the script will not affect the render that's currently running, because Avisynth parses the script text when it loads.) Load the modified script in Virtualdub again, and render the second part to another lossless file.

Lather, rinse, and repeat, and you can have as many videos rendering simultaneously as your hardware can handle (mainly your memory and disk performance). Once all of the sections are done rendering a few hours (days? ) later, concatenate them in another lightweight Avisynth script (use a single '+' to avoid audio glitches, instead of "++"), and directly encode the result to your output format. The downside of this method is that it requires a few minutes more work than it would take to load/render a single script with an actual working MT build, and if your final encoder is really fast, writing to lossless intermediates could seem like wasted time. The upside is, depending on your format, encoding to lossless intermediates before encoding the final result might be faster in the long run anyway.

Note that Windows will give each Virtualdub/Avisynth instance as much memory as it can give to a single process, which means that you can ultimately use a whole lot more than 4 gigs at once. The different processes might duplicate a little bit of work at the seams, but this should be insignificant unless you're using temporal filters with a radius of thousands and thousands of frames. I'm only aware of one "gotcha," and it applies to a pretty uncommon use case: If you're using a ScriptClip function that assumes linear access and carries over some result from previous frames, each section will start "clean" without any information carried over from frames before the start of the section.

I've been using this trick a lot recently to get multiprocessing with the official Avisynth 2.6 alpha releases, and it's nice to combine the stability and "correctness" of single-threaded Avisynth with the speed of MT builds.

Last edited by Mini-Me; 13th June 2011 at 08:08.
Mini-Me is offline   Reply With Quote
Old 14th June 2011, 00:49   #18  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 595
Quote:
I don't have an elegant solution, but there's a brute force workaround that will allow you to use all of your cores and potentially all of your memory. Short version: Split your result into pieces, concurrently render the different pieces to lossless intermediate files, then concatenate them afterwards and encode.
I agree to your idea.

my solution:

First, write an avs with avspmod, and do return the whole result at the end of my script.
Code:
input = Avisource("TheFellowshipOfTheLanczosRings.avi")

result = MCFilterOfObsceneSystemPunishment(input)

return result
Second, run this avspmod macro.
Code:
#coding: utf-8
#Macro that outputs intermediate files automatically divided
import sys
import os.path
import subprocess
#import datetime

vdub = r'C:\VirtualDub32\VirtualDub.exe'   #set path to VirtualDub
vcf  = r'C:\VirtualDub32\fastrecomp_uly0_audio_none.vcf'  #set path to vcf file that saved compression setting

entries = avsp.GetTextEntry(['Number of dividing', 'SetMemoryMax(?)'], ['3', '512'])
dnum, mmax = [int(i) for i in entries]

outdir = avsp.GetDirectory('Select a directory to output intermediate files.')

source = avsp.SaveScript()
frames = avsp.GetVideoFramecount()

if dnum > 1 and mmax > 0 and imf_outdir and frames and os.path.isfile(vdub) \
    and os.path.isfile(vcf):

#    enc_start = datetime.datetime.now()
#    print "start   :" + enc_start
    start = 0
    vdubprocess = []

    catfilename = os.path.splitext(source)[0] + '_imf.avs'
    catfile = open(catfilename, 'w')

    for i in xrange(dnum):

        end = frames / dnum * (i + 1)
        if i < dnum - 1:
            trimline = 'trim(%i, %i)' % (start, end)
        else:
            trimline = 'trim(%i, 0)' % start
        lines = 'SetMemoryMax(%i)\nImport("%s")\n%s\n' % (mmax, source, trimline)
        start = end + 1

        imf_avsname = os.path.join(imf_outdir, os.path.basename(source)).rstrip('avs')\
                      + 'imf_%02i.avs' % i
        file = open(imf_avsname, 'w')
        file.write(lines)
        file.close()

        imf_aviname = os.path.splitext(imf_avsname)[0] + '.avi'
        vdubargs = [vdub, '/s', vcf, '/p', imf_avsname, imf_aviname, '/r', '/c', '/x']
        p = subprocess.Popen(vdubargs)
        vdubprocess.append(p)

        if i < dnum - 1:
            catfile.write('AVISource("%s") + \\\n' % imf_aviname)
        else:
            catfile.write('AVISource("%s")\n' % imf_aviname)

    catfile.close()

#    for p in vdubprocess:
#        p.wait()

#    enc_end = datetime.datetime.now()
#    print "end     :" + enc_end
#    enc_tet = enc_end - enc_start
#    print "total   :%s (fps = %.3f)" %
#        (enc_elt, float(frames) / (enc_tet.days * 24* 60 * 60 + enc_tet.seconds))
and I can have as many videos rendering simultaneously as my hardware can handle (mainly my memory and disk performance).

I've been using this trick a lot recently to get multiprocessing with the official Avisynth 2.6 alpha releases, and it's nice to combine the stability and "correctness" of single-threaded Avisynth with the speed of MT builds.
__________________
my repositories

Last edited by Chikuzen; 14th June 2011 at 00:55.
Chikuzen is offline   Reply With Quote
Old 17th January 2012, 13:25   #19  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Hi, sorry to bump this up.

Is it possible to adapt the above script to encode with x264 instead? Or do I really have to encode to lossless first?

Two things comes to my mind. I asking because I have to QTGMC deinterlace a Blu-Ray, and then encode it with x264 after that. My two concerns are:

1) Lack of disk space for a QTGMC'ed 1080p 2 hour long video
2) Hard disk wear and tear

The second concern is made all the more important by the high current prices of Hard disks due to the Thailand floods.

Thanks for looking!
aegisofrime is offline   Reply With Quote
Old 18th January 2012, 08:18   #20  |  Link
kypec
User of free A/V tools
 
kypec's Avatar
 
Join Date: Jul 2006
Location: SK
Posts: 826
As long as you encode with x264 CRF mode (not 2-pass) there's no need to create interim lossless files I think. If you encounter memory problems due to heavy AVS being processed internally by x264 then you might try to separate Avisynth & x264 processes altogether. To see how it's done you can look at command lines generated by wonderful Lord Mulder's Simple x264 Launcher.
kypec is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:28.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.