Can you summarize the good reasons for using Xine for playback of non-HD video, when MPlayer could do it instead (or maybe it can't)?

Because Xine is doing it already? Why fix it if it's not broken?

My thoughts on the whole appliance/package separation effort is that right now I'd be happier to see development effort going into fixing all the annoying bugs and terrible GUI problems which make even simple operations almost impossible - e.g. girlfriend wants to find episode of Heroes called "5 years ago", or wants to watch an in progress recording - both of these things are actually quite difficult. The fact that under the hood a peice of code has been changed to be distro agnostic is at this stage in time wholly unimportant to me. I appreciate that is the goal, but surely that is the FINAL goal. In between we actually need to get the think to play TV/movies and do HA reliably and intuiively, which right now it doesn't really do.

Anyone agree?

I agree totally. The problem is that we have a community made up of people with a wide range of expectations for LinuxMCE. They range from the people who just want to code 'cool new' things... for the sake of well... 'coolness' (if there is such a word ;-) ) and dont use the system really that muxh to those at the other end of the spectrum who just want to use the system and want reliability and cleanup of what they expected LinuxMCE to be when they got started with it!

We need to keep both of these diverse groups happy and engaged with LinuxMCE... we need people at both ends of this spectrum. If we don't serve all these diverse needs we will become similar to a group of Master Woodworkers discussing the best way to 'sharpen' our tools or make a better join between two pieces of wood!

We probably need to organise things around releases so that the 'engineering' crowd here have a set of goals to aim for and a defined feature-set and path to travel along. Then there is a path which is focussed on delivering fixes etc and making sure the system delivers usable capability. Someone needs to become the 'product manager' for each of these and take charge of whats in and whats out. In the end you need someone to make the decision.

I've got a question on a related note with regards to xine/mplayer... why not make it an option like in mythtv.. where you can say files with extension .*** use mplayer and files with .*** use xine... give the end user the choice.... would that involve a great amount on coding?

because it's not that simple, different media players need to be used depending on both the type of media and the destination. In a properly designed system, the media players expose their capabilities, and the system makes the appropriate choice. This should not be deviated from, and would only cause reliability issues long term should such a feature be exposed.

because it's not that simple, different media players need to be used depending on both the type of media and the destination. In a properly designed system, the media players expose their capabilities, and the system makes the appropriate choice. This should not be deviated from, and would only cause reliability issues long term should such a feature be exposed.

-Thom

that would be fine with me... if the system determines the best player and automatically chooses it.. but my understanding is that in 7.10 mplayer is only used for HD playback... that's not going to help with video files that are SD but won't play in xine.. but would in mplayer..

I've nothing against Xine or Mplayer (and nothing special in favour of one of them)My concern as a user and as a semi-tech is pretty performance oriented.

To me it is not that important if my videos are played by Xine or Mplayer, but it is very important to get decent performance even without having to buy a core duo box for each MD.

From what I've seen many of us are oriented to use small factor MD (the majority of which are VIA based, like Fiire Station), and this sounds as a very reasonable choice to keep cost not too high and to keep the whole system appealing to general audience.

So the choice between Xine or Mplayer (and in general all choices, regardless of "appliance" vs "package" vs "distro" perspective) should be driven by this consideration first, i.e. performances against "normal" hw.

In the specific case of video playback, Xine_Player already gave proof to be a bit unefficient (if I launch Xine itself outside LMCE it consumes way less CPU compared as when launched from LMCE ).

