MPlayer development thread

Continuing from this thread.

@abalaban

Quote:
Ok, that's good news. I'm ATM waiting for the password retrieval email for my Google account.

Quote:
If I have understood well, you'd create two source trees, one with the official sources Afx worked on, the other one with a verbatim copy of afx' sources, is this correct?

Varthall

@Varthall

In a sense yes, but not really. In fact SVN (or CVS, and any other revision control software) can work on what is called 'branches'.
A branch is some sort of fork of the whole source tree in which you can do changes without perturbing the base source tree. The good thing in revision control softs is that they keep track of any changes done between two distinct revisions (not necessarily two immediate following ones, there can be any number of revisions in the between). Add to this the ability to merge changes into a given revision and you have the perfect way to handle forked projects (which in the end is our version of MPlayer). At first it seems dangerous or even risky but finally it proves to work really good and when you are used to revision control systems you don't want to work without anymore. Those notions might need a little more in depth learning, I can advise you partialy read the PDF book that is included in the Subversion archive (called "The Read bean book") you might learn some interesting things. Don't focus on the details at first just look at the main notions: command line and details can be learned at the time they are required, no need to get afraid by the ton of possibilities such kind of softwares are offering.

So basically I would import official MPlayer sources (corresponding to the one the actual AfxGroup's ones are based upon, not necessarily the latest (this is very important)) into a branch (let's called it 'Official') then I would put it into the trunk, then I would check out a working copy, replace all files by the one from the AfxGroup's one and commit the result. At this point we can already know which files were modified for our version and where. After that it's easy to update to latest official version it's only a matter of importing into the 'Official' branch latest files, then merging changes that occurred between this new revision and the previous one into the trunk (possibly resolving some conflicts).

We can discuss this privately or here if other people are interested in following/learning the process with more details. I would only states that I'm more experienced with CVS's branching/merging process than with Subversion's one but the concepts are there.

@abalaban

Quote:

/me raises hand

Interested

I wpuld suggest you to work in this way:

1) check out the official svn and search for all already present __amigaos4__ define

2) search all __amigaos4__ define and patch the official svn trunk updating it.

Don't expect to merge two trunk into one except if you send patches (written in a mplayer developer way...) to the official developers..

@afxgroup

Why ? I don't see the problem. If they don't want our patches what is preventing us from doing it locally. Having a dedicated branch for the official sources tree and updating it from time to time to merge the changes into the trunk is easy...

@abalaban

I merge MPlayer regularly. The os-dependant API (libvo, libao, dvdcss, gui, ...) is relatively stable, so the merge process is generally not much trouble. I generally need half a day or so to update to a newer MPlayer revision and compile it, if there are no major conflicts or changes.

Now, i seriously wonder why you all want to fork MPlayer when another amiga-like version with full GUI support already exists (and has been ported almost as-is for AROS too). But up to you, i guess. :)

@afxgroup

What is the problem with the MP devs not wanting amigaos4 patches?

Formatting?
Or is it something else?

@Fab
@abalaban
@Varthall
@afxgroup

Yeah, why not join forces (if it's easier than a complete reboot)?

@Fab

indeed.. i never tried to port your version due a lack of the time.. and i was thinking that you was using MUI4 features..
But if you assure us that AROS version is a quick port from your version, why don't merge all three versions into one?
In the latest version i've compiled (that one that all developers now has) iirc i've added also the __MORPHOS__ and __amigaos4__ defines because i was trying to post some other small patches to the official trunk.. but my time now is very limited and i never sent them..

@all

imho merging 3 mplayer version in one was really nice and usefull :)

@afxgroup

Quote:

I vote for that : let's get a unique repository for all Amiga versions starting with the Fab's port. Then let's check and apply some changes that could be useful from your port.

So, we will have only benefits : bug fixes applied to all versions in one pass, less time wasted porting the code 2 or 3 times, ...

@all
Absolutly agree. If we can't normally joing forces with OWB because of mui4, i hope we can join it with mplayer. But something make me think, that mplayer also use mui4, and for aos4 will need reaction-based gui rewrting. Or maybe mui3 will be more than enough , fab ?

@afxgroup

First, the GUI module is fully optional (be it at compilation or runtime).

