How to speed up tmpgenc?

[RabidDog]

I love the quality and flexibility of tmpg but it is just so damn slow.. when I transcribed a DVD to svcd it took a total of twenty two hours to do a two hour film and thats NOT using any filters or best quality motion search and leaving the audio at 48000khxz ... this is all on a p3 866 256mb of ram ? more ram ? or this is std? ideas anyone?
I recently practiced on the Office giveaway Dvd and that took about 3 hours !
(oh and this is to svcd 2 pass Vbr)

[vcdfreak]

By setting the preview option to 'Do not display' or 'Display with thinning' can shorten the conversion time a bit.

By not fixing the preview size also quickens the conversion process by a small amount.

Setting the task priority to High helps if other apps are running with TMPGEnc.


On the hardware side, the processor speed is inversely proportionate to conversion time. The faster the processor the shorter the conversion time. Adding RAM to 1 Gig helps as TMPGEnc is very memory consuming as you can easily check this out using the task manager. Usually TMPGEnc use up the max virtual memory available. Also need to set Windows to minimize the use of swap space so that more physical memory is used(important: this only applies if you have 1 Gig of RAM or more, memory less than that can significantly reduce the performance of Windows!).

Hope this helps.

[miketree]

Now, I'm not an expert, but the way I remember it is....

Don't use 2 pass! It'll reduce the time by about 1/2

[SingSing]

The TMPGenc plus can do motion estimate.
It speed up about 30%.

[poopyhead]

if you want to speed up tmpgenc, you need to get faster CPU...(nothing else really matters too much if you have a decent amount like RAM and HDD)..just make sure you set your tmpgenc priority to highest and close all other programs when you're encoding...otherwise, upgrading the CPU makes the most difference. (i.e. i have 2 comps that i use to encode...1 comp is 1.2 ghz athlon that encodes 2 hr movie in about 6-8 hrs, while the other comp is only 650 mhz and takes roughly 12-14 hrs to encode the same movie)

the other stuff ppl been telling you to decrease encode time will also decrease the quality...

higher quality usually means longer encode time

(i.e. 2 pass vbr effectively doubles the encode time, but has really high quality if you want to fit a movie onto less discs. also, motion search accuracy should NOT be set to the lower settings or motion estimate like SingSing said. yes, it will speed up the encode process, but it will lower the quality of the encode. motion search accuracy set to high quality (slow) will increase the quality of your rip w/o increasing the file size.)

[medievil]

The way I sped Tmpgenc up was to switch to CCE!!! Personally I think CCE is of much Higher quality and faster than real time encoding!

[andie41]

I certainly agree with previous posts-get a faster CPU AND faster Ram!
A few days ago, I finally decided it was time to upgrade my Celeron 300 OC'd @ 450. Four years ago this was a damned fast system, but time left me behind. Over the years, I had upgraded my Ram, display card and hard drives but the CPU was holding me back.

Previously encoding with TMPGenc would require more than 20x the source length (30 minute source required over 10 hours to encode). I just upgraded my MB, CPU to Athlon XP 1700 and DDR. I knew the difference was going to be significant, but I didn't realize it would be as much as it is.

My first encode with TMPGenc was slightly less than a 5x ratio. I had wanted to try CCE for months, but my processor was not supported so I eagerly tried a CCE demo and was amazed that it was over 35% faster than TMPGenc. Then I looked in the Enviroment settings in TMPGenc and discovered that SSE was not enabled. I enabled SSE and was delighted to see the encode time at slightly less than CCE.

This is only my third day with my new system, and I am "knocking on wood" that there are no "gotchas" waiting to bite, but currently I can encode with TMPGenc at less than 3x using motion estimate and a little over 3x using normal motion search.

All encodes using single pass.

I OC'd the FSB by 7% and knocked another 5% off encode time.

andie

[RabidDog]

All interesting stuff ... cant afford the $$ for CCe. Better investment would be to buy new mobo +cpu. Actually a dual Cpu system looks like the best bet with raid 0 (u can do this with two differrent drives cant you?) and DDr533. -------- Why cant my super duper GFX card with its own 64mb of memory and a gpu (optimized to perform Video) take some of the processing load?? what are my vertex shaders and dual pipeline registers doing?? I'm sure the Gpu could perform some of the transforms required in 10% of the time it takes a general purpose CPU.

[xed]

