10 hard won speed tips.

[DeusExMachina]

If you have a slow as hell machine like me (500MHz G4) and need to milk every last drop of speed from your CPU so that you don't have to wait a week for your file to finish encoding, here are some tips that can have a measurable effect on encoding times:

1) do NOT leave any finder window in column mode with a video file in preview. Doing so, even if you have not topped the window, will cause the finder to eat as much as 20% of your CPU cycles, indefinitely.

2) use the "Open Terminal Window" option in the tools section. This causes ffmpegx progress app not to run, dumping progress info to the terminal window instead. Since Progress can use at least 10% of your CPU cycles, it can profitably be bypassed.

3) close any browser window associated with java apps. Even if they are idle, they can eat as much as 30% of your CPU cycles.

4) run activity monitor to find other offending parties. Quitting processor hogs is always a good thing when speed is important, as long as the program is not critical. Hint: if you can't quit the program from the application menu (i.e. it is not a parent process) it is a good idea to leave it alone.

5) after you are done with it, quit activity monitor. It can have over a 10% overhead, so get rid of it after it has served its purpose.

6) encode to a drive other than your main system drive. There are a number of quirks that make you want to avoid using your main drive as the target disk.

7) letterbox manually, not automatically. This is much faster.

8) don't start a new topic at videohelp.com and then ponder the existential nature of the myths of Gilgamesh! Keeping the new topic window or the edit post window open keeps Safari using almost 30% CPU on my system.

9) if possible, preview the results before you get too far into the encode. The preview function is a bit hairy, but you can always just encode about 1% then open the encoding file and view it in an external player. No sense wasting your time encoding a file only to find that you mistakenly set it to 16:9 when it should have been 4:3. Which leads to #10…

10) double check all setting before you encode. No sense wasting time only to find you accidentally set it to 5.1 Surround when you wanted stereo.

Doing all the above takes me from ffmpegX using about 12% CPU to about 70%, around a 600% increase.

I am sure there are others, feel free to add them on.

[BJ_M]

don't stay logged into videohelp.com! Keeps Safari using 20% CPU on my system.

shouldn't be -- on the forum pages, there is nothing running on this site..

unless you parked on a page with a lot of animated gifs ..


as for java - yea , that's a for sure ..

[DeusExMachina]

correction:
Don't stay here with an editing new post window open, pondering the meaning of life. For whatever reason, if you have the post new topic window open, it eats system resources.

I edited my original to reflect this change, too.

[Mildew]

DeusEx, thanks for the great tips. One question. How do you do letterbox manually?

If you have a slow as hell machine like me (500MHz G4) and need to milk every last drop of speed from your CPU so that you don't have to wait a week for your file to finish encoding, here are some tips that can have a measurable effect on encoding times:

7) letterbox manually, not automatically. This is much faster.

[prop]

I was going to ask the same question. I was recently told by major to "Decode with Quicktime" with the letterbox option enabled, but I am interested in speed as well! How to letterbox manually and know the proper dimensions?

Also, how do I tell if I accidentally set my video to 4:3 when I meant 16:9?

[DeusExMachina]

If you use the ffmpeg option, you can set padding in the filters tab. This sets black bars in all four directions to the values you set. Just subtract your video's resolutions from the desired resolutions, and set the padding accordingly.
Warning, for what ever reason, the values are "backward," i.e. top/bottom/left/right. This can be confusing, since the standard format, e.g. 720x480, is given in width x height. Keep this in mind and you're all set. Sometimes this is actually an even better option than automatic, since it can keep the file closer to it's original aspect ratio. This is mostly true on files generated for the computer, rather than DVD/VCD RIPs. Also, since you can add padding left and right, this can allow more of your picture to actually be seen by the viewer (depending on it's original size) since as many as 50 pixels on a side can be lost when viewed on a TV.
So, for instance, if you have a computer video at VGA resolution, 640x480, you can add padding in the filters menu as:
0/0/40/40.
If the file is, say 640x360, pad to:
60/60/40/40. This allows all your video to be seen on a standard TV.
Beware the scary world of PAR vs. DAR, however. Just because a video is not at full 720x480 deos NOT mean that it will look ok if you pad it to 720x480. As I have learned, the pixel aspect ration of some formats, for instance 480x480 SVCD, is already such that is generated a 4:3 aspect ratio, since the pixels that make up this format are NOT square, they are, instead, wider than they are tall, thus 480 pixels covers the same distance as 720 pixels in the DVD aspect ratio.

As far as aspect ratio, if you have not encoded another video since the last one began, you can just check the settings in the video tab. If you have opened another file, you can either try opening the partial encode in ffmpegX. Sometimes it will actually show it as 16:9 in the information for the file. Another option is to open it in QT or VLC and check the info there. Failing that, ope the partial encode in a player like VLC (QT is unreliable here) and see if it looks right. If it look compressed or stretched, it is a good indication that you have the DAR set wrong.

[DeusExMachina]

Just as an aside, but I think that the reason that padding manually is significantly faster is that the black bars are added OUTSIDE of the encode. I.e., the file is encoded, frame by frame, and after each frame is encoded, the black bars are added separately to each frame. Doing it automatically causes the bars to be added BEFORE the encode. Thus, in the first instance, a certain bit rate is attained, without dealing with the pixels in the padded area. IN the second case, the pixels in the padding ARE included in the encode, so the bitrate has to be higher, which takes the encoder that much longer to process.

[Jirka Cech]

how fast is encoding of 90 min DVD movie to DivX on G4 1.2 GHz iBook? 20 min? 3 hours? 12 hours? week? on average...and how does it compare with mencoder on x86 (PC)

[extract]

If you have a slow as hell machine like me (500MHz G4) and need to milk every last drop of speed from your CPU so that you don't have to wait a week for your file to finish encoding, here are some tips that can have a measurable effect on encoding times:

*SNIP*

10) double check all setting before you encode. No sense wasting time only to find you accidentally set it to 5.1 Surround when you wanted stereo.

Doing all the above takes me from ffmpegX using about 12% CPU to about 70%, around a 600% increase.

I am sure there are others, feel free to add them on.

11) Renice the process (ffmpeg or mencoder or whatever), use renice command in the terminal or an app like nicer og renicer and renice to -20 to maximize the processing time given to your encoding.
12) For best quality/encoding time ratio go for Mencoder XviD, i suggest testcoding a chapter 1st., setting in the Options tab: Check High Quality, Use B-frames, Two-pass encoding, Trellis quantization. Audio: if it isn't a music film go with 96 Kbit at 48.000 Hz sampling (if it is from a DVD source), Stereo and mode ABR.

[DeusExMachina]

It guess it all depends which direction you are going. I tend to go in the opposite direction, encoding FROM formats like XviD into MGEG-2 so that I can author to DVD such that it will display in standard players.

[Mildew]

11) Renice the process (ffmpeg or mencoder or whatever), use renice command in the terminal or an app like nicer og renicer and renice to -20 to maximize the processing time given to your encoding.

Top shows two processes running when converting with ffmpegX:
1) movtoy4m [uses a substantial amount of CPU]
2) ffmpeg OR mpeg2enc

Which should I renice? I don't even know what "movtoy4m" does.

[prop]

Is it really necessary to renice unless you're running more than one processor-intensive task? When I transcode, I'm typically ONLY doing that - therefore, have I got anything to gain by renicing an app?

If it'll speed things up, I'll do it, but I thought UNIX was supposed to be smart about process management. As major says on his web page, "OSX Unix core reallocates processor ressources in realtime as needed."