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.

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.

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.

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.

I was tinkering with my MPlayer configuration for LIRC tonight to figure out a small OSD annoyance, when I found this interesting thing that I always thought would be nice.  The slave mode has an option to switch the aspect ratio during playback.

The reason this is nice is for those who are using mplayer to watch a fullscreen format (4/3) show on a widescreen TV, and they aren’t already stretching it to 16/9.  Basically, it stretches stuff if you want it to.  Personally, I like watching stuff in the original format it was filmed in, but sometimes I want to expand it to fit the whole screen too.  This let’s me do that.

Here’s the relative config for my lircrc file:

begin
prog = mplayer
button = some_button_you_mapped
config = switch_ratio 1.77778
config = switch_ratio 1.33
end

So, what that does is switches stuff from fullscreen to wide, and back again by pressing it again.  Pretty spiffy.

I also uploaded my mplayer lircrc file.  It’s nothing glamorous, but might give someone some ideas.

Okay, so that might not be the best thriller movie title ever … but so what. Buh. A while back, MPlayer developers forked libdvdnav, and recently had their first release. It’s already in portage, but package.masked. Emerge it and try it out. It might work. It might not. At least MPlayer compiles against it and uses it. I also bumped us to an rc2 snapshot, whee! There isn’t a dvdnav use flag, but that’s okay for now — just install it and MPlayer’s config will see it and link against it (similar to libnut). For the record, that’s not the ideal way to do things, but ah well. Someday all will be fixxored.

Also, it looks like LAME is currently the only possible solution for MP3 encoding right now … as the lavcopts + mp3 acodec option mysteriously disappeared. Dunno if that was an oversight or what. Who knows. Seems like there was something else interesting I was gonna mention, but I can’t remember what it was now.

In other unrelated news, I have eleven unopened bags of candy (plus a full bowl still) from last night. I plan on being on a sugar high for the next few weeks.

Note: I actually wrote this a few weeks ago (July 9th), but since I mentioned the Star Trek test in my last post, this is where I first wrote about it, and I thought this post was live. I can’t remember now why I didn’t publish it. Anyway, the basic description of the test is that once I get Star Trek looking really nice on my TV, then I’m finally finished setting things up for good.

I spent most of this weekend working on trying to get my media box back up to snuff again, so I can see how well things will work. This time, I focused mainly on trying out the media center experience on my TV, since I remembered vaguely from last time there were a few issues.

My backup power supply also died this weekend, which means I’m down two boxes now, so I hauled out my desktop instead to the living room to hook it up to my TV. For my first test, I trotted out some really old Harvey Toons cartoons from the 50s. Note: Some of the cartoons on this set are *really* creepy, especially considering the time period. Considering the generally low quality they are going to start with, they looked pretty good, except for one problem — I could see some horizontal lines anytime there was a moderate amount of movement.