That's what I love about this forum -- the helpful suggestions...like "Switch to CCE." Isn't that a useful
suggestion? Go out and spend $2000 to replace a piece
of superb $50 shareware...what a magnificently practical
suggestion. But wait! Here's an even *better* suggestion...
Upgrade your computer system to a massively parallel
supercomputing stack with 256 nodes -- that will only cost
2.5 million dollars, so it's even *more* practical than medieval's
wonderfully helpful suggestion of spending $2000 to replace
a piece of $50 shareware.
Oh, but better yet -- hire workmen to replace all your conductive
compute rcomponents with solid gold and install a cold room
and fill it with liquid nitrogen, then overlock your array of
parallel supercomputers -- that's even *more* practical.
Yes, the folks on www.vcdhelp.com are just brimming with
marvellous practical helpful suggestions, aren't they?
---
Back in the R*E*A*L world, here's how to speed up
TMPGEnc encoding _drastically_ without doing something
as terminally dense as pissing away $2000 to replace a
piece of $50 shareware...
[1] Do NOT use 2-pass VBR. In fact, don't use CQ or VBR
at all. Use CBR. By using a high CBR (say, 5 mbit/sec) you
are in effect trading off file size for speed. Going from 2-pass
VBR to CBR chops encode time drastically, by at least a factor
of 2.
[2] Use no filters and set motion estimation to NORMAL
and turn all previews OFF. This will speed up your encoding
time by another factor of 2 at least. Scenes with rapid motion
may look a little funky, but once again that's a trade-off.
[3] Try using a lower bitrate. Surprpisingly, many types
of video sources look great when encoded at bitrates
as low as 3 mbits. This could drop your encoding time by
another factor of 2.
[4] Have you thought about going to SVCD? Encoding
at 480 x 480 MPEG-2 takes roughly half the amount of time
required to encode at 720 x 480 (since you have approximately
half the total number of pixels in a 480 x 480 frame as in a
720 x 480 frame). There are plenty of "how to" guides on
this forum showing how to burn a playable SVCD file or files
onto a DVD-R. And in my experience, 480 x 480 SVCD at
5 mbits/sec looks nearly indistinguishable from 720 x 480 DVD
at 5 mbits/sec.
---
If you add up these time-saving steps, you'll find that by
using 'em all you can speed up your encoding by somewhere
between a factor of 8 to 16. That ain't too shabby. Of course
there are some minor trade-offs...by using CBR you'll get larger
encoded files (fine, encode the whole MPEG-2, then chop into bits
using BBMPEG or TMPGEnc if it won't fit on a single DVD) and
you may get some hinkiness with fast motion and, if you use
a low bitrate of (say) 3 mbits/sec, you might see some minor pixelation
on very fast-changing scenes... But these are pretty minor
trade-offs. Especially for speeding up your encodes by around
a factor of 8 to 16.

[poopyhead]

Upgrade your computer system to a massively parallel
supercomputing stack with 256 nodes -- that will only cost
2.5 million dollars, so it's even *more* practical than medieval's
wonderfully helpful suggestion of spending $2000 to replace
a piece of $50 shareware.

errrr, perhaps you're not in the real world...CPU's are really cheap right now...check out www.newegg.com for yourself

[1] Do NOT use 2-pass VBR. In fact, don't use CQ or VBR
at all. Use CBR. By using a high CBR (say, 5 mbit/sec) you
are in effect trading off file size for speed. Going from 2-pass
VBR to CBR chops encode time drastically, by at least a factor
of 2.

welcome to the real world... people actually care about quality while still trying to fit on reasonable number of discs...CBR is old and sucks. 2 pass VBR is for people who want good quality and PREDICTABLE filesize when trying to fit on a certain number of discs...

trying to promote CBR is just plain stupid.

[2] Use no filters and set motion estimation to NORMAL
and turn all previews OFF. This will speed up your encoding
time by another factor of 2 at least. Scenes with rapid motion
may look a little funky, but once again that's a trade-off.

may look a little funky? motion search accuracy is a great way to increase the quality while NOT increasing the filesize. in essence you're telling them to sacrifice quality just to get a little less encode time. best setting is high quality (slow)....the highest quality is not worth it.

also, filters sometimes may be needed. the de-interlace filter has come in handy when getting rid of those annoying lines while still using forced film.

[3] Try using a lower bitrate. Surprpisingly, many types
of video sources look great when encoded at bitrates
as low as 3 mbits. This could drop your encoding time by
another factor of 2.

errrr.... we're talking about making SVCDs here, not DVDs...no one even encodes that high for SVCD and expect for it to fit on a reasonable number of discs....also, dvd player compatibility is a BIG concern when encoding at such high bitrates.....try sticking between 2-2.5 mbit/s

[4] Have you thought about going to SVCD? Encoding
at 480 x 480 MPEG-2 takes roughly half the amount of time
required to encode at 720 x 480 (since you have approximately
half the total number of pixels in a 480 x 480 frame as in a
720 x 480 frame). There are plenty of "how to" guides on
this forum showing how to burn a playable SVCD file or files
onto a DVD-R. And in my experience, 480 x 480 SVCD at
5 mbits/sec looks nearly indistinguishable from 720 x 480 DVD
at 5 mbits/sec.

this is just plain dumb...did you even read the original post? this entire thing was about making SVCDs, not DVDs.....

hence, w/ SVCDs....size and quality are usually more important than a couple of hours of extra encode time

[gll99]

RabidDog:

Don't cut any corners to sacrifice quality you will just redo the work cause you won't be happy. If its worth saving then take the time it needs. Some of the tips are very practical and don't sacrifice any QA

With my an old P1 200 mmx, I usually took 44+ hours to process a 2 disc svcd until I got what I wanted.


My current P4 now lets me do some in close to realtime or realtime x2 or realtime x4. Guess which one I pick?

I would wait and upgrade MB cpu and ram at once so you get compatible stuff. One of my friends bought extra ram for an older sys then changed computer and went with DDR ram which meant he wasted the extra 133 sdram ram and lost it on a cheap resell for the sake of a few months.

[RabidDog]

I dont use any filters and have used motion quality from normal to highest quality ... this doesnt really affect the time taken. 2 pass vbr is the only way for me as I want all

projects

to fit on either one or two Cdr max. I sometimes lower sound bitrate to get it to fit. I will suffer the time taken for great qual output. But hows svcd encode compare to divx5 encode, timewise?

[kitty]

Pentium 4 2.8 GHz wouldn't hurt or if you have an extra dollar or 2 dual Pentium 4 Xeon processors.