Searching for MPlayer mantainer

Since i have no time AT ALL and many users are asking me for a new MPlayer version (almost every day..) i want to know if someone with almost a basic skill wants to take it.
Please send me an email at usual email address (andrea - amigasoft .net) and i'll send the latest source code that contains also a small gui (BTW not the gui written in the right way)

@afxgroup

Mail sent, I would like to try to maintain it. These weeks I'm working on mencoder, and I have already a recent build working, so I have already most of the work done for a new MPlayer release, and there will be no more duplicated work. By chance, your MPlayer sources is what I need right now, since I'm trying to add support for DVD:// tracks and libdvdread and I'd like to see how have you implemented them.

Varthall

I wish you luck Varthall and thanks afxgroup for all the previous versions.

@Kicko

What about trying to setup a public source repository ? That would enable punctual help from other developers.

@Varthall
A new release of MPlayer would be great. Maybe it would fix the horrid playback issues I have for MP4s (and other non-AVI/DivX formats to a lesser extent) where video stops being rendered (and just shows bright purple instead). Also MP4s seem to have bug where playback starts smooth & then quickly slows down until it is one frame per several seconds or more.

@abalaban

i've tried many times to add public patches to the mplayer sources, but many of them has not been accepted. It is hard to mantain two differents cvs since it is not like OWB where a library (WebKit) is updated from another source. So you have to patch every time the changes also on our cvs.
But if you want you can of course

@Varthall

This is great! Good luck!

@ChrisH

Quote:

Yea, this is very annoying. I think it has to do with audio syncing. I have a theory that it looses the sync sometimes and then slows down the video gradually trying to sync up with the audio again but it never works because most of the times the video is the slow thing, not the audio.

Most of the time it is not possible to properly quit mplayer when this happens. It ends up in some almost quitted busy-loop.

And another wierdness (in SVN-r29532-4.2.3): Some wmv files do not render properly but leave green residue from previous delta-frames, but this does not happen in an older version (SVN-r29068-4.2.3)!!

@Deniil

If you play an .mp3 file, can you exit while it's playing?

#6

@Varthall

GoodLuck :)

@Varthall

GoodLuck

@abalaban

As afxgroup has already stated, it would be difficult to maintain such a repository, at least it would have to be well thought on how to implement it. It would make the porting process faster though, even if at the end I'll be the only person working on it. A bugtracker, too, is a must. I have a first idea on how the CVS would be organised, let me know what do you think:

- to have a common starting point, an official MPlayer tarball would be uploaded
- next, we would have a list of versioned patches which should take care of different parts of the code. Depending on how the OS4's SDK evolves, some of these patches might become redundant and discarded
- and last, all the OS4-only sources would be included

A complete OS4 version would be created starting from the included tarball, all the files would be added and all the patches applied. Once a stable version is released, when the work on the next version will start the tarball will be replaced with a new one and it would be checked if all the patches are working on this version, by applying them one by one; if a binary is compiled without one or more patches, then those become redundant. I'm not sure if the MPlayer crew would allow to redistribute a tarball, if not it could be linked instead. This is something that would require quite some time to build up, but it might be worth.

Another thing I'd like to "address" is the exe versioning, MPlayer uses a progressive SVN number which is IMHO hard to read and to compare with other versions; the naming Afx uses is nice but also it doesn't give any info on which version is newer and which is older...

@Varthall

I don't see why/how a repository is harder than a tarball. On the contrary IMHO it's would be easier (and faster too) to update to a newer official version of MPlayer. It also ensures that no patch nor any work would be lost.

I managed to port MPlayer on my own a few weeks back. Just an SDL version. With the p96_pip driver source perhaps I might be able to get it to work a little faster.

.. as for the GUI and AREXX implementation, unless I can simply copy & paste it, then there's no chance in me adding that as I don't have any coding knowledge for C/C++.

Good luck Varthall.

@MickJT

you have compiled it since there are some patches in the mplayer trunk but many parts like libdvdcss, or the PIP driver and other stuff is not present in the official trunk so you have to add every time you want to release a new version.

@Varthall

Take the ball and run with it. I find it is much easier on the nerves to have complete control over a project and since you have the exact expertise to do what is necessary I think too much collaboration will only hinder any progess.

IMHO ;)

And thanks for taking it on! and yes, many thanks to afxgroup for the road that lies behind us.

@Varthall

Quote:

Yes, Andrea use exactly the mainstream progressive SVN number (f.e. 1.0 RC3 29xxx) imho it's perfect as is because we can easly compare the Amiga version and the original version/source

@Varthall

best of luck man!

@MickJT
I have sent you a PM.


@abalaban
I have never maintained/contributed to a CVS before, so my knowledge on the matter is limited. My initial thought was that it would be overkill to setup one if there's only one person working on it, but as you said a CVS would help maintaining the project nevertheless.


@all
Any recommendation for a CVS? Sourceforge?


@samo79
Quote:
My complain is that a progressive number like that isn't very readable (e.g. SVN-r29532-4.2.3 vs. SVN-r29068-4.2.3). I'd avoid following the official 1.x versioning too, those version seem to be coming out once every 1-2 years and when they do are already considered obsolete (see the comment on the latest 1.0rc3 version: "Note that this code is ancient, e.g. it still contains this long-fixed bug. Unless you are at least deadly allergic to it, use latest SVN instead.").

On the other side, using a new, separated versioning might be not a good idea too, as it might also lead to confusion ("Is OS4's 1.0 version newer or older than the official 1.0rc3?"). So, my suggestions:

- assign a new name to this project and create a new versioning path, e.g. AmyMPlayer 1.0, based on MPlayer 1.0 RC3 29xxx. The exe would output both "AmyMPlayer 1.0" and "MPlayer 1.0 RC3 29xxx".
- use the date of the source as a version number, e.g. MPlayer 1.0 2010-11-01. I have seen that the MOS port uses this type of versioning. AFAIR the date is not printed by the exe ("MPlayer SVN-r32198-4.2.5 (C) 2000-2010 MPlayer Team").

Varthall

@Varthall

I contacted afxgroup and got back the sources too. I'll look at them and see how we can setup a repository.

To be precise if we would go for a source repository it will be SVN (Subversion) and not CVS just because official MPlayer *is* using SVN as such using the same tool would ease the update.
I'll look at the afxgroup's sources and compare with the official MPlayer source tree to see what we can do and how.

Be it for CVS and SVN there are tons of tutorials on the web and for a basic use just two commands are needed (update and commit). Merging is another story but not over kill either.