mplayer and transcode fixes

Since things are finally starting to settle down (hey, I’ve had Internet for a week now, cool), I’ve started getting back to poking at stuff, slowly. Today I cleaned up some mplayer and transcode stuff in the portage tree, and I just thought I’d mention what’s new.

First of all, mplayer. The latest revision is 1.0_rc2_p27120. The snapshot itself is about a month old, and I don’t know of anything particularly major that’s in there (I haven’t had time to follow development for the past month anyway). It’s been masked for testing, not because upstream has done anything funky, but because there are some new use flags, which have helped me to go back and clean up some stuff that I should have done a long time ago. I haven’t heard a peep from anyone on bugzilla so either no one’s tried it, or it works great.

The big changes that I can think of off the top of my head are this: first of all, there’s an ewarn added if you enable the cpudetection flag. It finally dawned on me that this one might not make sense. Here’s what it *doesn’t* do — magically make the build detect and build for your CPU architecture. The build system already automatically detects and installs with the correct instruction set by default, using stuff like MMX, SSE, and friends. The only reason (that I can think of) that you would use that, is if you were deploying the binary package on another computer, since it is a runtime feature, not a buildtime one. So, you’ll get a little warning if you enable it, because, in general, desktop users don’t need it. I also fixed the use.local.desc to be a bit more specific as well.

Secondly, there’s a new use flag: custom-cpuopts which should finally solve the long-standing dance of trying to outwit users who always break their system but still allow real tweakers to do exactly what they want. Here’s how it works. MPlayer’s build system, again, by default, will automatically detect the CPU optimizations that are supportd for your platform (MMX, SSE, again, etc.). That means that, again, if you leave everything by default — it should work fine.

Originally the problem we would have is that people would have their CPU optimization use flags turned off (like mmx), which would normally break the build. The ebuild is written to only disable them if they are turned off, so my solution for a long time was to tell people to just turn them all on and let MPlayer *not* disable them, therefore, revert back to autodetection. This would then cause problems, though, for those few who were building MPlayer for some other box, and they wanted specific CPU opts on or off. This use flag will fix just that.

What custom-cpuopts will do, when enabled, is forcibly enable or disable the actual CPU optimization use flags you set. This will help out those on certain profiles and setups who need to tweak their build for whatever reason. For normal desktop users, you don’t need to enable it — if it’s turned off, the ebuild will completely ignore the other use flags (for CPU optimizations) and just use the default checks … which work great. It also means that your build will be optimized the best it can, yay!

I know I really went into depth on that one, but it’s been an issue with the build and users for a long time and I’m glad I finally got a cleaner solution working. Now everyone has the options to do whatever they want, but by default, everything should build and be optimized wonderfully.

Oh yes, one last thing — if someone wants to fix bug 228799, and submit a patch upstream, I’d be extremely grateful. That would clean up the LINGUAS hack in our ebuild, which I’ve heard breaks on paludis anyway.

As far as transcode — I’ve been out of the loop, and the media-video team has been taking things over and cleaning up (I don’t even know who, sorry guys, haven’t taken the time to look into that either — I know loki_val fixed up some imagemagick / ffmpeg dep crap that I didn’t want to touch, thanks man!). 1.0.5 is back in the tree, and should be the next stable candidate. I also added another rc for 1.0.6, and I have to add the 1.10 beta sometime.

That’s about it for now. Have fun. Go break your box. :)

Advertisements

what i'm working on

Just another update on what I’ve been poking at lately.

I’ve mostly been cleaning up really small stuff, small bugfixes that have been annoying me for a while.

GPNL / Packages

For the packages website, I finally fixed it so that you can search by just package name again. It’s still messed up where it searches way too much stuff by default, but that’ll be fixed soon. It was originally searching by atom and description, so stuff like package$ would break.

