wonkablog

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.

Okay, this is great. This morning at work we were talking about YouTube videos, and then cell phone ringtones, and we got the awesome idea — let’s make some ringtones from YouTube videos! Sweet!

So I downloaded the incomparable video Charlie the Unicorn, used audacity to cut out the Candy Mountain song, and then uploaded it to my cell phone with Bluetooth using my co-worker’s Mac. Freaking right on.

It’s a mecca of love, the candy cave!

Okay, so if you wanna know the technical details, here’s specifically what I did:

Download the youtube video using youtube-dl:

$ youtube-dl -b -t “http://youtube.com/watch?v=Q5im0Ssyyus”

Extract the audio to WAV format using MPlayer:

$ mplayer charlie_the_unicorn-Q5im0Ssyyus.mp4 -ao pcm:file=candy_mountain.wav

Edit the WAV file with Audacity, select the song portion, and export it to MP3 with a64 kbps bitrate. The start point was 2:26 and it’s 42 seconds in length

$ audacity candy_mountain.wav

And that was it! Instant ringtone goodness. Here’s the MP3.

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.

An interesting post came up the other day on the Gentoo forums about how to rip Blu-Ray discs on Linux. Short summary: I have no idea if it’s possible, and the original poster is still investigating. It has gotten me thinking though. The Blu-Ray player that I want to get it is $600, and it looks like it’s being phased out of production anyway, so why not get a disc drive instead and rip the movies? It’d save me some money, and I’d eventually buy one anyway.

Well, the questions that come to mind are, will the software actually work, will the drive firmware let me do that, and am I going to have to use Windows?

I haven’t done any research at all, mostly because I can’t afford to buy a DVD drive right now, but the whole thing does have me curious. I always assumed there was no way to rip the stuff under Linux, but I haven’t gone looking for possible solutions either. The only thing I am sure about though, is that once ripped, you can play the content just fine. At least, I think so. I’m not positive about the HD audio codecs, pretty sure about the video ones though.

I tend to buy hardware first and figure out how to get it working second, but because the DRM is so finicky in this case, I really don’t want to take that approach and be out a couple hundred bucks.  In the meantime, I really wish I could at least demo the stuff at home.  That would be cool.  The only 1080p content I’ve seen so far is the movie trailers I’ve downloaded from Apple’s website.  I gotta say that stuff looks pretty good.

There has been some recent activity again on the libdvdnav front, and so I’ve been playing around with it again.  I finally created an SVN ebuild for MPlayer which I can use myself instead of just manually updating and reconfiguring the repo myself.

Generally speaking, I don’t like the idea of ebuilds that hit upstream’s SVN servers directly, so please be kind and don’t do anything asinine like upgrade every single day or something.

So now I have live subversion ebuilds for both libdvdnav and mplayer.  This is the important thing to know about the libdvdnav ebuild: it has some changes to libdvdread so you will have to unmerge the one that is already uninstalled.  On top of that, since it is a new API version, everything you previously compiled against libdvdread (k3b, etc.) will have to be re-emerged … and even then, there are zero guarantees that it will work at all.

In short, these ebuilds are only designed for a select few: those people who are using mplayer exclusively and want to have dvdnav support at the risk of breaking anything else that needs DVD access.  Obviously, that scenario fits for someone with a media frontend, but doesn’t make sense for general desktop usage.

Also worth noting is that these are the only two ebuilds that will work together.  Previously, the mplayer in the tree would have detected and worked with the libdvdnav ebuild, but that’s not the case anymore.  It’s these two in the overlay, or the mplayer in the tree.  Pick one set and choose.

If you have problems with the ebuilds, let me know.  I’m still not an expert at layman so I can’t go about giving you instructions on how to install this stuff directly.  Have fun, though.

Oh, and last but not least — I tested them, and it works for me. :)  Just emerge libdvdread first, then mplayer.

Okay, now this is something I wasn’t expecting. Warner Bros. is releasing season one of Justice League on Blu-ray. Wow.

I’d been planning on *eventually* getting a Blu-ray player anyway, but I’ve been pretty indifferent about the decision, or when. Actually, the real thing that’s holding me back right now is that I can’t natively rip them on Linux right now (play back, yes, but that’s an entirely different matter). There’s no way I’m firing up my Windows box just to get some 1080p goodness on my harddrive. I’m a sucker for automation.

Even though I can’t code in C++, or anything more hardcore than bash (and even that’s pretty sketchy), with a push in the right direction from a noble soul in #mythtv, I managed to mangle a patch together for MythVideo that fixes some annoyances that I’ve had for a very long time. They are:

• Filenames won’t display underscores, but folders would
• Getting rid of the “cover image” screen in the gallery
• No page up, page down support with your remote

The patch is here, which should apply cleanly to media-plugins/mythvideo-0.20.2_p15087. Or you could just try and use my overlay directly. If you look at what I’ve changed, it should be really simple to make the same changes to the most recent version for SVN, since I don’t think the file has changed much between releases. Creating patches is also not my favorite thing to do, and in fact actually took me longer to create the actual diff and apply it correctly then it did to hack the code.

Here’s a complete list of what I changed, if you don’t want to go digging around the code and determining what’s happened for yourself:

