(Written offline, then pasted here for matters of sanity -- mine, that is )
Even on the chance I'm going to be the party pooper here, I'll throw in that the original topic of this thread was video playback on the Zaurus SL-5500, and, even "worse", on an "old" Sharp ROM (i.e. 2.38).
It's all nice and dandy when people come along and tell you how great their newly built MPlayer w/Kino performs on their SL-5600/C-XXX or whatever, simply because they are either unaware of or do not care about the fact that
no, not all Zauri are created equal -- and since recent MPlayer builds are optimized using XScale instructions, they will simply produce a nice, clean Illegal Instruction error when run on the 5500's SA-1100 processor.
It would be nice if people kept that in mind before making the usual blanket statements that 'it works just great with MPlayer' ...
That said, a few more minor things towards the topic at hand:
dreadlocks, it's not nice to completely ignore the rest of this thread and not mention VLC as an option for Zaurus video playback on your tutorial website -- maybe you should add it as well (hint, hint).
As for video encoding, well -- I for one don't use AVI as a container, since it was devised by the Evil Empire -- I personally prefer ISO standards with regard to that, so I build my video usually within an MP4 container (yeah yeah, I know, I'm a smartass). If done carefully enough, you can even produce files that will not only play pack on your Z, but on a 3GPP-capable mobile phone as well.
Granted, that certainly isn't for everybody, since it takes a whole zoo full of installed software, also depending on the codecs you intend to use. But I digress.
A few general points I can add, though, based on my own observations (note that these are rather VLC-centric, so YMMV and all are, of course, IM(NS)HO):
When it comes to audio, anything beyond 32 kHz sampling rate really is overkill for use on a mobile device -- resampling audio down to an appropriate rate will usually help playback a great deal. In addition, reducing the number of channels will help as well -- let's be honest: do you
really need stereo sound for that episode of Gilmore Girls or that newscast when you're on the road?
Codecwise, my experience is that MPEG-1 Layer II uses the least, HE AAC the most CPU cycles on playback. Vorbis uses somewhat to quite a bit more than MPEG-1 Layer III, but for all of them, the common rule is: the lower the sampling rate and the lower the bitrate, the lower the CPU consumption. My personal favorites are AAC LC in stereo at 24 kHz w/32 kBit/s and, if I feel really nasty, HE AAC in mono at 32 kHz w/12 kBit/s.
On video: basically, similar rules apply. For one thing, frame rate reduction is your best friend. You should, however use an integer divisor whenever possible -- otherwise the video will seem jerky in sequences that have uniform large-scale movement, i.e. zooms or pans. This of course is simple enough for film or PAL sources, where a simple division by 2 yields a nice 12 or 12.5 fps. No problem with 30 fps NTSC sources as well -- unfortunately, modern day NTSC uses 29.97 fps, i.e. 3000:1001. You may want to keep that in mind when doing conversions of NTSC material.
Obviously, size does matter as well (but we all knew that, didn't we? ) -- while QVGA (320x240) resolution is a Nice Thing, it may not always be called for. If you want really small file sizes, QCIF (176x144) may be the thing for you. It gives a fairly acceptable result and currently is on of
the favoured resolutions for mobile applications (e.g. 3GPP phones). Granted, you won't be able to read fine print, but there is lots of material that doesn't need the extra resolution provided by QVGA. Of course other resolutions are acceptable as well (240x180 or 160x120), but keep in mind that some codecs may not like them (e.g. H.264/AVC wants something that is divisible by 16).
Again, regarding codecs, similar principles are at work as are with audio. H.264/AVC uses the most CPU cycles on decode, with Theora in second place, followed by Simple MPEG-4 / H.263(+), with MPEG-2 and MPEG-1 using the least. In all cases, B-frames will cause additional load, so avoid them whenever you can. Less bitrate and/or quality on encoding will result in lower CPU consumption on playback independent of the codec used as well. Oh, and one major thing that, of course goes for
all digital video:
you need a clean source. Noisy images will drive up the data rate excessively and cause loads of really ugly artifacts that you want to avoid at all cost.
My personal favourites here are QVGA 12.5 fps Simple MPEG-4, VBR capped to a 320 kBit/s maximum for material that needs the resolution or that is 'important' to me and QCIF 12.5 fps H.264/AVC VBR with a 28-30 or so quality setting, usually with no maximum bitrate. If a source is really getting out of bounds, I add a cap of, say 112 or so kBit/s. But that rarely happens.
On closing, I'll revisit containers for a moment, since they're also involved when it comes to performance. Seems that MPEG PES and MPEG TS cause the least overhead, followed by AVI and, last but by no means least, MP4. Of course compared to the exorbitant amount of CPU cycles gobbled up by video and audio codecs, this practically is a non-issue. Just thought I'd throw that in for completeness' sake, and to give a good excuse to those using AVI instead of a certified ISO standard
Now comes the hard part: based on the above principles, everyone has to make up their own mind as to what is important for them and make the appropriate choices to achieve the desired result. For me, it boiled down to two combinations of the abovementioned favourites:
1) Simple MPEG-4 @ 320x240 @ 12.5 fps max. 320 kBps Video w/ 2ch 24 kHz AAC LC @ 32 kBps Audio
2) H.264/AVC @ 176x144 @ 12.5 fps w/ 1ch 32 kHz HE AAC @ 12 kBps Audio
and occasionally I will build files that are
3) H.263+ @ 176x144 @ 12.5 fps w/ 1ch 8 kHz AMR @ 12 kBps Audio
or the like if it should be playable on a current generation 3GPP mobile phone.
Rarely I do build OGG files containing Theora/Vorbis at similar parameters, but, to be honest, usually just for testing purposes. While I think it is important to have completely free alternative for A/V content on computers, I just don't feel that Theora is an accepted standard yet like Vorbis already is. Then again it's still in beta, so I probably shouldn't be surprised.
Still with me? Wow, you really must be patient
Anyway, should any of this be of any interest to you,
dreadlocks, feel free to use it for your tutorial. If so, glad I could be of help.
As for my original intention in reviving this old thread, I decided to put up the
updated VLC binary for those who dare
Just repeating that in case it got lost with all the discussion going on ...
Best regards,
Chris