I did, however, put the basic search I want to add to the packages website into GPNL: search by atom, package, category, description or all. I need to add changelog to that list. It’s not much, I know, but it’s a start on the long road to getting an advanced search going. I also cleaned up the front page a bit, and added a link to the nightly database dumps.

I also cleaned up the bash script to import the data. It actually has the beginnings of some error checking now, so you shouldn’t be seeing blank pages anymore. And the database is vacuumed correctly, and on a regularly basis, so things should be slightly snappier. I’m also importing the entire portage tree 3x daily now instead of twice. The import script is actually a nice cleanup for me, because if something breaks, I can run parts of it partially, instead of having to manually fix it. It’s much nicer.

My next big thing is getting RDEPEND searchable.  In the database, it’s combined with the DEPEND variable, so I have to separate the two out.  Once that’s done, we can finally dynamically query the tree to see where ebuilds need to be fixed for binary packages.

MPlayer / Transcode

Looking better, closed like eight bugs the other day for mplayer. Finally fixed some asinine bugs of mine for transcode, have one more to go.

Took out the masked libdvdnav because it will conflict and break libdvdread. I already wrote about how I put it in my overlay so if someone wants to use it, they can.

Sword ebuilds

I finally got pretty much all the main ones in the tree that I wanted to get in. There’s still two LDS ones that I have to make myself. Shouldn’t be too hard. I hope. In all, there are 150 sword ebuilds in the tree. Freak. That reminds me of something else I fixed on the packages website: it lists the number of results. That’s something else that’s been annoying me for a while.

I still need to remove the old sword-modules ebuild and add a new virtual-type one that will pull in all of the ones based on which language they are written in. Not hard to do, just slightly tedious. Should be done soon.

lds-scriptures 3.0

Believe it or not, I’m actually planning on getting this finished this week. The actual data has been finished for a very, very long time… it’s writing the documentation that I am extremely particular about because I plan on this being the final release.

That’s about it for now, that I can remember.

transcode and dvd::rip

New versions of transcode and dvd::rip just went into the tree.  Transcode saw its first stable bugfix release (1.0.3) for the first time in a year and a half.  Woots!  The 1.1.0 release of transcode is apparently just around the corner, too, so hopefully we’ll see that soon.

I haven’t had any luck getting dvd::rip to work with the newer branch (though I haven’t updated my snapshot lately, either), but I know it’s support is planned.

Anyway, give them both a try … both very mature, good pieces of software.  I always encourage people to give transcode a try as an alternative to using MEncoder or ffmpeg.  There’s a learning curve, but well written man pages will help you out immensely.

transcode snapshots

I just put a new version of transcode in the tree, this time a CVS snapshot of upstream’s development branch (v1.1.0).

It won’t work with dvd::rip, though, but that doesn’t mean you can’t play around with it. Besides, look at this as a perfect chance to get familiar with finally learning some CLI arguments and really learning to command your applications. That’s where all the fun is, anyway. :)

After a quick glance, it looks like the man page has a few errors. Nothing major, just small parts of it are incomplete. Actually, everything seems much cleaner, really. The output of transcode is a little nicer, and the man page seems trimmed down and more organized. I noticed while writing the ebuild that a few options were dropped in this branch, and a few other things added as well. I’m interested to take a look at it sometime and get a closer look at what’s improved. I haven’t played with encoding stuff in a long time, since I’ve kind of given up on my idea of having a massive library of encoded files on my mythbox. Truth be told, I don’t mind changing discs at all. I’m sure my position would change, though if I had some rugrats who enjoyed putting DVDs in the toaster or something like that. All in good time, though.

One thing is for certain — writing ebuilds of development snapshots is not nearly as easy as I thought. Configuration options change quite a bit, and you have to test things pretty thoroughly. I’m glad for the experience, though, that’s for sure. I feel like I’m getting a little better at it after each one.

multimedia bumpage

I don’t usually like talking about writing about stuff that I’m just bumping in the tree, but since there’s been a lot of it lately, I figure if I roll it all into one post it might be somewhat interesting.

