swingheim

The other thread was getting quite long, and since this was not a complaint, I wanted to post it anew, and hope it might be of benefit to others.

-= section 1 =---------------
To increase the speed of the encoding, since we are doing multi-pass encoding, I would think that you would not have to re-encode the audio twice. So, ignore the audio options (do a straight copy) for the first pass, and then re-encode the audio on the second pass. That should save a little time. I haven't tested this yet... but will shortly.

-= section 2 =---------------
If you have a wide-screen movie that doesn't fit the 4:3 aspect ratio, you can add those black strips across the top and bottom of the video to get the 4:3 ratio.

Example:

Source video is 704x336, and I want the result to be 320x240. If I straight resize the video, everyone will look "squashed". So, lets add those black stripes above and below the video:

VirtualDub makes this easy to do. We simply calculate the resized video as such:

704:336 = 320:X
Solve for X: 320 * 336 / 704 ~= 152. In our RESIZE video filter, we say we want our video to be 320:152, then check the box below, and say we want the resultant video to be 320:240.

-= section 3 =---------------
Video will laaagg behind the audio when it cannot draw the frames fast enough.

I had a similar problem with my laptop: if I didn't have DMA enabled for the DVD drive, the DVD disc could not be read fast enough to keep up with real-time playback. It is similar with your Axim.

The solution? Free up system resources. Make sure no programs are running in the background, and check to make sure your unit has enough RAM to properly cache the video. If your video is lagging behind 15-20 minutes into your movie, odds are you don't have enough free RAM. Free some up.

I haven't thoroughly tested VirtualDUb yet, but a general rule of thumb: free up your machine's resources when encoding video. It is VERY CPU intensive, and if you are running other programs in the background, it could (again I haven't tested it yet) cause errors inyour encoding. Remember the early days of CD-burners? If you launched PhotoShop/Word/Excel/Quake3 while burning a CD, the read-ahead buffers would not get repopulated, and you would get a buffer-underflow error.

-= =-------------------
I have a 2.4 gHz machine with 1 GB RAM, and I am encoding video at around ~4x.


I know I might have touched on things in previous posts, and apologize if you feel this post was too repetitive.

swingheim

I just tested it, and if you COPY the audio on the first pass, and encode it on the second, the process is faster.

geezer

Good tip on the audio copy during first pass. Wonder if it would work the other way around, since first pass is usually quicker than second. Direct audio copy on the second pass should speed up the more intensive video processing.

I'll have to give it a try. Thanks.

__________________
Learn as you go - share what you know

fibrizo

Note: I always skip encoding the audio on the first pass, I didn't add it to the guide to keep it as simple as possible (least amount of things going wrong.) once you get the basics working you can easily disable the audio on the first run... The fastest way (the one I use, is just to have no audio on the first pass (even saves the effort of copying the audio.

as for the black bars, don't bother. It's a waste of space and encoding to encode those black bars...

here's the simple solution... I've posted it before. but maybe I should add it to the main guide...

Say you have a widescreen source... lets say 480 x 208 or something like that...

Your final width should always be 320.

So take 320 and divide it by the width of your widescreen film.

which in this case is 480 so

320/480

This gives 0.6666667

now multiply by your movie's height, in this case it's 208

0.666666667 x 208

This gives us 138.666 or 139 rounded...


so our resized film would be 320x139, however...

Divx requires that your width and heights for your film be mutiples of 16...

So divide 139 by 16

139/16 is 8.6875

Which rounds to 9

So 9 x 16 gives 144

So you should set the height to 144

so your final film size is 320 x 144...

If you are following the guide I wrote, just enter that into step 1 instead of 320x240.

(Note this does do some stretching of the picture, but it's basically unoticable... If you downloaded that test file I put up, it's encoded this way and slightly stretched, but not noticably at all...) If you really want to be anal about it, it's possible to correct it completely and just put black space into the file, but that takes alot more calculation.

mroberon1972

Interestingly, I have found 120 kbps, with 15 fps for the video rate works well on the axim. You can even read the subtitles in anime, (except in one show, in one video sequence, for about 3 seconds, out of hours of total video. And upping the compression to 160 did NOT help...).
For most audio on shows I use 22000, 16 bit, mono. Sounds fine!

This gets about 1 meg per minute for storage.

Overall, I am very happy with the quality levels I get from this.


Mr Oberon.

derobbie

I always use one pass, quality based encoding. This takes me about 2 hours (on my 600 MHz Toshiba)

This results in a file of more or less 100 MB for a 700 MB divx.

Also I split it up in files of about 20 MB and use a playlist. This makes it easier to copy the files to the CF card

musttang87

thanks didnt know this!

__________________
Basic Axim X5 OCed to 500 mhz
scan disk 512mb CF card
sena black/blue case