[LINUX/MAC/WINDOWS] MPlayer porting to XBMC for Linux/Mac/Windows?

I think a start would be outputting with no scaling from both apps. This is "Original Size" mode on xbmc.

more detail plz

rarfs from xbox1

no kidding as the #1 warez video player on the planet; should embrace those that supported xbmc through the years. you may not agree with that statement but it is the truth.

hi,

I am getting confused more and more about what this thread is about. I'll try to summarize: some people ask for mplayer support in XBMC. The answer to this request is fuzzy (at least for me), there seems to be two directions:
1) there is no reason to do that, XBMC native player is as good (at least) as MPlayer;
2) there are technical issues, specifically about ld and -fPIC. Are there any others?


1) It seems that after all there are some differences which make MPlayer better (please see screenshots I attached in earlier post). We have to see how important they are, where they come from and if and how the gap can be covered. Because if there's no difference, why do we bother with point 2? Why did I spend a couple of hours taking screenshots, why is there a task (medium priority) of porting MPlayer to XBMC if it's no better than the native one?

2) We have to do something about it. I started getting involved in this thread by saying that I liked a lot XBMC, that it's the best (my opinion as an user) except the video player. Until you incorporate the best one, XBMC won't be the best.
Now, this task is medium priority. Is it that difficult to port it? Did anyone make a sizing and said "yes, it will take 5 man-month" and then (maybe another one) said "well, we cannot afford that because another 10 features won't be imlemented". If nobody made a sizing, why is that? If there is a sizing, how much work is it about?

Please help me clearly understand one thihng: is it all about resources, or is it (also) about politics? If it's the former, I'll try to carry on with my humble contribution. If it's the latter, I'll just stop posting on this thread and reconsider using XBMC.
Thanks to all of you for your support.

PS Perfect doesn't exist, but we can get close to it.

certainly not about politics.

HI I CANT USE MPLAYER ON XBMC ON LNIUX

no, just kidding. I'd like to offer a suggestion.

I think MPlayer support is REQUIRED, but should not be PREFERRED since DVDPlayer makes some good advances. To me, (i'm biased towards end-user) the project looks like it has taken a step backwards because it moved goal posts too far away with 'dvdplayer'. The quality of product the end users "sees" has suffered; it dropped about 10-20 codecs, some very common ones. I understand clean code is important too (respect to XBMC devs!) but this is an important area when considering the trade off. But I can only speak for myself when saying codec support trumps GUI integration. Any step taken in another direction lessens how much of a media player XBMC is, and makes the user more likely to use another product.

I request Mplayer support is escrowed to the operating system's package management, and XBMC simply calls binary if found in PATH when codec not supported in DVDPlayer/XBMC. Then XBMC can watch other streaming media codecs again!

It may then be possible to stipulate which media player core to use in a script like this:
xbmc.Player( xbmc.PLAYER_LINUX_MPLAYER ).play( rtsp_url, listitem )

What I'm proposing could be considered a duct tape solution. But if the proposal can offer more codecs by relying on another media player (if found in system) XBMC would be more useful to the average user. Many would be willing to compromise on XBMC GUI niceties to watch the odd .rm file they have lying around.

another idea; (last one!) mplayer can play in root X11 server window. could a nested X server be used for mplayer and XBMC GUI details overlaid on this? Could a new video output driver for mplayer be created? -vo xbmc_core?

Hi,

I have just installed and tested XBMC (windows). That's an amazing work (especially the UI and the scrappers !).
However (and that's what bring me to this thread), there are a few points which prevent me to use XBMC (unlike some mplayer-based distrib like GeexBox) :

- The inability to load subtitles within an MKV container.
- The inability to read RV9 encoded movies (although throughout posts it seemed to me that some users succeeded, it never worked for any of my vids)

Why is that a deal-breaker for me ?
My mother tongue is not English, and I like to watch my movies in English with subtitles while keeping the possibility for my entourage to watch them in native language if they prefer. So 90% of my movies are MKV. And most of the good releases in this container format contain RV9 encoded video.

So when I view posts of people saying that dvdplayer is at least as good as mplayer , I need to disagree. For those who ask for what should be added to dvdplayer, I think I'm not the only one to think that the two points above are important.

I hope they will be supported in the near future (or that user on windows version could choose his default player), as it's heart-breaking for me to leave XBMC aside after having used it !

Thanks again for your work.

Hi. I've been using MythTv and Geexbox for while and than I found XBMC. After grabbing some info about it I've decided to try it. I removed MythTv from my PC and installed Ubuntu 8.10 + Atlantis 8.10. I just fall in love with the clean and beatiful GUI and the scrapers are AMAZING.

But besides of all of this, today I am returning to GeexBox because dvdplayer can play only 10% of my video collection. All the other 90% I got frame drops and audio sync issues (CPU is below 20%) because somehow the dvdplayers codecs can't correctly decode my videos. Mplayer play all perfect.

I wish there were some way to use XBMC GUI and scrappers with mplayer as backend. It would be a dream.

I know that must be a lot of difficults to integrate both, but I simple way to call my system mplayer passing the movie as parameter would already be better then falling back to geexbox/mythtv IMO.

Thanks

we already have that - search for 'external player'