First, the issue of page up / page down. Sure it’s nice that you can do that with a keyboard, but if you are using a remote, it’s painful scrolling when you have a lot of folders to look through. I remapped 1 and 7 to emulate Home and End, and 3 and 9 to emulate Page Up and Page Down.

Second, for the display of folder names, if it has an underscore in the title, that is replaced with a space. This is consistent with the naming scheme for the actual files.

Third, and always most annoying to me, is that I got rid of the information screen that displays all the metadata about a movie after you select it in gallery mode. I always thought that was pretty useless, because I already know what I want to watch, and didn’t like having to hit enter twice to start playback. There was a shortcut already, you could just hit the Play button and it would skip the screen, but I think this is more effective and natural.

Finally, I disabled the Menu, Filter and Info options by commenting them out, for the only reason that I never used them and sometimes they would pop up when I was debugging stuff with mplayer and my remote.

Needless to say, I’m much happier now with my user experience, since MythVideo is all I’m using right now. I have a really low tolerance for small tweaks that bug me, and I’m glad I finally got these taken care of. Besides, it’s forced me to start learning some C++ (again) so I don’t have to keep relying on people to help me get started.

Now I can go back to watching Roger Ramjet and Knight Rider in navigation harmony. It’s great.

If you’re looking for mplayer + dvdnav support, there’s two ways to get it right now. Depending on how much support you want is going to change which ebuilds you’ll have to use right now, though.

If you just want simple playback support (no menu navigation), then use portage’s tree. Just unmask and emerge media-libs/libdvdnav, then re-emerge media-video/mplayer. That will build against the older, original dvdread library, but it should be enough to get you around the Sony ARccOS DRM. Hint: mplayer dvdnav://[track_number]

If you want the full playback + navigation support, you’re going to have to use an overlay (specifically, mine). I, personally, am against the idea of using overlays since I think it splits the tree, only asks for problems, and reminds me of using Mandrake back in the day when I had to have all these third-party mirrors just to get software I want. So, I’m really against the idea and wouldn’t be doing this unless there were an easier, simpler way.

Ranting aside, my overlay is at http://overlays.gentoo.org/dev/beandog Browse the ebuilds here. I would give some slick instructions on how to add it using layman, but since I never use overlays, I can’t tell you how, and I assume that the people who really know what they’re doing don’t need instructions anyway.

There are very few differences in my ebuilds. libdvdnav will use the newer version of libdvdread, so the one from the portage tree will show up as a blocker (and possibly break all your other packages that use it). After it’s installed, you’ll have to use my mplayer ebuild as well, since it’s configured to use the external dvdread library as well. After that, you can use dvdnav:// as you normally would. Hint: mplayer dvdnav://

I know it’s a bit of work, but until the forked libdvdnav can also work as a replacement or secondary slot to libdvdread in the tree, either option which would require testing, that’s how its gotta be. The plus side though is, it works.

I normally don’t post info about version bumps, but since the last MPlayer one was a while ago, and since I’ve been way too busy lately to work on anything Gentoo related, I thought I’d make mention of this one.

Not much to say, though, really … there’s a new snapshot in town (media-video/mplayer-1.0_rc2_p25993).  It fixes some security issues in older versions, which was the reason for the bump.  I’ve tried to change my approach of bumping the package every month or so and instead just focus on getting one release working really well and as many bugs fleshed out as possible in that release.  So far the approach has worked well.

Normally I’d have a good idea of what’s changed between releases, but since I haven’t had time to keep an eye on mplayer-dev either, I couldn’t really say.  I think there’s a few DVD fixes, but I’m not sure.  Sorry.

Anyway, as usual, let us know if you have any issues.  Should hit the tree shortly.  Enjoy.

A bug in MythVideo inspired me to work on fixing mplayer-resume tonight, so that it can properly handle movies with filenames.  I don’t know why I didn’t think about this before, but it’s simple if the file is properly escaped or quoted.  And so, mplayer-resume v1.5 is released, with support for spaces in filenames, finally, and also one other cool little thing: it works with playlists now, to a degree.

The playlists thing is kind of hard to explain, and it’d be easier to point you to the documentation that I’ve already written.  Instead, I’ll just describe what it is I’m going to use it for.

One thing I’ve been wanting to add to my MythVideo setup is some playlists so that I can randomly play something.  I have a lot of cartoons and videos and movies, and sometimes I don’t feel like picking something myself — one of the nice things about TV in general is you are genuinely surprised when you’re channel surfing and something cool just happens to crop up.  That’s kinda what I like, and what I wanted to do.  But, I wanted to take it a step further.  If I started playing $random_episode, then if I quit, I want to be able to resume playback of that same show.  Up until now, mplayer-resume wouldn’t work that way, since if you’re randomly picking something from a playlist file, there’s no real way to seek back to the same one.

That’s fixed now.  The script will read the filename of the movie you are playing when you exit (once you setup .lircrc correctly), and checks to see if that’s the same file you started playing.  So if I play random.pls and it plays Tarzan.mkv, and I exit, then when I go back to watch Tarzan, it will resume in the same place.  Basically, it saves the file position for Tarzan instead of the playlist file.  Pretty cool.

So, there you go.  I’ll put it in portage shortly as well.  Enjoy.