Re: mplayer_1.0rc1-maemo.25
 

WMV is another rc2 reason :) rc1 WMV native support is very limited.

Re: mplayer_1.0rc1-maemo.25
 

I've also been having trouble with my converted video files playing extremely sluggishly (as if in slow-motion) and with a bad stutter in the latest update of mPlayer.

I decided to try some of my raw mpegs (i.e., the original file before I converted them), and they seem to work fine in mplayer. I use Kontorri's Media Converter utilizing the "Super High Quality optimized for MPlayer" setting for converting my videos. If the raw videos play fine, could something having to do with the conversion process possibly be a cause for some of the reports of sluggishness that some people are reporting?

Re: mplayer_1.0rc1-maemo.25
 

I have tried and tried to figure this statement out. But, I finally decided to admit that I don't know what this means. What's this about "rc2" vs. "rc1"?

Re: mplayer_1.0rc1-maemo.25
 

rc = release candidate (wikipedia: release candidate)
serge's mplayer version is based on mplayer release candidate 1. The latest (non cvs) version is rc2.

Re: mplayer_1.0rc1-maemo.25
 

Ok, so Bundyo is suggesting that Serge move to the (upstream version) rc2 mplayer. From the use of "another" in Bundyo's post, it sounds like rc2 has been suggested before.

Are the Maemo / ARM optimizations changes being added to the main mplayer project? Is it difficult to move the Maemo-specific portions to rc2? Is Serge the only dev on this project?

What about the "binary codecs" I've heard about? Is there any way to bring them into maemo?

Re: mplayer_1.0rc1-maemo.25
 

we need update versions 27 28....


mp4 veido files still have some crashes (stop) for playing :(

Re: mplayer_1.0rc1-maemo.25
 

I'm sorry, but this problem description is not very informative. At least having mplayer log would help a bit. And please describe what happens when it "crashes (stop)".

Re: mplayer_1.0rc1-maemo.25
 

It's a bit more complicated, as Bundyo tested SVN snapshot which is even more recent than rc2 :) And that "another" reason is DVB support: https://garage.maemo.org/forum/forum...7&forum_id=170

Yes, but but this process is slow. Some optimizations are already in upstream project, some are still in maemo version only.

Both no and yes. It will take about one evening to update all the patches and apply them to rc2 upsteam sources. But then it will take a bit more time to find and fix all the possible regressions (there is a fair possibility that we will have some regressions).

I mostly do decoding and video/audio output optimizations only. GUI frontend and debian packaging stuff has been contributed by other developers (see changelog).

You probably heared about binary x86 codecs from windows operating system. A special adaptor loader code exists in mplayer to use these codecs, but it works only on x86 systems. Binary codecs for x86 will not work on ARM (and even theoretically emulation is out of the question for peformance reasons). I don't know, maybe some binary codecs exist for Windows Mobile ARM systems, but I have completely no interest/motivation to even do some basic research regarding this matter.

By the way, dspmp3 audio codec is a proprietary binary codec too, so we actually do have some kind of "binary codecs" support :)

Re: mplayer_1.0rc1-maemo.25
 

If you need a beta tester, I'm your man!

Sounds like you're in charge of the stuff that I really care about. :D

The reason wmv video (and other formats) has suddenly become important to me is that Pipeline has managed to shim the Maemo mime system so that mplayer plays various forms of streaming video right from the browser, and any video file type I want, right from the file manager.

Pipeline's latest dbus-switchboard

Re: mplayer_1.0rc1-maemo.25
 

Serge, wondered if v4l support was coming any time soon, possibly in conjunction with the rc2 change?
I saw a custom build over here to get a webcam working, and there's some interest in getting a TV-in device working, where it would also be helpful.

Re: mplayer_1.0rc1-maemo.25
 

Yes, I just updated from 24 to 26 and am seeing exactly the same thing. Which might not be a useful comment without further details, but I'm not sure what more to say...