The GUI module uses a couple MUI4 extensions (mainly for playlist class and dtpic.mui with alpha channel), but Deadwood managed to backport this to AROS (except for the overlay drivers and their integration in the GUI window, since AROS doesn't provide overlay support yet).

OS4 may also not have all the necessary bits for the overlay integration in the GUI (at least not using cgx API), but even then, MPlayer is modular enough, so you could re-use and improve the vo_p96pip driver, implementing the same functionality as vo_cgx_overlay or cgx_overlay_gui drivers (cgx_overlay_gui allows the video to be embedded inside the GUI itself, instead of opening a separate window as cgx_overlay or cgx_wpa would). Here's how it looks like in embedded mode: http://fabportnawak.free.fr/mplayer/MPlayer.png

And if for any reason the MUI GUI is an issue, you could add a separate reaction GUI backend (see gui/ directory).

@abalaban
Thanks for the info about branching in a CVS. I have downloaded and printed the SVN manual, and I have started reading it, so far it seems to be very well written and easy to understand.

Regarding the branching: as I have understood, when it would be decided to update the Amiga port of Mplayer, you would just merge the latest official source with the Amiga version. I believe that to do so you'll have to review each change manually. I suspect that we'll not have time to do the "update" procedure once in a while, but only when we'd be working on a new release. After e.g. one year, I believe most of the changes between the Amiga version and the official one would be related to old vs. new official MPlayer code. Wouldn't it be faster to skip this step by directly starting to work on the new sources and only apply the Amiga relevant patches? As long as this is possible with SVN, of course.

@Fab
I also fully support your idea, my only fear is that in the long term all the differences between MOS, AROS and OS4 might make it difficult to mantain the project (I'm thinking of CGX vs. P96 - later CGX vs. new OS4 gfx subsystem, ARexx vs. Python, eventually MUI vs. Reaction - later MUI vs. QT), but still it's better to start and see how this evolves.

I'm still available to mantain the project, but since I believe you have the best knowledge on how MPlayer works among everyone here, if you wish and have the time to take yourself this task, that would be no problem from my side.

Varthall

@Varthall

As i said, MPlayer itself is modular enough. You can have several backends living happily together. Ideally they should rather be sent to MPlayer svn itself, but it would be quite time-consuming and painful to have these accepted, as afxgroup told (besides, there are few (rare) changes to "generic" sources that could be seen as intrusive by MPlayer maintainers, which certainly wouldn't be accepted).

I also don't plan to manage this "MPlayer for AmigaOS" project for all OS flavours: not enough time, too much "administrative" overhead and possible conflicts later in some of the design choices. It's a bit sad, but I think it's much more efficient to work alone on this kind of small project (MPlayer itself is not a small project, but the port is).

My original suggestion was just that you could still use these sources as a base, since it implements most of the features you might want and is stable. Then, whether it's maintained for all OS flavours or only forked for OS4 in the long run, we'll see. The former would be ideal, but i think the latter will happen, unless someone "neutral" manages it. I don't care a lot, because it won't stop me from maintaining my port in any case. )

@Varthall

In fact merging is automatic in CVS or SVN as long as changes didn't happen on the same line. In such cases one would have to manually resolve the conflicts (which would be automatically detected at merge time).
That's why I'm saying we need the official sources afxgroup worked on this way SVN will be able to automatically detect changes specific to AOS4 and differenciate them from hte one done on the offcial sources. In the end that would mean SVN automatically detecting AOS4 diffs and automatically applying them to the official sources. This shouldn't be that much time consuming and even easy...

@Fab

I'm not against having a single repository that would be really great to be able to acheive this !

@abalaban
I agree with what you said, my only point was what happens when we have released a binary and we want to start working on the next release by updating to the newest official sources. The options I see are two:

- download the newest official sources, merge all of them with the whole AmigaOS MPlayer sources (your proposal)
- start anew: remove the old AmigaOS MPlayer sources from the trunk, put there the newest official sources, merge them with the AmigaOS-specific patches

Shouldn't be the second option faster (you don't need review any diff before the old and new official sources, as you are already working on the new ones)?


@fab, @abalaban
I was thinking to try to merge Fab's sources at a later stage, but on second thought it is indeed better to directly start to work on them and compare them, after that we can check afx' changes too. Thanks for your help Fab, I have sent you a PM with my email address.


@all
Let's get the ball rolling:

https://code.google.com/p/mplayer-amigaos/

Abalaban, and any other who would like to contribute, please send me you Google Code usernames so that I can add you.


Varthall

@Varthall

Quote:

No in fact the second option might prove to be slower (because you'll have to *manually* apply AmigaOS 4 changes). While with the first option everything will be automatic, only conflicts (if there are some) would need to be reviewed.

@varthall

Quote:
Ahem, what is QT doing in there ?

@centaurz

http://www.amigans.net/modules/newbb/viewtopic.php?topic_id=4432

That was just an example. Providing that that native QT port will see the light of day, it would be interesting to try to make, or port, a GUI using it. Another possibility would be FLTK, although that has not been further developed since long time. Anyway, this is low priority stuff that I'll eventually take in consideration in the future.

Varthall