mplayer_1.0rc1-maemo.27
 

A new release of mplayer_1.0rc1-maemo.27 has been uploaded to extras-devel repository.
If no regressions are reported within a reasonable time, it will be moved to 'extras' repository. If we get some important regressions reported, there will be subsequent releases in 'extras-devel' repository (and announced in this thread) until the quality is good enough.

Please be sure to report the problems you encounter, don't think that they will magically fixed themselves before getting promoted to stable status and get to 'extras'. The previous release .26 showed that in spite of being tested at garage extras-devel repository for a long time, serious bugs still slipped in and were discovered only after putting that release to 'extras'. This might be an indication that we can't rely too much on the community testing in 'extras-devel' repository. It surely helps, but apparently is not enough to ensure good quality.

If we did not have the urgent need to fix bugs, this release should have been an upgrade to upstream rc2 version.

Below are the links to .deb files (they can be only used to upgrade mplayer from any version since .24, fresh install will fail with missing dependencies) if you don't want to enable 'extras-devel' repository on your device:
OS2006: http://repository.maemo.org/extras-d...ree/m/mplayer/
OS2008 (does not work on OS2008HE!): http://repository.maemo.org/extras-d...ree/m/mplayer/

Support for OS2007 is going to be dropped as having too many OS versions to support just takes extra time. Please let me know if somebody is still seriously interested in OS2007.

Nokia N800/N810 users: This version has some performance improvements in AAC audio decoding support. It means that .mp4 files should play a bit better than before. If it still does not support .mp4 files good enough, that's not a bug, but an indication that more efforts still need to be put into optimizations.

Nokia 770 users: This version supports automatic detection of tearsync & yuv420 video mode support in recent 770 kernels from fanoush and anables these features without the need to edit any config files. A potential pitfall here is that some early SDHC kernels falsely reported availability of tearsync support, but in fact that code was not ready yet. If you encounter device deadlock and reboot on trying to play video in mplayer, please consider upgrading the kernel. The users of stock Nokia kernel are unaffected and mplayer will just work the same as before (that means without these cool features :) ).

Re: mplayer_1.0rc1-maemo.27
 

well i installed it and couldn't find any change with older versions

mp4 converted files by Internet Tablet Video Converter are still slow

mplayer 25 is still better than others on my os2008

video playback is cool faster for 27

Re: mplayer_1.0rc1-maemo.27
 

I have written at the previous thread:

and then came the test:

I just installed the .27 version, but subfont-encoding still doesn't work properly. So, that's a regression.

One more thing: does mplayer use software mixer or hardware?

I am wondering, because i want to use −softvol option in order to boost low volume files, but i don't know if the performance will be worse due to the dependence on software amplification rather than hardware.

Anyone who knows? Thanks in advance!

Re: mplayer_1.0rc1-maemo.27
 

I really hope the big bugs get squashed in this version. The official move to rc2 is really an exciting thing to look forward to. Any possibility that the mplayer team could make an official build of mencoder (with lame MP3 and v4l2 support), too? As a separate package, of course...

Re: mplayer_1.0rc1-maemo.27
 

I installed .27 (replacing .26) on my N800.

Transcoded video (*.avi files) no longer play when mplayer is launched in embedded mode from Canola (beta8). After a couple seconds, the screen darkens (in "I'm going to sleep" mode), and the on-screen Canola buttons become completely inactive.

oh, nevermind.

Re: mplayer_1.0rc1-maemo.27
 

Same here, Canola no longer will play xvid or avi's exact problem as briand wrote about, same videos will play fine when opened with Mplayer, so is this a Canola issue or Mplayer ?

Edit: downgraded to v.26 and videos still won't play in Canola.

Re: mplayer_1.0rc1-maemo.27
 

had issues with video playback in canola and kmplayer.
if you installed the screen rotate stuff.
then that might be the cause of it.
just upgrade the new kernel that is made available on the screen rotate maemo site.
should work after that.

http://sse2.net/rotate/

Re: mplayer_1.0rc1-maemo.27
 

Thanks Unique311, over on the Canola thread briand helped me out, I had to re-scan my media folders then it worked ok again.

Re: mplayer_1.0rc1-maemo.27
 

Playing audio files from the command line is now fine. But I still have the following problem with gmplauncher (I don't know if it is a known bug): once I start to play an ogg file (on the internal memory card), gmplauncher doesn't react until the end of the ogg file. When gmplauncher is run from a shell, I get the following message only:

gmplauncher[10199]: GLIB DEBUG ConIc - con_ic_connection_send_event(0x8b938, Vinc17, WLAN_INFRA, 0)

Re: mplayer_1.0rc1-maemo.27
 

Serge, I've been doing some experimentation and i've noticed that when i launch an xvid with :
mplayer filename.avi it will play i little slower than when i play through gmplauncher.
when i launch it with :
mplayer filename.avi > /dev/null (i think thats right command) it plays comparably to when launching with mplayer

If statistics make a noticable difference, is there an official command line option to disable them from being sent in the first place? Or would that require modifying each codec?

Also i noticed something weird... if i launch a 1080kbps xvid (with mp3 48000hz, 2ch) with no video using :
mplayer -vo null filename.avi > /dev/null uses up 100% of cpu most of the time...

That same xvid, launching without audio :
mplayer -nosound filename.avi > /dev/null can play high quality video essentially flawless... but also uses 100% of cpu

Although the video is a bit smoother, its not double the performance... and yet the cpu utilization (using load-applet in status bar) is virtually identical when running audio only, video only, or both.

Could the realtime statistics generated by mplayer/codecs be sucking up the extra free cpu time? Even though i redirect it to /dev/null the cpu has to sling those statics around right?