Adding to my own message... after reading the bug report discussion in garage - editing ~/.mplayer/config to contain "ao=esd", makes these files play perfectly.

Re: mplayer_1.0rc1-maemo.25
 

yes i have this (my converted video files playing extremely sluggishly (as if in slow-motion) ) problem with my mp4 files

i updated to 25 and 26 but the problem is still available!

can u fix this too?

edit: by the way i have in my mplayer.conf : ao=gst,esd,sdl

????

Re: mplayer_1.0rc1-maemo.25
 

Thanks for the tip, gtallan & itolodance,

ao=gst,esd,sdl

fixed the problem.

Re: mplayer_1.0rc1-maemo.25
 

Even so .24 gives better quality than .26.
With .26 I could not play mp4 files smoothly but with .24 everything is ok.

Re: mplayer_1.0rc1-maemo.25
 

STRANGE? my tablet is n800 os2008

and 24 is very slowly for play mp4 video files and 26 is better (but still slow on some screens)

Re: mplayer_1.0rc1-maemo.25
 

Serge,i think mplayer is not beighness....infact i tested 1 video file on mplayer and media player

and media player was perfect for brightness

is there a way on mplayer.conf for edit brightness???

Re: mplayer_1.0rc1-maemo.25
 

Serge Mplayer can't read good DIVX/XVID 640x352 and i need to rencode the size for about below 550x340

please can create mplayer that can read the original size (6**x3** ) of divx movies files?

please reply

thank u

Re: mplayer_1.0rc1-maemo.25
 

Serge another request! sorry but we want to make mplayer better than past,hope all these questions/problems Will fix in the future and for mplayer 27


well we know mplayer can read subtitles srt idx sub ssb..........

mplayer can read all languages with idx and sub

but what about srt? well i want to see farsi (persian),what i can do? i need a script or only an official debian font for this?

possible and can u add language for srt files?????


i love mplayer veryyyyyyyyy much :)

Re: mplayer_1.0rc1-maemo.25
 

Maybe a bug?

Hello, Mr. Serge. I just noticed something in the latest build of mplayer.

I changed the config file located in home/user/.mplayer in order to include the "subfont-encoding=ISO-8859-7" option, as i wanted to properly display external subtitles files of the greek language.

But, the outcome wasn't as expected. The subtitles weren't displayed properly. Instead of ISO-8859-7, i also checked CP1253, but they didn't get any better. They show different (i mean with less symbols like !@$#>?:") from the default Unicode encoding, but still very far from what is normal.

I have used the above two options with success in the desktop edition of mplayer (and VLC), so why not with the maemo version?

Moreover, if i remember well, the "subfont-encoding=ISO-8859-7" option, used to work back at .24 mplayer version.

Later, i am going to uninstall mplayer, and start with .24 again to see if that really happens.

But, is it really a bug?

Anyone noticed someting similar with other subfont- encoding options?

Am i doing something wrong?

Should it be reported in the bug tracker?

Re: mplayer_1.0rc1-maemo.25
 

Well, i can confirm now that this subtitles problem doesn't appear at previous versions.

I tested both .24 and .25 from here http://repository.maemo.org/extras-d...ree/m/mplayer/ and everything went well - the subtitles were properly displayed.

I even reinstalled .26 but the behavior described in the above post still remains the same.

I used the subfont-encoding for the greek charset but i think others can easily check it out for other languages.

To sum up, that's a regression. Should we report it in the bug tracker?

Re: mplayer_1.0rc1-maemo.25
 

ok i solved this problem,download free tool: http://www.softpedia.com/get/Multime...t2VobSub.shtml

it can convert all srt files with all languages to idx/sub then ready for mplayer :D

hope this can help to many friends from different countries & Languages here :o

Re: mplayer_1.0rc1-maemo.25
 

It helps. Thanks a lot! :D

When subfont-encoding option is fixed, there would be no need for conversions hopefully.