Notices

My guess is that you looked into wrong place in App Manager. If previous version of mplayer is installed you should be looking in 'Check for updates' section, but you most probably looked into 'Browse installable applications'.

I'm also having sync problems with 1.0rc1-maemo.22.n8x0 on the N800 with OS2008. I've gone back to 1.0rc1-maemo.21.n8x0.

Yep, I'm getting the same sync errors with my avi's/flv's etc.

Switched back to 1.0rc1-maemo.21.n8x0 as well

I'm also using the latest offical OS2008 Beta firmware as well.

Cheers
Rip

start mplayer with -idx in xterm fix my sync error

Does the OS2008 version of mplayer for the N800 support ALSA for A2DP?

This kind of audio sync problem (fixable with -idx option) could be introduced by problems with transcoding: http://www.internettablettalk.com/fo...ad.php?t=12249

Well, theoretically ALSA should be supported there (configure script is explicitly feeded with '--enable-alsa' option), but looks like something was lost when tweaking build system for OS2008 support and 'extras devel' repository. Probably Ed_ can have a look at this issue and try to solve it. By the way, he should be credited for doing all the work building OS2006/OS2007/OS2008 mplayer packages, doing initial testing and uploading releasesto repositories.

That's not so simple (if implemented in the same was as MP3 support). Right now dspmp3 'decoder' performs bitstream parsing on ARM side and is able to identify individual mp3 frames. That is done in order to always know current position in the bitstream for proper timing and synchronization with video. So dspmp3 knows and also processes MP3 bitstream format but just skips decoding step (bitstream parsing, decoding and playback is done on DSP). If we want to implement AAC support in the same way, AAC bitstream parser should be also implemented as part of some new 'dspaac' pass-through decoder.

Maybe it is possible to avoid bitstream parsing completely and still provide proper audio/video synchronization, but I don't feel like investing any efforts into this at the moment. After all, this code would just increase reliance on proprietary binary only blobs And this stuff (gstreamer sound output hack in mplayer) gets less reliable with each new release of IT OS, see mplayer bug #1273

In addition, OS2008 (at least the initial leaked firmware which could be considered unofficial beta ) works much more efficient with MP3 audio decoded on ARM core (so it uses libmad decoder in .22 release on OS2008). That may sound counterintuitive, but there is an explanation. ARM core clock frequency drops to 330MHz when using dspmp3 task for decoding MP3 audio. So we lose 70MHz on ARM core as a price. On the other hand, decoding MP3 audio on ARM takes only about ~40MHz of ARM cpu resources on average. So just not touching DSP at all, results in overall performance improvement. The question is whether ARM core clock could stay at 400MHz with DSP running at 133MHz when decoding MP3 audio? The following post suggests that not all dsp tasks require running DSP at full speed: http://www.internettablettalk.com/fo...0&postcount=18

Anyway, using DSP for MP3 audio was a good and useful trick on Nokia 770 and OS2006, but right now everything is reversed for N800 and OS2008

Now getting back to AAC audio. It would make a lot of sense to get an efficient fixed point AAC decoder optimized for ARM added to mplayer. AFAIK, right now both AAC and H264 generally don't have any special ARM optimizations in mplayer/ffmpeg. So losing to standard OS2008 media player in this respect would not be very surprising.

Here is the changelog for .22 release:
It had a fix/workaround for OSD deadlock reported by Nikem. One more important issue that got somewhat solved is mplayer bug #1270. If you try to download and play ftp://upload.mplayerhq.hu/MPlayer/sa...rate-atmos.avi sample using standard ffmp3 decoder (default fixed point mp3 decoder from mplayer/ffmpeg), you will see severe problems with this file. The same problem existed in dspmp3 decoder some time ago, but it is now solved. Nobody encounters this bug on desktop version of mplayer as it uses a different decoder there by default (floating point implementation). If you try to play this video sample on desktop PC using x86 mplayer and specify ffmp3 decoder (using '-ac ffmp3' option), you will easily see this problem too. An alternative fixed point decoder usable on ARM is libmad. It behaves much better on this Coyote clip, but has its own drawback - audio/video sync problems for variable bitrate audio (a similar problem was also found and fixed in dspmp3 decoder some time ago).

I have reported the problem with fixed point mp3 decoders in mplayer developers mailing list in September:
http://lists.mplayerhq.hu/pipermail/...er/053920.html
The mplayer developers suggested to use ffmpeg demuxer instead of old demuxer from mplayer (enabled with '-demuxer lavf' command line option). It indeed fixes the problem with Coyote video clip and alows to use ffmp3 decoder. Anyway, I was warned that lavf demuxer while being newer and better is still not very well tested. And a regression really showed up: lavf demuxer has problems with playing video streamed from http server.

So what is the solution? I hope to fix libmad support code in mplayer to solve this audio/video sync issue for the next maemo mplayer build. At the same time, it makes sense reporting http streaming problems with lavf demuxer upstream.

PS. libmad and ffmp3 performance is more or less equal on N800.

Thank you for your great work on mplayer, serge.

I noticed a problem with N800 (OS2008) and the new mplayer builds: mplayer doesn't remember the volume setting. Mplayer starts everytime with 100% volume, regardless of the last entered volume level...
Is this a known issue or a new feature?