Hi,

Have you tried mplayer-svn? Mplayer will probably not have a stable release ever anyway.

Yeah, I'm using the mplayer-svn package from AUR right now, with some adoptions regarding the configure flags (like support for x264 and mencoder of course...). Well, I'm not to familiar with the development procedures of mplayer but what I mean by stable is "stable enough to be packaged" ;) Cheers, Markus

On Sun, Dec 28, 2008 at 4:23 PM, Pierre Chapuis wrote:

To me, the only way to use an up-to-date mplayer is to compile it yourself on your machine (by using one of the AUR packages).

Making a binary mplayer package is very difficult and the result can't be perfect for everybody because you have to make choices about what will be enabled in it (and add deps) and what will not (but some users might want it). It's the prototype of the package that should stay source-based if possible.

That may be so, but there are binary packages available. And while that is the case, they should be updated every so often. I mean, ffmpeg is almost 6 months old and it's tied to revision 14236 - the current revision is 16380! We are 2000 commits behind, it's astounding. Not to mention I recently ran up into a bug where ffmpeg causes mpd to crash, and it's because the package is so out-dated. And there are other bug reports as well, dealing with other crashes and broken ogg support: http://bugs.archlinux.org/index.php?string=ffmpeg&project=1 So the question remains, will these packages be updated anytime soon? Back to your point about it being difficult to package - while I realize there are resource implications to this suggestion, I think the goal would be to have a couple different binary packages available to hit the most common uses, like is done with some other packages. I wouldn't throw up my hands and resort to compiling from source. Any idea how long it takes to compile mplayer on a p3? Trust me, it's not fun. Scott

On Mon, Dec 29, 2008 at 1:34 AM, Scott Horowitz wrote:

On Sun, Dec 28, 2008 at 4:23 PM, Pierre Chapuis wrote:

...

To me, the only way to use an up-to-date mplayer is to compile it yourself on your machine (by using one of the AUR packages).

Making a binary mplayer package is very difficult and the result can't be perfect for everybody because you have to make choices about what will be enabled in it (and add deps) and what will not (but some users might want it). It's the prototype of the package that should stay source-based if possible.

That may be so, but there are binary packages available. And while that is the case, they should be updated every so often. I mean, ffmpeg is almost 6 months old and it's tied to revision 14236 - the current revision is 16380! We are 2000 commits behind, it's astounding.

Not to mention I recently ran up into a bug where ffmpeg causes mpd to crash, and it's because the package is so out-dated. And there are other bug reports as well, dealing with other crashes and broken ogg support:

http://bugs.archlinux.org/index.php?string=ffmpeg&project=1

So the question remains, will these packages be updated anytime soon?

Back to your point about it being difficult to package - while I realize there are resource implications to this suggestion, I think the goal would be to have a couple different binary packages available to hit the most common uses, like is done with some other packages. I wouldn't throw up my hands and resort to compiling from source. Any idea how long it takes to compile mplayer on a p3? Trust me, it's not fun.

Scott

I would add a feature request on flyspray to at least move mplayer to svn. The mplayer developers have explicitly stated on the MLs many times that they dont care about releasing. Also I dont know who maintains the packages atm, but if the situation is as you say maybe someone else can pick them up. One that actually uses them. Greg

Hi,

Making a binary mplayer package is very difficult and the result can't be perfect for everybody because you have to make choices about what will be enabled in it (and add deps) and what will not (but some users might want it). It's the prototype of the package that should stay source-based if possible.

Well my main issue wasn't so much about an up-to-date, "bloated" or modified mplayer package but a bump of the x264 package wich is like half a year old if I interpret the versioning scheme right. I just wanted to show that there are some showstoppers in the way if we want to provide an up to date x264. I'm perfectly fine with the mplayer version from the repos but I don't think that the PKGBUILD can be reused for the latest available mplayer sources if it is configured with x264 support (as it is the case now) because of the rewrite in the mplayer/ffmpeg code. So I'm not asking for new features and stuff but if future mplayer packages should be built against an updated x264 package and provide the same functionality as todays version, the configure flags might need to be adapted as pointed out by the forums thread. I'm sure that Hugo makes the right coices and would be able to find (better) solution for this on his own, but nevertheless giving the forum thread and my mail a read could perhaps save a bit of time ;) If there is a possibility to "recycle" the now used PKGBUILD I definitely won't complain about it. Greets, Markus