I was pretty sure the problem was related to interleaving or something like that, there are many terms I don’t entirely understand, so I started looking around the MPlayer man page for some video filters. I immediately found one that I was familiar with, and I had used just the other day to re-encode something. The softskip and pullup filters fixed the problem, and made the lines go away (ex: mplayer dvd:// -vf softskip,pullup).

I tried watching something a bit more modern (Murder, She Wrote), and the picture was absolutely gorgeous. As far as picture quality went, I couldn’t tell it wasn’t the DVD. It seemed to me that I noticed some slight stutter anytime characters moved rapidly, but I wasn’t sure. Once again though, for simple shows where you are just going to watch the show and not care too much about quality, it worked great.

Since things were going so well so far, I decided to pull out the big guns and try out what I refer to as the Star Trek test. This is where I’ll pull out a disc from Star Trek: The Next Generation and see how well my setup duplicates the quality of my DVD player. I randomly grabbed a box set and disc from the bookshelf, and ended up testing with the episode “Deja Q” from season three (a really great episode, btw. “Red alert …”) .

This episode turned out to be a great one to sample, since the very opening scene shows a huge asteroid drifting off to the side, with the Enterprise right beside it. On my computer, the stutter was painfully obvious, especially compared to watching it on my DVD player. The only thing I could think of at first was to try and drop some frames so it wouldn’t have to work so hard, even though my CPU usage was never above 5%. I tried -framedrop and -hardframedrop, and I’d like to say I noticed a slight improvement, but I can’t be sure. Running either one of those is risky anyway, since if you pause and resume playback, half the time MPlayer quits.

One thing I was hoping might help was if I changed my monitor resolution to a lower setting. I changed it to something much lower, like 640×480, but that didn’t help either. I poked around at more video filters, but nothing helped.

It’s not really a big problem for me, anyway. I’d already made the decision long ago that trying to watch any science fiction movies or anything with high motion or action scenes would be visually annoying on the computer, so I’d given up on hoping to get those ripped and archived. Still, as far as the Star Trek test goes, I must admit that the quality was much better this time, and if it wasn’t for the visual artifacts, I’d be sold.

The thing that really bothers me though is this. I can spend $60 on a DVD player, and the picture quality still looks better than what I can get with $600 in computer parts, including a top of the line CPU and video card. I’m really not sure where there is room for improvement. Until then, I guess I’m stuck watching stuff the old fashioned way — one disc at a time.

I’ve been having a lot of fun with my mythbox lately. I’ve learned some really cool stuff about Myth, MPlayer, LVM2 and multimedia in general that is really helping to polish my setup. Add to that the fact that I’ve been working on dvd::bend quite a bit lately, and getting some bugs taken care of, and things are really adding up. I also finally took the plunge last week and bought my first 750 GB harddrive. I’m up to 1.6 TB of space in my server now (5 harddrives in one box), and I haven’t even hit 50% capacity yet. I’m sampling a little bit from all my TV series and getting them on there, so I can at least watch something from everything I have. Eventually, somewhere down the road when I have lots more space, I’ll have everything completely archived. For now, I’m still experimenting and getting used to the setup. It’s getting pretty nice.

Here’s some of the cool little stuff I’ve found out recently.

mythtv custom menus

I didn’t know this til just the other week, but the design for the menu layout that Myth uses is all in XML files, and right there in the themes directories (/usr/share/mythtv/themes). That said, you can customize them all you want! Just read the docs, and you’ll be up and running in no time. It’s really simple. It took me just a few minutes to simplify my main menu so I can jump to the TV recordings and MythVideo really easily.

mythvideo gallery view

I’m really having fun with this one. There’s a few things I’d change, but for the most part it works great. Here’s what my layout looks like right now:

mplayer + xvmc + high motion

I just barely discovered this tonight. One of my frontends is a Pentium 4 1.6 gHz, which does plenty well. You really don’t need that much horsepower to play back video. It’s got an older nvidia AGP card in there which works just fine with s-video out. The only problem I have is that there is sometimes a slight stutter on the video with some high-motion scenes. I’ve actually started to get used to it, but then I found out that using the XvMC video out option really makes things much smoother.

At first I was just playing with it to see if I could get the CPU usage down. It was only dropping by about 10%, which wasn’t that great, especially since it was still running high … around 35%. Turns out I had cpufrequtils set to use the powersave governor, so my CPU was only running at 400 mHz. Whoops. I bumped it back up to full speed, and mplayer dropped down to around 10% total.

But, even then, at the lowest speed, the video looked gorgeous. I’ll admit it might have been my imagination, but those motion blur issues seemed to go away. I was so surprised by the results that next I ran it through the Star Trek test (which everything has failed), and played back some Deep Space Nine. Normally I’ll test TNG since I’m extremely picky about the video quality on that one, and I’ve seen them enough that I can notice video artifacts more easily, and this was only the 2nd time I’ve seen this DS9 episode. But, it still looked nice. I could notice some small amounts of blur, but it was pretty minimal. So, who knows, that solution might work well for everything. We’ll see. I’m feeling pretty optimistic about it, and at the very least it works great for my older TV.

mplayer + audio delay

Before that, I was taking a break and watching some A-Team. Great stuff. On one episode, the A/V was off just slightly. This has always plagued me in the past, and it’s one of the reasons I don’t bother with encoding files. Also, this has happened before on another Universal disc (of all the DVDs I have, they have the most problems … they are rare, admittedly, but that studio is still the winner). I remembered reading somewhere about adjusting the audio delay with mplayer, so I checked the man page. You just use + and - keys on the keyboard to adjust it by 1/10th of a second each way, faster or slower. Played around with that, and the A/V was back in perfect sync. So, I mapped my channel up / down keys on my remote to do that in case I ever run into that problem again, and now that’s all fixed too.

matroska saves the day, and disk space

This is another cool one I noticed last week. This is all anecdotal evidence, so YMMV, but I’ve noticed that Matroska files are consistenly smaller than AVIs. About 8% smaller, in fact. I noticed that quite by accident while playing around with some encoding files. At first I figured I had done something wrong, but the results proved the same after quite a few tests. That is a lot of overhead for AVI, sheesh. Just one more reason to love and use Matroska.

Seems like there was something else, but I can’t remember now. Ah well. Anyway, I was hoping to get all those random thoughts down sometime, so there you go. Lots of fun playing around with this stuff. I’m pretty blown away by how well it’s working and how polished the whole thing is getting. Once I’m done for good, I’ll be sure to document how to reproduce the entire step in detail. Good times.