My fear is that a lot of efforts have been made to write a MPlayer_Player wrapper and (I'd happy to be wrong..) no effort has made to improve Xine_Player, so in the end we have a more complicated system that can play HD content but still has some glitches playing simple stuff.

Exactly. Development effort is being watered out adding more features which only partly work, rather than getting the current software to work properly. Though if the community want this then there's no real sense arguing about it. I guess people are voting by deciding to code things like mplayer support!

There are immediate concerns to be dealt with in the abstract Media Plugin itself!

open the code, look at the base Media_Player.cpp ....

experienced OO coders will almost immediately see the problem:

there are tons of if statements leaking knowledge of the plugins below into the abstract code, and killing off encapsulation, thus making a tight locked dependency with the plugins below (this is especially evident with the HD-DVD code, that explicitly short circuits the entire process to force mplayer to be used.), this is very wrong, and should be rectified immediately. I would like to say this is an isolated incident, but there are bits of stuff like this all over the code, written by coders who try to bandage on functionality to suit their immediate need, without trying to understand how to do it properly! (I would also argue that stuff like this would be completely avoided in a dynamic, late-bound language, the polar opposite of C++, but still...)

We need to refactor, and we need to do it as soon as we re-sync 0710 with Pluto, or we're going to have severe migraine sized headaches later on as we start to add the very functionality that some of you are describing!

Design choices are valued by their results in feature performance. But I also look at the costs of delivering those features over the long term. So I'm interested in whether MPlayer can assume all Xine's functions, now that MPlayer is (seems to be) a complete superset of them, and MPlayer is a much more active independent development project than the fairly inactive Xine project. Since the "bet on MPlayer" decision has already produced a wrapper for MPlayer that seems to give it architectural interchangeability with Xine,

These are considerations about choices for developers (like me). I don't think LMCE should have choices between different media players (or similar kinds of choices) available to consumers, except maybe at installation time. And even then, it's probably better for consumers to select one completely separately packaged installer for one combo of components that are selected for one scenario rather than a few alternatives defined by other usage scenarios, rather than letting an installer give them choices that will most likely confuse them. Mostly because different packaged scenario combos is easier to develop than some AI installer .

If MPlayer is now actually interchangeable (with some reasonable quantity of straightforward porting), I'd like to investigate unifying the players into just MPlayer to factor and simplify that functionality. Especially because there are going to be more changes to the Media_Player API as more functions are integrated over time (eg. telephony functions in a UI while video plays, even videophone, or integrating videogames with other simultaneous A/V...). It'll be better for everyone if there's just a single media player to keep delivering those functions, rather than a stable of them, if that's possible.

Which is why I'm trying to find out whether Xine still offers any functions that MPlayer doesn't (the actual apps, not any possible fixable limits of their wrappers). If it does, and MPlayer is not really simply a superset of Xine functions, then there's no point trying to merge/factor them. But if there is, I'm interested. I don't expect anyone else to follow me, but if I do deliver a version factored to just MPlayer with all the functionality of Xine+MPlayer, then that's my own time wasted for everyone's benefit, right ? That's what drives OSS: mutual interest in each other's pet projects. Or just talk me into helping with your pet project, because it's more interesting than mine.

Why don't you spend some time, actually looking through the code... and seeing how the system, for example, routes messages for media.

The reasons why the architecture is like this, will surprise you, because even at this point all of the different media delivery software out there is designed for different audiences, and different needs....

it was easier, for example, to use vlc and vls for media streaming...but there are situations for example, that nbd needs to be used (for example, to expose a DVDCSS protected DVD to a media director on the other side of the house, that's in a jukebox not even connected to the system that's playing it!), the system decides...not the user...the best path through the network of devices, plugins, and players needed to accomplish a goal.... and I suggest spending a month or two, (I've spent much longer), studying the code itself...because otherwise, you're in way over your head.

Why don't you spend some time, actually looking through the code... and seeing how the system, for example, routes messages for media.

Well, that's worthwhile, though it won't really answer the question "what does Xine still do that MPlayer can't?" At least not nearly as effectively as getting some more experienced developers, like perhaps yourself, to dump to web pages how that stuff works, as any kind of guide.

The more I look at the project, the more it looks like the most productive help the community could get at this stage would be a note attached to every bug in Mantis indicating how the reported use case's critical path calls which series of code scopes, or at least which files, or at least which function is called by a GUI init. There are only a couple dozen block || crash || major bugs in Mantis, they've practically all got developers assigned to them. If each of those people just noted which files are (the most likely culprits) in the scope of the debuging task, then other people could help, and it would all be the best intro to the code.

If you want to kick it off, would you mind updating the Xine wiki page to mention the Xine_player wrapper, Media_player.cpp , whatever generates the Orbiter and Adminsite GUIs with controls that trigger Xine, the glue code from the GUIs to the Media_player.cpp ? Or at least just which code the GUIs call that eventually calls Media_player.cpp which then calls either Xine or MPlayer. This abstract discussion should be in terms of the code, and more veteran's time should be spent tipping off newcomers to which code, so we can work togther.

As another example, this Xine vs MPlayer redundancy looks like a similar redundancy/drift problem is polluting the code that rips CDs. There appears to be different code for ripping from an IDE CD-ROM than the code for ripping from a jukebox, different code for ripping multiple CDs or just a single CD from the jukebox. Some of those 3 use cases are properly using the target format configs, but the "rip multiple" is not. If the redundancies were factored out, that bug would be much easier to fix, if it appeared at all. Of course the code actually needed to accommodate single ripping for either IDE and jukebox might be one program, and multiple jukebox rip another, or more likely ripping IDE should be separate from single/multiple (with modes) jukebox, or probably the best is simply a single ripper that calls different HW as specified, wrapped in a loop. To say nothing of the factoring that would mean I don't have to set the rip target format in the Adminsite, then switch to the Orbiter to actually rip. I would be fixing (perhaps totally rewriting) that code right now (I already did something just like it for my old custom system), but my bug report hasn't even been touched.

The more I think about it, the more it seems this project would benefit most from people familiar with the code just walking through the bug reports and noting which files are the likely culprits for others to investigate.

The customer only cares if it does what it's supposed to do, the customer is NOT going to be selecting the media player, the software is!

FWIW, I specifically said the user shouldn't be picking the SW, so I don't think I'm missing the point at all. I'm just talking about simplifying the architecture so it doesn't support two redundant video players, just because a new one was added for its increased functionality without removing the other superfluous one. Which is a benefit to developers, who can then bring benefits to users.