mplayer_1.0rc1-maemo.21/22 (and OS2008 support)
 

A new build of mplayer has been released. Here is the list of changes since mplayer_1.0rc1-maemo.18 (a previous public release):
New release has been uploaded to maemo extras devel repository with the goal to move packages to normal extras repository later once they can be considered stable enough. You can add extras devel repository information to your application manager in the following way:

Nokia 770 (OS2006):
Catalogue name: testing maemo Extras
Web address: http://repository.maemo.org/extras-devel
Distribution: gregale
Components: free non-free

Nokia N800 (OS2007):
Catalogue name: testing maemo Extras
Web address: http://repository.maemo.org/extras-devel
Distribution: bora
Components: free non-free

Nokia N800/N810 (OS2008):
Catalogue name: testing maemo Extras
Web address: http://repository.maemo.org/extras-devel
Distribution: chinook
Components: free non-free

A big warning: Repository extras-devel is expected to be full of untested and broken versions of various software, so be carefull when using it. You can enable this repository, install mplayer and then disable it again. If you upgrade all the software to more recent versions from extras-devel repository, you have a (small) chance to break your system. If you want to test new experimental versions of various software (the last build of mplayer is an example of such experimental version) that's fine. Otherwise you need to be very careful using extras-devel repository and upgrade only the applications you really want to try, keeping all the rest of software at stable versions.

Alternatively you can manually download deb packages from:
http://repository.maemo.org/extras-d...ree/m/mplayer/ (OS2006)
http://repository.maemo.org/extras-d...ree/m/mplayer/ (OS2007)
http://repository.maemo.org/extras-d...ree/m/mplayer/ (OS2008)

OS2007HE is not officially supported (bora package has N800/N810 cpu specific optimizations and will not run on Nokia 770), but you can try a package for OS2006 as usual.

Package for OS2008 is still not quite stable, it needs more testing and bugfixes. But packages for OS2006 and OS2007 should be good enough. MPlayer should become somewhat faster with this release, especially on Nokia 770.

Re: mplayer_1.0rc1-maemo.21
 

Only tested a couple videos, but it's looking great so far on my N800 with OS2008.

Thanks!

Re: mplayer_1.0rc1-maemo.21
 

Works like a charm :)

Re: mplayer_1.0rc1-maemo.21
 

Hey !!! Great job ! This new version is faster on my n800 on it2008 than the previous for it2007.

Faster read ... no lag anymore on my vids ... fast forward / reward

Re: mplayer_1.0rc1-maemo.21
 

I downloaded an XviD video. "file" on my Mac says it is:

RIFF (little-endian) data, AVI, 624 x 352, 23.98 fps, video: XviD, audio: MPEG-1 Layer 3 (stereo, 48000 Hz)

that's quite a big video for a tablet (349Mb!).
The internal video player is able to show it, but not viewable at all.
It was really choppy, part of the video frames were missing and audio choppy as well.
I thought, well.. it's a 400Mhz processor, what'd you expect ?

But now I tried the very same video with Mplayer.. well.. .stunning.
Literally stunning.
The video plays just fine.
And I mean it.

Great work.

Re: mplayer_1.0rc1-maemo.21
 

I have one problem with .21 on OS2007/N800: if I try to change the OSD level in the menu, mplayer stops playing! The same video with .18 played without a problem.
If I use xterm, after some time the error is displayed:
"GLIB ERROR ** GLib - gmem.c:135: failed to allocate 147456 bytes
aborting..."

Re: mplayer_1.0rc1-maemo.21
 

.21 is failing for me on a file that .18 played perfectly. It is a TMPGEnc DiVX encoding of a Quicktime .MOV video.

i am happy to mail it to the developer if it helps, file size 4mb.

Re: mplayer_1.0rc1-maemo.21
 

I try play video file was made by Nokia Video converter. Not played.
The .18 also more perfect for my. .21 is failing sound of many my files

Re: mplayer_1.0rc1-maemo.21
 

Did OSD work with .18? Does this file fail to play with .21 if you don't touch OSD level settings?

To gLobster, Rebski: please also add device type information and OS version to your reports. I assume it is OS2007 with N800? It is particularly interesting as OS2007 build should be quite stable.

OS2008 build has problems with sound on some files because of a cumulative effect of these two problems together:
https://garage.maemo.org/tracker/ind...id=54&atid=269
https://garage.maemo.org/tracker/ind...id=54&atid=269

A solution for the sound problem is underway and the next OS2008 build should have it fixed.

Re: mplayer_1.0rc1-maemo.21
 

OS2008/N800 in my case

Re: mplayer_1.0rc1-maemo.21
 

The two files I tried played fine with both .18 and .21, and the OSD level selection worked in .18 without any problems.
Here the whole error-message:

Re: mplayer_1.0rc1-maemo.21
 

Serge

I am sorry, OS2008/N800, there is a similar thread on the 2008 OS Forum and I forgot that I was posting elsewhere.

My particular issue relates to the sound and I look forward to future releases.

Thanks for all the great work.

Re: mplayer_1.0rc1-maemo.21
 

The output from ITVC are MP4 files, rather than DivX/Xvid. Perhaps Serge could comment on how well these are expected to work? I suspect the target for the ITVC authors was the built-in Media Player.

Re: mplayer_1.0rc1-maemo.21
 