I’ve been focusing mostly on just multimedia applications lately, since other Gentoo stuff has been annoying me, and this is the most fun to work on. Last week I went through the sound bugs and cleaned up some crufty old bugs that were simple fixes to ebuilds. I think that’s actually the first time I’ve fixed almost anything in the sound herd since I joined oh so long ago. There’s still a lot of stuff to be done there, but from a quick glance most of it seems pretty trivial. There’s a lot of requests for version bumps in there, which I’ll get around to sooner or later, usually depending on how tricky the ebuild is.

Here’s a helpful note to users filing bugs, btw. If you can attach a working ebuild, that helps a lot. I usually have to go in and tweak them anyway and fix errors, but most of the time they are just cosmetic in nature, or are missing a DEPEND flag or something. Even a little effort helps, though. And if you don’t know how to write ebuilds, learn! It’s not that hard for most of the packages that use a simple configure, make and make install. I recommend checking out the excellent devmanual for guidance on getting started.

Or, if you’re already good at writing ebuilds, try to find a proxy maintainer to put the ebuilds in the tree for you, while you do all the hard work (I really need to write more about that when I get some time). Or maybe get them into one of the Sunrise overlays. I’ve already dragged one user into the fray and put some of his multimedia applications in the tree. Proxy maintenance seems to work really well for me. I’m already doing it for a few applications. All I have to do is look over the ebuilds, fix them up, test the program and I’m done. The maintainer gets to do all the hard work like write the original ebuild and bug me when the version gets bumped.

Now that the wordpress security saga is finally over (it’s hard masked), I’ve been able to get back to my own ebuilds as well, too. Here’s some of the stuff that is new and I’m hoping people will check out and test.

IVTV released a new version, 0.10.1 which works across three different kernels this time (2.6.18 through 2.6.20). I upgraded my mythbox last weekend to the new kernel and version, and while it may be my imagination, I’ll swear that the picture is a little cleaner than before. The ebuilds just barely got unmasked because there was a bug in pre-2.6.20.2 kernels that would bork loading the firmware for certain devices. So if you are going to use a 2.6.20 kernel with IVTV, be sure to use either gentoo-sources-2.6.20-r1 (or higher) or vanilla-sources-2.6.20.2. Those are patched, so you should be good to go.

I’m thinking about masking the other, older IVTV ebuilds in a bit here, since technically they are all deprecated now by upstream because of this new release. I probably won’t remove them from the tree, though, because I’m all too familiar of the symptom of some funky version being the only one working on your hardware for some ungodly reason. Please do migrate and move onto the newer versions, though, since if any bugs come in on the older ones, I’m just going to start ignoring them.

In other IVTV news, the drivers are going to be in the mainline kernel starting with 2.6.22. I’m pretty excited about that too, since that means I’ll just have to maintain a set of userland tools after that. Speaking of which, 0.10.x have a few more than before, so be sure to check them out if you’re looking for some help. And please, for the love, read the README if you have any questions about the package. It contains lots of useful information.

Something else I bumped the other day was dvd::rip. It seems to have stabled up pretty good (I haven’t heard any complaints). I was a bit worried at first about removing the 0.5.x series from the tree (the old GTK+ v1 releases), but things seem to be okay. I don’t even remember what’s new in this version of dvd::rip. I remember glancing at the changelog, but nothing exciting is coming to mind, so who knows.

I also did a CVS snapshot of transcode, which is in the tree now. Their last point release was November of 2005 (eek!) and their website recommends running the CVS version instead. A lot of multimedia applications tend to do that it seems like (mythtv, mplayer being some other examples), and while it usually works just fine (except for myth of course, where upgrading is like russian roullette … sorry, I just can’t resist ripping on Myth ;) ) it makes it difficult for users that don’t want to or don’t know how to get CVS snapshots.

