Notices

As a reply to JustJoe asking to see "benefit of going from 480 to 600+ in resolution", I just uploaded 2 videos of the same source:
TestVideo-480-270-800bitrate.avi
TestVideo-640-360-800bitrate.avi

They both play correctly on my N800, I cant see any speed difference.

The scenes in this small videos are "active", and if mplayer is able to handle this video correctly, I think it should be able to handle any type of scene.(again I'm using 1 single pass, I THINK that with 2 passes the bitrate may "peak" on action scenes and cause some lag)

I just re-encoded an episode of 2 and a Half Men with PDXE:
624x352 at 23.976 fps (I chose not to change the original resolution)
XviD codec 2 pass (Virtualdub gives it 691 kbps) (the original was over 1,000 kbps)
MP3 sound at 128 kbps
Total file size 116 MB

Although I haven't let it run completely yet, I was surprized -- nay: stunned -- that mplayer appears to run this file without any stuttering or tearing on my N800. Clearly Serge has been doing some sneak-finetuning while I wasn't looking.

Can you guys confirm the version of mplayer you are using? I can't get it to play smoothly regardless of what codec/bitrate/resolution I use. The built-in Nokia Media Player seems to work *FAR* better for me (mpeg4). See my thread here:

http://www.internettablettalk.com/fo...ad.php?t=27213

Ignore the stuff about UPnP streaming -- the results are the same even if the file is played off the tablet directly.

The built-in player works better with h.264/AAC than mplayer, but mplayer handles MPEG4 (part 2, not part 10)/MP3 better than the built-in player.

MPlayer 1.0rc1-maemo.29.n8x0
when I try to launch a video via the terminal , it starts to lag after some seconds, while it play correctly when launched via the GUI launcher.

Thanks karatchov, for going through the trouble of encoding and uploading.

I was paying particular attention to the details in black/ shadow and mist, which I think is the weakest part of the videos that I've transcoded. I think I'll stick with 480 width, since I wasn't able to see a significant difference in quality while playing the videos you uploaded -- on the N800. Viewing them on the desktop computer showed the differences very well, but the N800 screen is small enough that I think those details get lost.

Just FYI, I'm getting better details on single pass runs, (at least on the slow sections), though file size is larger than on double pass runs. (200M original.VOB, 54M for single pass, 50M for double pass). To see the difference requires much more zooming (in) than normal viewing would allow, and of course these very small differences aren't even remotely viewable on a screen the size of a tablet screen.

Thanks again,

Joe

MBWOTO Given a fixed bitrate, it doesn't really matter how dynamic a scene is, the amount of data to be pushed around is usually the same (unless it's *totally* static, of course). There are two ways around this:

a) Use 1 pass fixed bitrate. Yes, gets artifacts on intense action but hey, better blocky than choppy, right ?

b) Use a bitrate cap. If you use mencoder this is done with -lavcopts vrc_maxrate=700 not sure for other SW/codecs.

EDIT: And the oft overlooked single most playback quality killer on the NIT: 48000Hz audio streams. Conversion of those to 44100 is a must.

The amount of data may be fixed, but it does not mean that the amount of work to be done will be fixed as well when decoding video. Scenes with lots of motion or panning still take more cpu than mostly static scenes even with the same bitrate.

Yes, fixed bitrate single pass encoding helps to reduce cpu usage spikes and is preferable from the performance point of view.

Just one more thing, cartoon/animation is typically much easier for cpu to decode. For example, N810 just barely has enough power to be able to decode and playback 480p big buck bunny video in realtime (without sound). This of course needs some tweaks (crop filter to letterbox it from 854x480 to 800x480) in order to prevent cpu from wasting too much resources on software downscaling because the video itself is bigger than screen resolution. It should be possible to find some animation in 640x480 resolution which would play fine on the device And adding missing ARMv6 optimizations could help a lot for sure.

Here is the log of 480p video playback:
So decoding and showing all frames of this 596 seconds long video takes 591 seconds which is just a little bit faster than realtime. Of course playback speed is not uniform, but decoding ahead and buffering can help to solve this problem (like mplayer-xp fork or omapfbplay proof of concept demo program from beagleboard). And adding audio would be the last straw to break everything.

And of course getting such good looking results is practically impossible with any real non-animated 480p video

Yes, audio pipeline is a major pain on N8x0 devices. It goes through ESD daemon and ends up in DSP. It is hard to even get audio/video playback in sync, let alone be sure that no extra cpu resources are wasted on resampling somewhere.

YES!! THANK YOU!! That solved my problem. Now my mediatomb on-the-fly transcoding setup works with Canola flawlessly! All it took was setting the audio to resample to 44100 (was 48k). I knew it had to be something simple.