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.
but again, you're missing the point...
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.
