Virtual Dub Preformance

[Toshi.des]

I was wondering if there is a way to make vdub encode faster.



Currently it takes up an avg of 30% of my processing power, and for some reason it's using the third core the most while not using the others really at all. I did set processing thread priority to even higher. But is there a way to use more processing power to make it go quicker? While I do like that I can do other things while it's encoding sometimes I would like it to go faster.

[trythil]

There's a few things at play here.

(1) You almost will never need (nor, for that matter, be able to) specify which core(s) a process will use. That's the process scheduler's job.

(2) There is ongoing work to make VirtualDub more multi-thread friendly; check out the 1.7 branch if you're interested. From what I can tell, the bulk of the work Avery Lee is doing involves reworking the rendering engine (which, among other things, includes the filter graph) to run multithreaded, which means that if you are applying some particularly expensive filters that can be easily parallelized, you may see a speedup there.

(3) Some encoders support multithreaded encoding. (Lagarith does, for example.) Some don't. You need to figure out this for yourself. If the encoder does support it, turning on multithreaded encoding often does result in a speedup and greater CPU utilization, but sometimes may reduce encoding efficiency and/or quality. (Some people have reported this with e.g. x264.)

(4) If you're using a frameserver like Avisynth, that throws another variable into the mix. Prior to v2.6, I think Avisynth's parallelism was limited to filters that explicitly multithreaded themselves. Avisynth v2.6 allows you to specify how many threads you want to use for processing the filter graph; see the GetMTMode and SetMTMode functions. Note that such work is still experimental, so if you're using some badly-behaved filters, expect things to break badly if you push it too far.

[trythil]

There's a few things at play here.

(1) You almost will never need (nor, for that matter, be able to) specify which core(s) a process will use. That's the process scheduler's job.

Or, more precisely, you almost will never need (nor, for that matter, be able to) directly specify on which cores to run which threads.

[Phantasmagoriat]

I don't have multiple cores myself, but you might find this relevant:
http://www.animemusicvideos.org/phpBB/v ... hp?t=81499

*shrugs*

[post-it]

.. to speed-up Virtual Dub .. use less filtering, clean your video's first and keep it simple.

.. Virtual Dub is just the "trim & save" portion of any Video Editor; it has the option of correcting some problems and, unlike most "trim & save" editing sections, can save its work Directly to a Codec instead of Dropping-it-back to a time-line.

.. Another thing that will slow Virtual Dub to a crawl is "the prior Editor's encoding" missing or improperly using Frame Timings. Virtual Dub pays' attention to Video Frame Structure; you'd be surprised how many Editors "do not follow the rules" for streaming most Videos!

.. in conclusion .. the speed of Virtual Dub totally depends on the Prior Encoder of that Video.