[arch-general] x264, mplayer, ffmpeg rebuild?
Hey guys, Today i wanted to rip one of my dvds with h264enc from AUR [1]. I updated to the latest available version (8.6.6) but couldn't get it working together with the mencoder from the repos. I'm not asking for support for an AUR package, but here is what I found out and I guess this could be important for other ripping/x264 encoding software as well: The extra/x264 is severely outdated, in fact it lacks support for some -x264encopts that can be used by mencoder and therefore breaks encoding. This seems not to be very common by now but sooner or later encoding tools will use these options and we should provide compatible packages :) So, if one rebuilds x264 either with the $pkgver bumped to the latest available snapshot [2] or uses the AUR x264-git Package [3], MPlayer needs a rebuild too. Using the official MPlayer PKGBUILD results in a build error with a possible solution posted on the forums [4]. I know that the OP is using an SVN version of mplayer but I couldn't get the new x264 working together with the mplayer PKGBUILD from the repos (another build error complaining about libavcodec), so upgrading to the latest & greatest (tm) version seems to be the next logical step to me. I see that this "solution" involves using ffmpeg and mplayer svn versions which is obviously not suitable for the repos. But I'd be very thankful to see a rebuild of x264 and mplayer/ffmpeg as soon as the changes in ffmpeg and mplayer are in the stable branches and you guys can afford the time to do so :) Greetings, Markus [1] http://aur.archlinux.org/packages.php?ID=12121 [2] ftp://ftp.videolan.org/pub/videolan/x264/snapshots/x264- snapshot-20081228-2245.tar.bz2 [3] http://aur.archlinux.org/packages.php?ID=15774 [4] http://bbs.archlinux.org/viewtopic.php?id=61858
On Mon, Dec 29, 2008 at 12:39 AM, Markus Heuser <mheuser@mi.fu-berlin.de> wrote:
Hey guys,
Today i wanted to rip one of my dvds with h264enc from AUR [1]. I updated to the latest available version (8.6.6) but couldn't get it working together with the mencoder from the repos.
I'm not asking for support for an AUR package, but here is what I found out and I guess this could be important for other ripping/x264 encoding software as well:
The extra/x264 is severely outdated, in fact it lacks support for some -x264encopts that can be used by mencoder and therefore breaks encoding. This seems not to be very common by now but sooner or later encoding tools will use these options and we should provide compatible packages :)
So, if one rebuilds x264 either with the $pkgver bumped to the latest available snapshot [2] or uses the AUR x264-git Package [3], MPlayer needs a rebuild too.
Using the official MPlayer PKGBUILD results in a build error with a possible solution posted on the forums [4]. I know that the OP is using an SVN version of mplayer but I couldn't get the new x264 working together with the mplayer PKGBUILD from the repos (another build error complaining about libavcodec), so upgrading to the latest & greatest (tm) version seems to be the next logical step to me.
I see that this "solution" involves using ffmpeg and mplayer svn versions which is obviously not suitable for the repos. But I'd be very thankful to see a rebuild of x264 and mplayer/ffmpeg as soon as the changes in ffmpeg and mplayer are in the stable branches and you guys can afford the time to do so :)
Greetings, Markus
[1] http://aur.archlinux.org/packages.php?ID=12121 [2] ftp://ftp.videolan.org/pub/videolan/x264/snapshots/x264- snapshot-20081228-2245.tar.bz2 [3] http://aur.archlinux.org/packages.php?ID=15774 [4] http://bbs.archlinux.org/viewtopic.php?id=61858
Have you tried mplayer-svn? Mplayer will probably not have a stable release ever anyway. Greg
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
Le Mon, 29 Dec 2008 00:09:23 +0100, Markus Heuser <mheuser@mi.fu-berlin.de> a écrit :
Well, I'm not to familiar with the development procedures of mplayer but what I mean by stable is "stable enough to be packaged" ;)
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. -- catwell
On Sun, Dec 28, 2008 at 4:23 PM, Pierre Chapuis <catwell@archlinux.us>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 <stonecrest@gmail.com> wrote:
On Sun, Dec 28, 2008 at 4:23 PM, Pierre Chapuis <catwell@archlinux.us> 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
On Mon, Dec 29, 2008 at 1:34 AM, Scott Horowitz <stonecrest@gmail.com> wrote:
On Sun, Dec 28, 2008 at 4:23 PM, Pierre Chapuis <catwell@archlinux.us> 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
On Sun, Dec 28, 2008 at 5:34 PM, Scott Horowitz <stonecrest@gmail.com> wrote:
On Sun, Dec 28, 2008 at 4:23 PM, Pierre Chapuis <catwell@archlinux.us> 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.
This is a valid point, and I do agree. The "problem" here is all the legwork with x264 and ffmpeg rebuilds... It's a lot of deps and a lot of them (avidemux comes to mind) just don't compile against newer versions. If anyone is interested in speeding up this process, I would love some help with the following: a) Bump x264 to the latest version b) Bump ffmpeg to latest version c) Rebuild all deps for the above c') Patch apps that fail the build, and submit patches upstream d) Post an FR listing the versions used and which packages build fine, and which needs patches. Please attach the patches too. It's a lot of work, and I'd love to be able to do it sooner, rather than later, but quite frankly, I have more pressing things to deal with at this juncture.
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
participants (5)
-
Aaron Griffin
-
Grigorios Bouzakis
-
Markus Heuser
-
Pierre Chapuis
-
Scott Horowitz