Thank you very much for reporting. It turned out that -O3 optimization setting triggers compiler bug. Build .18 used -O2 optimization (as it was benchmarked to be faster at that time). Build .21 had optimization settings changed (back) to -O3 as motion compensation code was optimized for size and -O3 started providing positive performance effect. But if we take OSD bug into account, -O2 is clearly the winner now. The next build most likely will have working OSD. But changing optimization option still does not help with #763

I wonder how I missed this optimization option when I was analyzing bug #254, I'm almost sure I tried different optimization settings at that time. Well, nevermind, let's hope it will not show up again :)

With this additional details, it should be possible (though it can take a lot of time) to pinpoint the problem and find the problematic part of code by splitting code into pieces and compiling them with different optimization options. But I wonder if gcc developers or anyone else is interested in a bugreport against old version of gcc when more recent gcc seems to be ok?

This message is generated by gstreamer after it was not feeded with get audio data in time. This problem is a consequence of mplayer deadlock, but not its cause.

Re: mplayer_1.0rc1-maemo.21
 

I think the problem here is the audio format being used by ITVC - AAC - isn't well supported by mplayer (see this post). :(

Re: mplayer_1.0rc1-maemo.21
 

Perhaps an opportunity for someone to implement a similar link to the DSP codec for AAC as Serge did for MP3.

Serge's MP3 link code is available as is the ARM-side gstreamer dsksink code for both MP3 and AAC.

Re: mplayer_1.0rc1-maemo.21
 

Just a short notice as I don't have much time at the moment: a new release mplayer_1.0rc1-maemo.22 has been uploaded to extras-devel repository. It fixes (most of) the issues reported here. I'll provide more information a bit later and will reply to some posts. Thanks to everyone who is taking part in testing these new mplayer releases, your feedback is very much appreciated.

Re: mplayer_1.0rc1-maemo.21
 

From a newbie...

I tried to update from the application manager and it told me that it needs some packages from other sources... then I tried to install the new release (22) manually from the .deb file and it tells me that it needs:

libmad0 (>=0.15.1b)
libogg0 (>=1.1.3)
libtheora0

I also tried hunting for these files from the repository but can't install them because it says something like is not meant for 2008.

What am I doing wrong?

Thanks...

Re: mplayer_1.0rc1-maemo.21
 

Sounds strange. I uploaded mplayer and libraries to all -devel repositories.
Which repository did you use?

Re: mplayer_1.0rc1-maemo.21
 

OS2008/N800
Wow, that was quick! I updated to .22 today and the sound issue on that particular file is fixed.

Not only that but the video aspect plays better then even. I had attributed its previous slight motion hesitation to an encoding glitch but it is completely cleared up now.

Thank you.

Re: mplayer_1.0rc1-maemo.21
 

This one:

Nokia N800/N810 (OS2008):
Catalogue name: testing maemo Extras
Web address: http://repository.maemo.org/extras-devel
Distribution: chinook
Components: free non-free

Re: mplayer_1.0rc1-maemo.21
 

How you did your upgrade? Manually or using Application Manager? Which repository did you use?

Re: mplayer_1.0rc1-maemo.21
 

Try to update your repository list. It should help.

Unfortunately I don't have tablet with me at the moment, but I tried to install mplayer in scratchbox armel target and it worked just fine.
It means that all needed libraries are in repository.

Re: mplayer_1.0rc1-maemo.21
 

Well I did update my repository but I got the same problem.

I've found a solution:

Uninstall .21... install .22 from the repository.

Everything is working well now.

Thanks!

Re: mplayer_1.0rc1-maemo.21
 

I updated Application Manager and it was there.

Re: mplayer_1.0rc1-maemo.21
 

After installing libmad0 (wasn't needed before) and rebooting (without rebooting the screen dimed during playback) .22 works (with my videos) perfect on OS2007. :) Thanks Serge!

Re: mplayer_1.0rc1-maemo.21
 

We're getting "there" aren't we? :D

Re: mplayer_1.0rc1-maemo.21
 

I'm having the same problem trying to install from the 2006 distro on my 770, but I don't even see mplayer in my application catalog, so I tried to install the .deb file.

Re: mplayer_1.0rc1-maemo.21
 

Ok scratch this, i uninstalled the old mplayer, updated the catalog and installed the new mplayer. Seems to work now.

Re: mplayer_1.0rc1-maemo.21
 

Hi there, I updated to 1.0rc1-maemo.22.n8x0 today and now my audio is out of sync with video. I'm running 2008 on a N800.

I'd tell you what version I upgraded from, but I cannot find the apt log. Does anyone know where it lives? There's nothing at all in /var/log...

Thanks Evan.

Edit: I forgot to add that the standard media player plays these videos fine.

Re: mplayer_1.0rc1-maemo.21
 

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'.

Re: mplayer_1.0rc1-maemo.21
 

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.

Re: mplayer_1.0rc1-maemo.21
 

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

Re: mplayer_1.0rc1-maemo.21
 

start mplayer with -idx in xterm fix my sync error

Re: mplayer_1.0rc1-maemo.21
 

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

Re: mplayer_1.0rc1-maemo.21
 

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

Re: mplayer_1.0rc1-maemo.21
 

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.

Re: mplayer_1.0rc1-maemo.21
 

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.

Re: mplayer_1.0rc1-maemo.21
 

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.

Re: mplayer_1.0rc1-maemo.21
 

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?