This is a binary of the VideoLAN client, version 0.8.5 (final)
(see http://www.videolan.org/ for details) for the Sharp Zaurus
SL-5500 running ROM 3.13 (yes, it should also run on 2.38, and most
likely on 3.10 as well, although I didn't explicitely test it this
time). It is statically linked, so no additional installation of any
shared libraries should be needed. I did not compress the binary,
since the uclx decompressor creates a temporary file the size of the
original executable in /tmp while running a binary. This may not be
what everybody wants, so I decided to leave it uncompressed. If you
want to compress it yourself, feel free to do so :)

The configuration of this build includes ffmpeg (CVS 2006-05-19),
Tremor, mpeg2dec 0.4.0 (patched with Agawa Koji's excellent motion
compensation code for ARM), libtheora 1.0alpha5, FAAD2 (CVS
2006-05-26) beta, libmad 0.15.1b, liba52 0.7.5 (CVS 2005-03-16),
libdvbpsi (SVN 131 2006-05-26), speex 1.1.11, live.com's RTSP library
dated 2006-05-17 and who knows what else ;) -- so it should happily
play most things MPEG and OGG you can throw at it, provided the
parameters aren't beyond the computational power of an embedded
device.

Yes, it will also do live streaming of HTTP AAC, mp3 and Vorbis
sources, as well as playback of MPEG-4 RTSP live streams, as served
by, e.g. Apple's Darwin Streaming Server. A quick note: when playing
back HTTP streams, you may want to increase VLC's default cache to
something higher than its 2000ms default using the --http-caching
command line option.

This build NO LONGER SUPPORTS THE QTE VIDEO_OUTPUT MODULE mainly
because I don't really have any use for it and removing it allowed me
to get rid of GCC V2 for building the binary altogether. SHOULD YOU
NEED QTE VIDEO_OUTPUT for any reason, YOU WILL HAVE TO STAY WITH ONE
OF THE PREVIOUS BUILDS I did.

RTSP streaming should no longer produce those dreaded bus errors upon
startup like it did in the previous builds. This is most likely due to
the fact that GCC V2 is no longer used.

Sorry, no ipkg, you'll have to 'install' it yourself. Since it's just
one executable, that shouldn't be too hard. I have faith in you :)

As for limitations, well -- video playback is a CPU intensive process,
and with a regularly clocked Collie (i.e. SA1100 @ 206 MHz), the limit
will be somewhere around 320x240@15fps when doing MPEG-4 video and
audio. Less resolution will allow for a higher frame rate, and using
MPEG-2 Audio (i.e. 'mp3') instead of MPEG-4 audio ('aac') will save a
few CPU cycles as well. You'll have to figure out what combination of
file format and codecs will suit you best.

A note on OGG: it seems that at this point, Theora still isn't yet
available in a version optimized for StrongARM, so it performs rather
poorly -- at 320x240, 15 fps will not quite be reached. I haven't
performed a lot of testing, but my gut feeling is that the limit is
somewhere around 14 fps or so with it. Again, smaller resolutions will
work with higher frame rates.

I managed to get H.264 up and running as well, but the performance
situation is (obviously?) even worse here than for Theora. Collie will
run QCIF (176x144) H.264 MPEG-4 with lower bit rate AAC LC nicely at
15 fps. At this point, higher resolutions or frame rates will not play
back gracefully, giving the codec (IMHO) a very limited usability.
Then again H.264 does give the most bang for the bit, quality-wise. As
before, you have to make up your own mind as to what you like best.

Generally speaking, video output is performing marginally better using
the frame buffer video output module than in previous releases, which
can most likely be attributed to the better optimization achieved by
getting rid of GCC V2. Note that if you do run it under Qtopia, its
output _will_ interfere with video playback somewhat (more or less
annoyingly) and, of course, controlling the beast becomes virtually
impossible :)

Well, hope this helps.

Best regards,
Chris.
