Agree. If it is the case that the internal do not use all acceleration possible. I'm so looking forward to check out what mplayer will manage once properly tuned. Because, even now, the internal is ok for my use. I'm watching my recoded TV shows at 400x240 25fps without visible dropped frames.

Will be fun to check out possible encode params when mplayer is ready

Yeah, it is somehow very funny. Most of the PDA's with Xscale out there don't even have a DSP, so all the multimedia stuff is processed by the ARM/Xscale core, while you watching movies at an acceptable qualitiy and don't even use your ARM Core But I think it is not possbile to load both the ARM core and the DSP at 100% while watching a movie. You can't just mix up mpeg4 decoding on the one and on the other processor. That's while the mplayer developers tried to decode the mpeg on the arm core, while decoding audio and do some image scaling on the dsp.
I am sure there will be a performance boost... I hope that one day, the IVA coprocessor is going to be used. TI specs said that it can handle 640x480 mpeg @30fps . But there is not much going around with IVA integration. I also hope that Nokia is not going the "We are going to castrate the N800's hardware in order to be able to recruit special Multimedia Devices" way...

since OS 2007 update on my n800 I've tested the following parameters based on sveinan's enhancement proposals of 770-encode.

noky => { abitrate => 128, vbitrate => 600, width => 400, height => 240, fps => 30, vrcbufsize => 500, vrcmaxrate => 1000 },

I also active index genration for mencoder.

Till now I have been able to watch the videos generated (2 only) without any problem on the standard Media Player

Just thoght I would share this info for those interested.

dwardo

Would it make sense to do the following in 770-encode.pl to limit vbitrate when preset is more than needed when considering fps width height and vbitrate of original file...

my $ovbitrate = int($info->{vbitrate}*($ofps*$w*$h)/($info->{framerate}*$info->{width}*$info->{height})+0.5);
$ovbitrate = $preset->{vbitrate} if $preset->{vbitrate} < $ovbitrate;


with this a original file
VIDEO: [XVID] 624x352 12bpp 23.976 fps 1010.0 kbps (123.3 kbyte/s)

would be encoded with:
vbitrate=441 even if the preset contained 600 as a max value.

dwardo

That's an interesting suggestion, but OTTOMH only makes sense when the input format is the same as the output format (i.e. DivX/Xvid)?

I've got some outstanding suggestions from Benjamin Réveillé to look at (apologies if he's reading this), but a new computer and the long Easter break should help knock some of these items off the list.

Cheers,

Andrew

Actually I am Benjamin Should have told you so.

For the info, I have coded the third proposal I made (the ability to furnish a list of files to encode and determine automatically the outfilename. (Am learning pearl while doing so Which I like more and more...)

I'll send it to you latter on.

As for the framerate, maybe we can test get the original file encoding in movieIfo function and take the proposed measure only if the original file encoding is equivalent to that we want to create... I'm not an encoding guru at all, but there must be some sort of equivalence we can work out.

dwardo