Notices

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

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?

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"?

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

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?

we need update versions 27 28....


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

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)".

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

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

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

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

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.