Notices

2serge here is another fixed point codec
http://sourceforge.net/projects/zfaad
this one is for aac can you make use of it
thankyou

Thanks, but I'm trying to make mplayer work with gstreamer right now That would be probably the best solution. Now I'm getting familiar with gstreamer and testing some simple programs with it.

One problem that awaits ahead is that mplayer decodes video and audio in the same thread, so even if we make DSP decode audio, ARM core will stay idle waiting for results from DSP. Simulated that behaviour artificially slowing down video decoder by inserting empty loop to it until cpu usage has grown to about 85% and also adding a call to usleep in audio decoder (that simulates waiting results from DSP). So video ar audio gets played fine separately but not both at once. This issue also needs to be solved. Though DSP itself may be still faster than ARM for audio decoding and improve performance even in such scenario

Also reading these two links appears that ARM core is already used for mpeg1 in the default Nokia 770 player:
http://maemo.org/platform/docs/multi...hitecture.html
http://maemo.org/platform/docs/multi...g_started.html

But mplayer subjectively seems to be faster and skips less frames than default player on one of the *.mpg files from my collection with lots of action (320x240, 30 fps). So I wonder what is the problem? It could be worse compiler optimization options (no use of -mcpu=arm926ej-s), extra unnecessery scaling step in video decoding, gstreamer overhead, nonoptimal use of cpu cores in gstreamer (maybe it could be the same problem as with mplayer - one core is working, the other is idle and waiting for results). I don't know for sure, maybe Nokia developers can have a look and fix some bottleneck if it exists.

By the way, it is possible to use '-lavdopts gray' option to decode video in grayscale, it is a bit faster. Also for grayscale video probably we don't need color conversion at all (only one component Y - luminance is used), so we can make a special grayscale convertor and just set R=Y, G=Y, B=Y in this case. Not that I suggest you to watch grayscale video, but it can be used just like one more experiment to improve performance

As for the goal of all this thread, I see it as the following. We can't make Nokia 770 play any video file (there are H264 high resolution video files that are very hard to decode even for desktop PC). So we can try to make player tuned for some transcoded type of video and achieve the best quality with it. Scaling is bad as it requires cpu resources when decoding and also extra scaling step degrades image quality, so let's stick with 320x240 and 400x240 resolution doubled on playback. It is very desirable to keep natural video framerate, so the player should be able to smoothly play 30 fps video.

2fanoush: Thanks for link to DSP tools (though it looks like I need to be registered to get them), that would be probably fun to experiment with them Also as you are interested in color conversion, you can try to optimize this part of code. So looks like we have several options: check what videocontroller is capable of, try to make some use of DSP (from the links you provided, looks like YUV->RGB conversion involves many multiply and accumulate operations and DSP should be good at that), also it might be interesting to try getting the best possible performance with grayscale video decoding.

Now about my progress with getting audio decoded by DSP through gstreamer There is nothing to show at this moment (I mean no working mplayer build yet). Appears that Nokia 770 has 'dspmp3sink' gstreamer sink for playing mp3 data. It can't work as gstreamer source, so we can't transcode mp3 using it and are quite limited because of that. By the way, though dspmp3sing has license 'unknown', dspaacsink shows 'LGPL' license when running 'gst-inspect dspaacsink' (in order to use gst-inspect tool, you need to 'apt-get install gstreamer-tools' first). I wonder where we can get the sources? But nevertheless there seems to be a solution to use DSP audio decompression in mplayer anyway mplayer has hardware ac3 decompression for some soundcards (-ac hwac3), it is implemented as a hack to send compressed audio data chunks directly to audio card, see more details here. So we can use this one-way gstreamer sink. I have modified one of the gstreamer examples and now it can play mp3 by writing data to a socket, this crude hack is attached here. So we can treat this socket as such soundcard capable of decoding mp3 in hardware Implementation will involve parsing mp3 headers in mplayer code, splitting it into mp3 frames, but passing through without decompression. That all requires some work, but I'm quite optimistic MP3 format description is here: http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm

And maybe we should try to register a project at http://garage.maemo.org now?

There are other things that may be very handy:
1. Make a .deb package for mplayer at last
2. Make some gui for selecting files and launching mplayer (maybe porting something like freevo to maemo)
3. Try to build mplayer streaming server, it can be used for streaming video from desktop PC with seek support (sources in TOOLS/netstream), also it is interesting whether it could support transcoding video to format supported by Nokia 770 on the fly.
4. Rewrite some time critical mplayer code in assembler using armv5 edsp instructions.

Any volunteers to take some of these tasks?

Registered a project at https://garage.maemo.org/projects/mplayer/

Original MPlayer 1.0pre8 sources imported to SVN repository, all the maemo related patches cleaned up and committed. So SVN now contains MPlayer sources that can be cleanly compiled to build optimized and tweaked video player for maemo (and all the other architectures are most likely not broken, at least I tried not to break them).

I decided not to create traditional 'trunk' directory, but work with a directory 'MPlayer-1.0pre8'. As this project is only a set of patches against upstream mplayer sources, it seems that the most easy way to maintain that all would be to apply these patches to this directory. Once the next mplayer version gets released, it will get imported into some other directory (for example 'MPlayer-1.0pre9'), existing patches will be merged to it and all the development will get switched to this new directory.

If anybody wants to get commit access (or at least has some nice patch to apply), feel free to contact me

Usually the way to do this would be to have a trunk into which you import the 1.0pre8 sources. This is tagged as "tags/MPlayer-1.0pre8" (say) and then Maemo development happens on the trunk.

Once MPlayer-1.0pre9 is released, rename the current trunk to "tags/MPlayer-1.0pre8-maemo-final", create a new trunk and import the MPlayer-1.0pre9 sources into it. Tag this and then merge the changes made on the trunk between the 1.0pre8 tag and the rename.

2aflegg: Sounds reasonable, thanks for advice.

Out of not so idle curiosity, anyone deciphered:
http://www.maemo.org/platform/docs/m...g_started.html
To the point of getting mplayer to launch browser videos?

First initial experimental version of MPlayer which supports MP3 audio decoding using DSP core is ready: http://ufo2000.xcomufo.com/files/MPl...1-armel.tar.gz. Patch for original Mplayer 1.0pre8 sources is available from garage project page: https://garage.maemo.org/projects/mplayer/ (binary is not uploaded there because of 2MB upload limit).

In order to install the player, better unpack it to some place that is available in PATH, /usr/bin for example (yes, deb package is still not available).

This new DSP sound decoding feature is implemented by adding new gstreamer sound output module (ao_gst.c) which can be used to play either ordinary stream of sound data (for any decoders) or MP3 frames passed in uncompressed form using dspmp3 fake decoder module (ad_dspmp3.c).

Use 'mplayer -vo x11 -fs -ao gst -ac dspmp3 filename.avi' to get the best mplayer video playback performance at the moment. Remember that it is still experimental and surely contains bugs A known limitation is unavailability of volume control for gstreamer output module '-ao gst', it will be fixed later.

And finally some benchmarks:
time ./mplayer -ao gst -ac dspmp3 test.mp3
real 6m 14.91s
user 0m 6.95s
sys 0m 4.00s

time ./mplayer -ao esd -ac mad test.mp3
real 6m 14.07s
user 0m 51.60s
sys 0m 3.67s

So now ARM core definitely has more cycles free for video decoding

Works great, congratulations!

How can I double video size (you told about a 2x HW option). What about full screen?

.flv's downloaded from Youtube & Google Video are playable too (use this for downloading: http://javimoya.com/blog/youtube_en.php) !

Thanks Serge. you are great at figgering things out fast. iv noticed in a clip with one channel, the video apear to go at double speed. also will you be building a passthough codec for aac. I've notticed that gstreamer has an aac sink