Transcode actually has two CVS branches as well, one for stable bugfixes, which would be the 1.0.3 release, and one for the next development release of 1.1.0. I put a snapshot of 1.0.3 in the tree, and I’ll get around to doing one for 1.1.0 later on. In the meantime, I’ve created a forum post if you find any issues with the snapshot, I’ll see what I can do.

I should mention that I have a secret love affair with transcode. I know I fawn over MPlayer and MEncoder constantly, but I love using transcode, especially for DVD encoding. The controls are a bit different, and may seem somewhat unorganized at first glance, but once you read through the entire man page, it’s not bad at all. It’s a great little encoding app, and I’ll put a cap on my fanboyism and just suggest giving it a try in your free time. I tested it with the latest dvd::rip and it seemed just fine, so go ahead and be daring and do the same.

One thing I did notice that was new in this release was that if you started transcode and canceled the process (ctl-c), it would kill the pipes as well. That’s actually very nice, since it was somewhat annoying before having to stop up to four processes just to kill transcode completely.

Other stuff that’s new, there’s a new version of OGMRip in the tree. I really like this slim frontend to MEncoder. The things I like the most is that it handles subtitles for me (I’m still really unclear on how those work, I need to do some manual encoding some time), wraps the output straight into Matroska, and of course is GTK+. :) I would say it’s been pretty stable for a good while now, so if you’re looking for a good ripper, I would recommend that one as well. So there you go, two recommendations for two rippers that use different backends (transcode and mencoder). There are more of course, but if you want the simplification of a GUI, you’ve got a few good options.

Speaking of subtitles, I somehow got roped into maintaining all the subtitle programs in the portage tree some time ago. I bumped gnome-subtitles again this week (thanks again to proxy maintenance), and there’s another ebuild in bugzilla for a new one that I’ll be looking at sometime soon. And I must in good conscience mention gaupol, your third option for subtitlely goodness.

I also got roped into helping out on ALSA now that Diego has left us. I’m still not sure how I got suckered into that one. I’m not making any claims to fixing things up nice and pretty, though. At the very least I hope to keep us on track to staying current with upstream and fixing some minor bugs. I’m still not convinced that I can be of any help on the team, but I’ll see what happens. Just don’t expect me to fix any major borkage. :)

Last but not least is mplayer. I finally got a new version of mplayer-bin in the tree, though that’s already old news. Thankfully the biggest complaint I’ve gotten so far is that I’ve ripped out AAC support. I’m actually glad for that, because it was a royal pain in the pooty pants getting that thing even working in the first place. As far as missing media libraries go, though, that is not not really my area of expertise. I’ll see what I can do about it sometime, but to be honest I’m not really in a huge hurry. I figure if you can play either the audio or video stream in the native mplayer / mencoder, then just separate the two and use mencoder-bin to do the other half. That’s poor reasoning, I know, but that’s why it’s not high on my list to fix right away. I should also mention that there’s a RealVideo stream I watch on a regular basis, half of which will only work in each player. So, I can sympathize. And yes, I do download it and then re-encode it with mplayer-bin just so I can watch it in mplayer.

I’ve also been working with Luca (lu_zero) on a new mplayer SVN snapshot. It’s coming along quite nicely, I’d say, and hopefully should be ready and in the tree real soon now.

That’s it for now, I guess there was more stuff to write about than I imagined. Sheesh. I hope the multimedia experience on Gentoo is working well for everyone. As I’ve said before, it was one of the main things that made me pick and stick with this distribution years ago, and I’m glad that I can finally get the chance to help out and give back at least a little bit.

As a final note, there really are a lot of bugs for sound, video and cdr stuff in the tree (well, not so much media-optical). They almost all register pretty much the same as far as importance goes to me, so if there’s something that’s been just nagging you for a while now, feel free to ping me on IRC (beandog on Freenode), or e-mail me (beandog at gentoo dot org) and I’ll see if there’s something I can’t help move along a bit. No promises, though. :)