I'm adding an ebuild for libbluray to the gentoo multimedia overlay if someone wants to access it.  It's something I plan on pushing into the mainline tree soon enough, once it's properly finished.

If you are building MPlayer from SVN, it will automatically detect the new library, and build against it.  You can use the -9999 ebuild in the portage tree.

To playback some of your Blu-Ray content, you will first need to extract it to your harddrive.  I use MakeMKV, also in the multimedia overlay, to accomplish that.

Here's a simple way using the CLI to dump the contents:

$ makemkvcon backup --decrypt disc:/mnt/bluray/ <location to dump content>

The syntax for playback is:

$ mplayer br:// -bluray-device <path to dumped content>

By default, it will play the longest playlist (I think).  If you can get the list of playlists available, you can pass that as an optional parameter to br:// (fex: list_titles /home/steve/bluray/src; mplayer br://5 -bluray-device /home/steve/bluray/src).

libbluray also ships with a few example programs that do basic stuff like listing the titles (list_titles), dumping information about the playlists (mpls_dump), and a few more (sound_dump, index_dump, mobj_dump, libbluray_test, bdsplice, clpi_dump).

Have fun with it.

I haven't found a way to embed this in my browser yet, but I haven't really looked either, so this is for all the CLI geeks.

$ mplayer $(youtube-dl -b -g http://www.youtube.com/watch?v=9IfEInQ7aic)

And thar ya go.

Oh, and did you know that Flash Gordon is on Blu-Ray now?  Flash!  Aaaaaa-ah!

Decrypting Blu-Ray discs is a really confusing process ... I'm still not even sure of all the steps that are involved.  Everything I understand has been cobbled together from posts on the doom9 forums.  While the forums are a great resource, it's not a comprehensive one at times.

I was playing around with aacskeys (from doom9 forums, available in portage), and it managed to decrypt / find the keys / whatever it's doing / work successfully on most of my movies.  I'm not sure how to get them off after that, though, or why that's important yet, but I do know it's a good sign.

For now I'm taking the simple route of using shareware to access my movies.  There's two programs I've used so far to rip my Blu-Rays, AnyDVDHD and MakeMKV.  They are both nice programs with some good features, but MakeMKV is the only one that has a Linux port.

The last time I tried MakeMKV, it couldn't decrypt all my discs, so I had to use my PS3 to rip the ISOs, and then use AnyDVDHD.  This time, though, using the most recent version (1.5.6), it managed to decrypt all of my discs.  I was going through my Blu-Rays to see if it could handle all of them, but I gave up after the 15th one, since it was working on every single one.

While AnyDVDHD will extract the original, unencrypted files to your harddrive, MakeMKV will additionally mux them at the same time into Matroska.  I kinda wish I could still have the originals, but I'm not going to be picky. (Edit: you can, see comments)

So, no real plans after this except to play around and post my results.  I really don't have that much interest in playing with Blu-Rays on Linux other than curiosity.  I don't wanna rip them and stream them to my HTPC just yet since I don't have the storage space, and because my frontend isn't quite as HD-ready as I'd like it to be (I still need to update some software and tweak settings ... lots of testing, meh).

I am going to be looking at some other tools and see if I can get them in portage or our multimedia overlay, which reminds me, I just added MakeMKV to there this morning if someone else wants to try it out.

Specifically, and I'm not picking on Ars in general, I notice in popular journalism a technique to claim that many people are supporting a view, but then to provide only *one* source that supports that view.  That doesn't mean that many people support it ... it means that at least one person does.

For example:

"Some critics of VP8 contend that its design is sufficiently similar to H.264 to warrant concern. One such critic is Jason Garrett-Glaser, a software developer who works on x264, a well-known open source implementation of H.264. In a lengthy analysis of VP8, he attacks On2's claim that the format is superior to H.264 and says that the format's legal status is too dubious for companies to trust."

There are no other references to "some critics" anywhere else in the article.

Again, here's a second example:

"MPEG LA's threats at this stage appear to be little more than self-serving saber rattling, but others who have analyzed the technology seem to believe that there could be serious patent risks on the horizon."

There is a reference earlier to MPEG LA's own remarks, the original piece of which makes its own conclusions as well.

Looking at that piece, the whole article is based around *one* question that he shared:

He writes:

"Here’s an excerpt from my email exchange with him:

JP: Let me ask you this: Are you creating a patent pool license for VP8 and WebM? Have you been approached about creating one?

Larry Horn: Yes, in view of the marketplace uncertainties regarding patent licensing needs for such technologies, there have been expressions of interest from the market urging us to facilitate formation of licenses that would address the market’s need for a convenient one-stop marketplace alternative to negotiating separate licenses with individual patent holders in accessing essential patent rights for VP8 as well as other codecs, and we are looking into the prospects of doing so."

That's the other thing I don't like about journalism ... I would call it a pet peeve, but really it's just a matter of not being able to trust the reporting when all we get is excerpts.  His entire article is written around one excerpt of an email exhange.  Why don't journalists ever post the entire exchange?  Lack of transparency, to me, just gives the impression that they are trying to present a biased view.

I realize, of course, that in only including excerpts here that I'm doing the same thing in a sense, but at least I'm providing references to the full sources I have available so that anyone else can do their own analysis and come to their own conclusion.

If you wanted to see his own conclusions, just read the article.  First of all, the headline is: "Google's "Royalty-Free" WebM Video May Not Be Royalty-Free for Long".  There's no way to draw that conclusion from the article.

I wonder if the editors come up with the titles of the articles themselves.  It  could easily have said "MPEG LA may create a patent pool for VP8", and that would be more accurate.  Compare that possible title to the other one when reading the author's assumption after the excerpt:

"It would seem, then, that VP8 may end up subject to the same licensing issues as H.264. If MPEG LA does create a patent pool license for the standard, the free lunch Google promised yesterday may not be free after all."

That's an obvious conclusion, and I could come to the same one as well -- If this, then that.

We can see again, even in this article, that he uses the same tactic of using one source and pretending it's many:

"As a number of observers have already noted VP8 isn’t free from patent liability."

Again, it's not a number of observers ... it's one blog post ... the same one that Ars referenced as well!  Jason is a great multimedia dev, but he's not a patent lawyer last I checked.  I'd be equally bothered if someone took my opinion, on any piece of my blog, and quoted me as the expert who knows which way the industry in Linux is going to go, or what legal battles it has to deal with in the future.

My take on the whole thing is this -- first of all, I thought Jason's original piece was very well written, and it was exactly what he set it out to be: a technical write-up of the codec.  He made some comments in passing about patents, but the focus of his post was how VP8 is better than Theora, not as good as x264 (and I would agree).  I would imagine that the poor guy didn't expect his blog post to get as much attention as it did, and that it will probably affect future blog posts, if any.

My opinion on the MPEG LA stance, reading just the excerpt above -- and not the author's own conclusion -- is that their business stance is completely normal and reasonable.  The way I read it is not that MPEG LA is claiming anything, but that some other companies might be wanting their own assurances of patent protection, and looking to their company to make sure they have their licensing ducks in a row.  That could be it, maybe not.  Either way, we don't have any information from them to really speculate.

Personally, I'm not too worried about the whole thing.  I think VP8 will emerge just fine, there may be *some* licensing involved somewhere, but in the end, open source tools will go on just like it has for years and support the standards, and consumers will still win out with more options.

As far as journalism goes, I think we're going to see more FUD pieces about the whole thing.  It's a common tactic used by big bullies (anyone remember SCO?).  I'm not saying the concerns are illegitimate, but I sure wish people would use critical thinking and analysis when writing their articles, instead of trying to spin up hype and paranoia for .. whatever reasons they may have.

It's obvious that my attitude is that modern journalism has completely lost its credibility, and that's the reason I don't like writing about it -- is because I get into rant mode. And I apologize for that.  Also, sorry that the post kinda bounces back and forth between my points ... it's the nature of a rant, I suppose.

One last comment (this is one of those posts that has the misfortune of never ending), that I wanna make sure I clarify is that it's not my intention to disprove, stir controversy or anything like that ... my only goal is to encourage critical thinking which seems to be a missing element in reporting these days.  I'm personally tired of how research becomes whittled down to conclusions.  It's like statistics -- you can often make the numbers say anything you want.  But, yah, not trying to hand out pitchforks or anything, I just think it's a good idea to be honest in reporting, present the facts, and let people come to their own conclusions.  That's all.   Have a donut.

I found a few bugs in my ripper this weekend, one of them was that I was only storing one possible subtitle type in my Matroska rips.  If a DVD had both VobSub and Closed Captioning, it'd only mux the first one I added.  Fixing it was fun, since it was one of those moments where you open up the code trying to find the reason for it, and you find a big comment labeled "FIXME: Add this feature here."  Heh.  So, now it muxes both, if available.  Woots.

There is still one DVD subtitle format that I am having absolutely zero luck in finding anything about -- English SDH (Subtitled for the Deaf and Hard of hearing).  According to Wikipedia, it's basically closed captioning with color.  I can play / watch / rip closed captioning just fine (watching: mplayer -subcc dvd://, ripping: ccextractor), but not SDH.  And I haven't seen anything that can even play them yet, although in fairness I've only been playing with Linux applications.  And everytime I try to explain to someone what I'm trying to do, they think I'm talking about VobSub subtitles.  Usually I get tired of trying to explain the difference and give up searching.  I could try finding some Windows apps to rip / play them, but if I can't get something in Linux that's scriptable to access them, then it doesn't matter anyway.  So, if someone knows of something ... plz to drop me a line, kthx.

Speaking of subtitles and MPlayer, I've come to the conclusion that MPlayer's support for them is just plain sub-par.  The options to play them back (or force them off) are buggy and inconsistent across the bar.  For example, here's a small roundup:

- Flagging a subtitle track as "default" when muxing a Matroska stream means that, if you turn on subtitles in the viewer, that should be the first one to show up.  It does not mean "these are forced subtitles, so display them automatically."  That's why Matroska has a "forced" tag.  default != forced.  If you're still lost, look at the original audio and video tracks, and you'll see they are also muxed with the "default" flag fipped on.  It's purpose makes more sense with video with multiple audio tracks -- if there's more than one, which one do you play by default?  The one with the "default" flag!  Same principle should apply with subtitles when you turn them on.

- MPlayer can't load Matroska subtitles externally.  You can, if you wish, mux just subtitle streams into a Matroska wrapper (ex: mkvmerge subtitles.{idx,srt} -o subtitles.mks).  But using "mplayer -sub subtitles.mks" won't work.  Bummer.   I understand that in this case, the Matroska stream could contain more than one subtitle stream (VobSubs and CC in my example), and it generally expects just one (-sub subtitles.idx, fex), but still, it'd be a fancy feature.

- MPlayer can't dump CC to SRT, even though it can play them (mplayer -subcc).  Bummer.

- Random rant about -noforcedsub and -nosub and -sub are conflicting / confusing, but too lazy to put together data about it, and it's mostly related to the Matroska one above.

I just had to get that stuff off my chest.   I have faith in MPlayer eventually improving in said areas, and filing bugs would probably be good on my part.  I generally don't deal with subtitles much anyway, so for me it's kind of a "would be nice to have" set of features.  Meaning, I've already worked around the bugs and they don't bother me as much anymore.  I would be curious to get SDH read support though.

I'm starting to notice a general trend here -- I complain a lot about certain issues and bugs in detail, but never go out of my way to report them.  I'm becoming the kind of user that as a developer I totally hate!  Oh noes!

In reality, I like being able to be on both sides of the coin, and I'd have to agree with the assessment of most user complaints I see, that are: the barrier to entry to reporting bugs is too hard.  I could go into detail about that, but I don't really want to, as I don't wanna focus on the negative.  But generally speaking, sometimes it's too much of a hassle to easily report a bug.  If it means me creating yet another user account on a bug tracker or subscribing to a mailing list, I weigh that against the strain of just ignoring or working around the bug.

I am, of course, to blame for my laziness, and I completely understand that developers (such as myself) need a detailed report with contact information along with the ability to quickly index reports.  I wonder if there's some magical middle ground, though, where users who aren't regular bug reporters can just easily report their issues and be on their way.  I know in Gentoo, we tend to use the forums as a poor-man's bugzilla sometimes, and maybe that's one way to do it.  Interesting stuff to think about.  Drive-by bug reporters, kinda thing.  They'll come by once or twice, but not regularly.

Anyway, I can't think of any other interesting DVD stuff I ran into this weekend.  Other than I bought season three of Taxi and it wasn't as entertaining as I remembered it to be.  Oh well.  You win some, you lose some.

So, the backstory is that the other day I was making a note of all the projects I have to do,  creating what I call my project tree.  It's basically an ordered list of general projects (Gentoo, home theater system, etc.), and then abstract projects underneath that.  It's nice because I can get a birds eye view of all the stuff I'm working on without going into specifics about any of them.  One of the home theater ones was to get at least ISO disc rips of the Blu-Ray movies I already have, even if I can't decrypt them yet, so I can at least play around with my options as they become available.

Well, I had moved my server setup around not too long ago, so I had two 750 GB harddrives just collecting dust.  I put one of them in an external USB drive, and plugged it into my PS3, which was already running Linux (see this pervious post for all the fun details).

I formatted my external USB drive as NTFS, so that I could read/write to it with Windows as well, and then I would insert a disc and just dump it to an ISO file.  That's easy enough:

$ cat /dev/sr0 > KFP.iso

I grabbed a couple of them (which took awhile, don't let me kid you on that part) so that I could get a good sampling in case I had more luck with one than another.

Once that was done, I trotted the little drive and plugged it into my netbook, running Windows XP, and installed both Virtual CloneDrive and AnyDVDHD.  The first one lets me mount an ISO as an actual disc drive, and the second actually decrypts the disc for me and dumps the contents back to the harddrive.  So, that's two passes now on all the data, which is making this take a long time.  But that's okay, it's fun.

Now that I have the actual contents, the MPEG2 transport streams, I can play it back with MPlayer, ffplay or whatever.  I'm having limited success with latest MPlayer on the files with VDPAU playback support, but it could just be my video card (GeForce 8600 GTS).  On my HTPC frontend, it works almost perfectly on there, with a nicer video card (GeForce 9300).  My desktop just craps out, though.  I can still watch it with Xv video out, though.

mkvtoolnix doesn't support m2ts files right now, so I don't have many options if I wanna change things around.  I'm still in a proof-of-concept stage, so I don't really care all that much.  Plus, my options are already limited.  AnyDVDHD is shareware that will expire in 21 days, and while it's amazing and works great, it's really expensive -- something like $200 for a lifetime license.  Eek.  With that, I'll keep trying my options on Linux.

The second piece of shareware I ran into (which also has a limited evaluation license, though this time for 30 days) is MakeMKV.  The Linux port is always a little more difficult to find, so here's a direct link to the details on the lastest version.  Boy, I never thought I'd be talking about shareware on my blog.

MakeMKV works really nice, too.  It's supposed to be able to do the same job as AnyDVDHD, I believe, but since I don't have the actual Blu-Ray drive, everything I've tried has never worked when just mounting the ISO direcly and trying to access that.  I believe that part of cracking the key involves having access to the drive.  I'm really not sure.  I've read a bit about the whole process, but it's still really confusing to me still.

Anyway, the software will let you access it directly through the decrypted contents, and that's what I did.  The interface is actually really simple and nice, and I would actually consider buying this one (it's much cheaper, at $50 for a lifetime license).  I'm trying to remember the last time I paid for a software license.  One that comes to mind, is that I actually have a valid registration key for Legend of the Red Dragon, the *really* old BBS door game.  Wow.  I think it cost me something like $15.

MakeMKV is pretty nice, though.  It snags the subtitles I select, and already includes the chapters as well as the HD audio formats.

So, that's it.  The whole process is pretty tedious, but it works, and I'm happy.  I don't really care about decrypting it *too* much right now, since I don't wanna go through the pain of trying to play them back over my HTPC just yet.  I'd need to do a lot of tweaks and upgrades to my system, and I really don't care that much.  It's not worth the hassle.  Especially, uh, since I just bought a new Blu-Ray player last month.

Really, though, I'm just doing this for the exercise since when I get bored, often times I'll want to play around with media files and formats and see what I can do with them.

Eventually I'll buy a BD-ROM drive and see what I can do, but for now I'm trying to save some $$$ and the whole point of this was to see if I could rip some discs with just the hardware available, and I could.   Woots.

On a sidenote, I posted aacskeys to the portage tree today, which is one of the tools users need to decrypt the keys on their discs.  Hopefully we can get some more hackers interested in poking at it.  That's always good.

Last but not least, here's an actual screenshot from the final rip.

I love TMNT.   Boy that's a post for another day ... which reminds me, I should get a copy of my home-made videos some day, that I made with my action figures.  Oh man, that'd be awesome.

I've been ripping my TV shows, and so far I haven't seen any really hard and fast rules on what to expect with them on DVD.   Part of the reason is that I just haven't been paying much attention to subtitles until recently.

I was playing with ripping one show last night, and I saw the CC logo on the back of the case, so I went to check the rest of my library to see which other ones had it.  Nearly my entire library of Warner Bros. DVDs displayed the logo -- even for much older cartoons (Looney Tunes, Scooby Doo) -- once again staying consistent with the fact that the studio puts a lot of effort into the quality of their releases.

I just started playing with extracting CC though, and just barely wrote the code to my DVD ripper to extract them, so I have no idea what the other series are like, if they have subtitles or not -- VobSub or CC.  I usually don't find out until I actually go to rip them.

Extracting the closed captioning subtitles is a lot easier and faster than getting the VobSub streams.  For Linux (and Mac and Windows) there's a nifty OSS program called ccextractor.  Once you have your VOB video file on your harddrive, just run that on the movie, and it will create an SRT subtitle file of the closed captioning text.  It's great, and really fast, taking probably under a minute on a 60-minute video on my box.  Comparatively, when ripping a VobSub stream, you need to read the DVD directly which causes its own bottleneck, and then demux the entire stream.  It takes probably around 3 to 5 minutes for an episode of the same length.

Another thing I like about the closed captioning titles is that because they are extracted as SRT, it's easy to look through them since they are just text files.  If you're really anal, you can correct typos yourself.  The VobSub subtitles are all bitmaps.  I've also noticed that on some DVDs, where there were issues with framerates or something else, that the VobSub timestamps will be off ... and sometimes either they will show up clumped together at the beginning of the film or the sync will be way off.  I think that this has to do with the dumping process, somewhere, but I'm not sure.  I've never really taken the time to pin down the source.

So, with closed captioning being easier and faster to extract, as well as editable and the timestamps haven't had any issues for me (yet), it's quickly becoming my preferred subtitle format.

There's only one small issue with using ccextractor, and that is you won't know if there are any captions in the VOB until after it's made its trial run.  The program will create an .srt file regardless when you run it, but the file will be empty if it couldn't find any.  That's the only drawback.  With VobSub, you can know if there are subtitles just by probing the DVD using lsdvd or something similar.

Muxing it into matroska is simple, too.  Just pass it as a file argument and you're done.

As a sidenote, while my bend application that I wrote and use to rip DVDs would be a major pain to setup for someone else, I've rewritten it recently so that it uses individual classes to access every object directly: DVD, DVD track, DVD VOB, Matroska file.  They are standalone classes written in PHP if anyone wanted to use them, feel free.  You would also need my tiny class of shell functions as well, since they all make calls to it.

The DVDVOB one makes it simple to extract the subtitle stream.  In fact, all the classes make things relatively simple.  They have made writing my code so much simpler.

The first step, though, was getting the PS3 to run Linux.  I took the shamelessly easy way out (and I don't regret it either) and installed Xubuntu.  I won't go into details about how I got Linux on my PS3 since that's well documented.  I will say that I remember quite vividly now why I can't stand binary distros.  Bleh.

The BD filesystem is UDF.  Providing you have a recent kernel (2.6.20, I think) with UDF v2.5 support, you are good to go.  I mounted a remote share and just dumped the disc to an ISO file onto my desktop.

$ cat /media/cdrom0 > wonka.iso

That was the easy part.

The hard part was trying to get it decrypted.  I had to use Java tools (bleh) to get to the source.  There are three applications you need.  And if you hate digging through forums and using download services, then I've got direct links for yah:

• aacskeys-0.4.0c.tar.gz
• bdvmdbg-0.1.5.7z
• dumphd-0.61.tar.gz

For Gentoo, you'll need to install the JDK to build the aacskeys library and binary.  I just emerged dev-java/sun-jdk and it worked for me (I know absolutely nothing about Java, but my stabbing in the dark miraculously worked).  You'll also need a runtime environment to actually execute the stuff, and I emerged dev-java/sun-jre-bin and that worked fine, too on my amd64 box.

For aacskeys and Gentoo, you'll need to apply this patch that I cobbled together from what I found on the doom9 forums to get it to compile.  It just fixes the Java include directorys for the Makefile.

Now, I'm still a bit fuzzy about what each program does, and whether you need all of them or not, so I won't go into a lot of detail.  What you want to use, though, is the dumphd program.  But to use it, you'll need to copy the aacskeys library and a file from the bdvmdbg package as well into the path or same directory as the dumphd program.

Once you have that, you can just run dumphd.sh and it'll fire up a simple little GUI telling you if it has all the libraries it needs.  Then you just specify the source and destination, and aacskeys will see if it has a working key to access the disc.

I can't really give much more detail than that, since I'm so new to this.  Suffice it to say, if you read the accompanying README doc that comes with each one, you'll get along just fine.

It took me a long time last night to get just one disc ripped and transferred over my subnet to try it out, and by the time I managed to get it mounted (mount -o loop -t udf wonka.iso /mnt/udf) and access it, it was pretty late.  The keys I had didn't work for my disc, and I didn't want to try the whole procedure over to try another disc.

Anyway, good luck if you try it.  One thing that impressed me is how much simpler it was than I thought it'd be, but what a pain it was trying to figure out where things went wrong.  The doom9 forums are a good resource, but not exactly the best place to find clear, concise information for a beginner.  That part was frustrating.

Personally, I don't think it's worth the hassle right now, the way I did it.  I'll get a BD-ROM sooner or later so I don't have to transfer the content over the network and can instead just test it directly.  But, I started out to see if I could at least get a copy of the ISO and get the tools running all without Windows, and I can.  So, that's progress right there.

Here's a snip of a sample ffmpeg output I generated last night:

$ time ffmpeg -y -i movie.vob -r 30000/1001 -acodec copy -croptop 60 -cropbottom 60 -s 720x480 -aspect 16:9 -deinterlace -vcodec libx264 -vpre hq -crf 15 -threads 0 movie.mp4

FFmpeg version SVN-r20371, Copyright (c) 2000-2009 Fabrice Bellard, et al.
built on Oct 25 2009 14:09:56 with gcc 4.3.3

Input #0, mpeg, from 'movie.vob':
Duration: 00:29:43.93, start: 0.280633, bitrate: 6492 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR 4:3], 9000 kb/s, 59.94 tbr, 90k tbn, 59.94 tbc
Stream #0.1[0x80]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
[libx264 @ 0x1c64530]using SAR=32/27
[libx264 @ 0x1c64530]using cpu capabilities: MMX2 SSE2Slow
[libx264 @ 0x1c64530]profile High, level 3.0
Output #0, mp4, to 'movie.mp4':
Stream #0.0: Video: libx264, yuv420p, 720x480 [PAR 32:27 DAR 16:9], q=10-51, 200 kb/s, 30k tbn, 29.97 tbc
Stream #0.1: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s

Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
Press [q] to stop encoding
frame=43411 fps=  7 q=-1.0 Lsize=  767982kB time=1783.95 bitrate=3526.6kbits/s

real    103m29.692s
user    155m46.121s
sys     8m0.649s

Which brings me to the second reason I don't encode stuff ... time.  Seven frames per second, on my fastest box at home, heh.  For a 30 minute video, it took a very long time.  The video looks great, though.  I can still notice a drop in quality when there is text or titles on the screen, but that's the exception.  The size was almost exactly 50% the original (1.4 GB to 750 MB).

The backstory for this particular video though, was that it was presented in letterbox, and I wanted to re-encode it so I didn't have to make a pan & scan config for just that file on my box.  So, I cropped the black bars off the top and bottom and resized it.

One small annoyance I have, is that all DVD source video always shows up as 59.94 frames per second when being probed by ffmpeg, and I have no idea why .... every single one of them does that, and it drives me nuts, since all the NTSC DVDs are going to be 29.97 or variable frame rate.  So, I have to specify to encode the new video to 29.97, otherwise, it will encode it to 59.94 by default and nearly double the size.

Also, I'm only doing a one-pass video encoding, ironically because I don't like waiting.

I have little interest in encoding my video, because my boxes are so slow, but at a savings of 50% in storage space, the idea always keeps me curious.  Unfortunately, because I'm so picky about quality, it takes a long time to find something that I like, and even longer to encode everything.  On top of that, I have little to no interest in buying a faster computer right now, so I just kind of shrug the whole thing off.

I can't deny that the video looks very nice, though.  Kudos to x264 and ffmpeg.

]]> http://wonkabar.org/2009/10/26/playing-with-x264/feed/ 2 http://wonkabar.org/2009/10/02/ripping-vhs/ http://wonkabar.org/2009/10/02/ripping-vhs/#comments Sat, 03 Oct 2009 03:23:31 +0000 Steve http://wonkabar.org/?p=1000 I don't think I've ever written about how to rip a VHS tape before, so I figured I'd write up a quick guide since it looks like that's part of what I'm gonna be doing this weekend.  Yet another item I've long had on my todo list was to get a digital copy of some really old tapes put out by my church, since they were never released on DVD.  Fortunately, it's really easy if you have a TV tuner card.

I'm using a Hauppauage PVR-500 card, which has composite inputs on the rear, and that's how I'm capturing the feed.  That good old analog hole.  Although, ideally, the Macrovision DRM shouldn't allow that, so don't ask me how it's working.

Anyway, it's simply a matter of switching your input to the component input, and then using ffmpeg to capture the stream.

To change the input, you'll need the IVTV utitiles.  In my case, the command is:

$ v4l2-ctl -i 2

Then, with ffmpeg, you can capture the stream, just copying it and saving it in its native format.  My PVR card does hardware encoding to MPEG2 video and audio, so I can just save it directly.

$ ffmpeg -i /dev/video0 -vcodec copy -acodec copy -t <hours:minutes> vhs.mpg

And thar ya go.  Pretty simple.

Here's a screenshot from an old church video.  As you can see, its slightly grainy, but that's because of the source, not because of the transfer.  It would look just as good / bad on the VCR player itself, so the conversion actually works really well.

Edit: I thought I'd add a bit more technical details as far as the MPEG encoder goes.

The video is MPEG-2, and the bitrate is 8000 kb/s.  The framerate is NTSC, of course.  The picture is 720x480 in size (my snapshot above is scaled down for presentation).

The audio is encoded to MP2, and it keeps the stereo stream.  The bitrate is 224 kb/s.

However, while Netflix is certainly the best contender right now, I think it's worth pointing out that the content is still in its infant stages.  Netflix can stream some movies, sure, but it's selection is not anything compared to say, iTunes, in regards to music availability.  One thing Apple did quite well was it got *all* the major studios to sign on to sell their music.  That means that you can expect to find everything mainstream right there without much difficulty.  Compare that to Netflix, who has *zero* major studios signed on right now.  Hopefully that will change, but everytime I see articles like the Wired one, that tout Netflix's library, I feel the need to clarify to people so they don't get suckered in.

For example, here's a quote from the article, "And the devices won't just be streaming remaindered basic-cable or art-house fare: Already, Netflix customers can call up just about any episode of SpongeBob SquarePants, The IT Crowd, or Lost whenever they like. They can watch recent releases like WALL-E and Pineapple Express. In other words, they can get unlimited access to the kinds of programming that previously required a cable subscription." (emphasis mine).

Just reading that, it *sounds* like Netflix is a drop-in replacement for cable access, which is not the case at all.  Rather than trying to read between the lines and saying something like, "Oh, they have everything between Wall-E and Pineapple Express", it's far more accurate to say "Oh, I can watch Wall-E *or* Pineapple Express."  The selection simply isn't there.

A few weeks ago, I bought my brother a Roku Netflix Player for his birthday (I'm such a nice guy, I know).  He has two small kids, and one of the main reasons I got it was because Netflix *does* serve up a lot of children's programming -- quite a lot, actually -- and I figured he would find that useful.  It's all available on demand, simple bookmarking, easy pause and resume, easy interface, etc.  I talked to him about a week later and one of the first things he mentioned about it was that there weren't hardly any new movies on there.

Right now, their only real provider for new movies is Starz Play.  If you have an account for Watch It Now, and want to find the new stuff, that's really the only place to look.  Plus, it's really hard to find stuff as well.  The website for browsing DVD releases on the Netflix site is amazing.  It's intuitive, it's quick and easy to search and find stuff, it's great at recommendations and it gives you lots of info in lots of ways.  Now, compare that to the Watch It Now navigation menus which are *completely* different.  My take on it is that there is so little content there, that they forcibly dumb down the interface to obfuscate the fact that there's really nothing there.  It's just taking the small amount they have, and spreading it around really thin so it looks like it's more than it is.

So, anyway, while I really hope that Netflix does the right thing, and business-wise, they are poised to take over the market -- Hollywood is holding them back.  I wouldn't blame Netflix in the least.  It's impossible to download *all* the new releases from any service anyway (from what I've seen).  For instance, X-Men Origins: Wolverine came out on DVD the other week, and I wanted to check it out.  I didn't really feel like going down to Blockbuster to get it, so I checked to see if any of my online pals were serving it up.  The Playstation Store had it, but you had to buy the movie, in standard definition, for $14.  No thanks.  Amazon's Video on Demand didn't have it, and neither did Netflix.  I realize that's a small sample to choose from, but there's really not many more services out there -- I think iTunes sells / rents new movies now, but I don't have a way to watch them on my TV anyway, so I didn't bother checking.

Once Hollywood gets on board, then things will really take off.  I read in the news how Blockbuster isn't doing well, and they are the last legacy distribution market.  I kind of can't wait for them to stumble, because if they are gone, the studios will have no other medium to even sell / rent new movies through, except through newer, leaner retailers like RedBox, Netflix, and on demand services.  The future can't get here fast enough for me.

I spent a few hours last night digging through the code, trying to find out exactly how the code is operating and what it's doing. What I learned was that, well Myth was doing exactly what I thought it was -- it builds a file list upon first entering, and then it doesn't examine it at all until you re-enter the video browser through the main myth menu. (I wish I had a decent screenshot about now, it's a bit confusing if you don't know what I'm talking about.)

There's a couple of problems with this approach, in my mind. First of all, the time it takes to actually load the mythvideo plugin grows in relation to how much media you have that it needs to parse. That is, it iterates over *every* single file that is in your media storage, and adds it to one variable. It's essentially like running find on your filesystem, saving it into one variable, and then when browsing, just using that snapshot that you took.

The simpler way, in my opinion, would be to just refresh the directory structure and metadata for the directory you are in. While I was poking at it, one thing I tried was to get the directory scan to not go more than one level deep. That reduced the startup time from about 8 seconds to less than one. Nice.

Ideally, I'd like to change it so it just updates the directory scan as it enters a new one, progressively growing the variable as you jump around the directory tree, but I couldn't figure out how to do that in the code (and if someone wants to help, that'd be awesome). MythVideo calls fetchVideos() only when first entering, and not anytime after that. The real problem is that it in turn calls about eight other levels of functions that eventually get to scanning the directory tree. I could probably hack it together to pass the current directory I'm in and update the directory scan from there, but again, I'm so limited in my C++ skills, at this point it's just code and guess. So, I can find and explain the problem, but not fix it myself.

Fortunately, it's a minor wish list item of mine, and so it's not a show stopper. I can live with not being able to do it, and it's probably just a matter of me learning how to code a bit more that I could figure it out. On the plus side, I'm learning more about the internals of the code, and each time I go in there, I find a few small inefficiencies that I can cleanup myself, which is fun. Making progress, I suppose.

The simplest way I'm dealing with it now is just rip the DVD and use MPlayer to play it back correctly. I only need a few switches, and I'm done.

There's two ways to deal with it. The first, I just crop it myself with this:

$ mplayer -vf crop=704:352:8:64

Here's a before:

and the after:

You can't tell from these since I had to rescale them for the blog, but the second one was slightly less narrow than the first by a few pixels. Can be a bit of an annoyance.

The second way is much simpler.

If you're playing back on a widescreen monitor, just do this:

$ mplayer -panscan 1 -aspect 4:3

And it will frame it perfectly.

The coolest thing is that two of my patches got submitted upstream, one for mplayer, and one for ffmpeg.  In both cases, they needed to be changed a bit, but I'm still happy with the results.  The ffmpeg one was the patch I wrote about previously, to have the LAVF demuxer pull out all the metadata that's in the Matroska container.  That's in there as of revision 19184.  Thanks, aurel.

There's no way currently of cleanly pulling it out of MPlayer for display, though my hack works just fine.  The demuxer for mplayer needs a new function to iterate through all the metadata that's available, and add it to the demuxer info.  Currently, it's only pulling out a few named keys specifically.

Here's a screenshot of how it looks where I'm pulling it out, in this case I'm just using it as an OSD menu screen display.

The actual documentation on how to access the OSD menus and work them is pretty non-existent.  I'll try and write some up and get it submitted when I get a chance.  In the meantime, if you want to see what my menu configuration looks like, have at it.  I haven't cleaned it up at all.

I'm too tired to lay this down in story format, so I'm just gonna dump it out best I can.

The other week, I noticed that a new version of mkvtoolnix had come out (the tool to mux audio/video files into the Matroska container), and it totally flew under my radar. I started playing with it, and noticed some real improvements in speed, with regards to parsing MPEG-2 video. After playing around a bit, I started reading some more of the documentation, and found out about this excellent tagging system that the specification declares.

You can read all the gory details about it here, but basically, when building a Matroska file, you can create an XML file that has global tags that can store pretty much every metadata tag I could ever dream of possibly wanting.

I never really had the itch to pack much metadata into the container up until this time, when I realized just how much factual data I could stuff in there and not depend on the database for. Pretty much the only thing I really cared about was the title. In fact, all I wanted originally was to be able to get MPlayer to display the metadata title that was in the file.

Going off on a tangent here, I poked an open bug I have on MPlayer's bugzilla, and Reimar, an mplayer dev, was kind enough to oblige me once more and updated the code so that I could pull it out. If you're using a recent snapshot (for Gentoo, the 20090530 one has it), you can pull it out using "get_property metadata/title" in slave mode. If you wanted to display it on-screen, you would map a keypress event or LIRC event to this: osd_show_property_text "${metadata/title}". Quotes and all.

Anyway, Reimar added that in for me (thanks, man), so I started poking around with mplayer's features to see what else it could pull out for me. Now that I was going to be storing lots more data in the container, I wanted to be able to pull it out, too.

Jump forward a bit to today, where I woke up this morning and was determined to get it out somehow. My original plan that I had decided on was, since I can't really hack on C code, to just work around the limitation by using a fifo for mplayer. I'll spare you the ugly details, but basically I was going to have an event send a command to an external script that would query the .mkv file for the metadata tag I requested, and send a command back through the pipe to print that out to the screen. Quite a run around.

Well, I've tried before to grep the code of mplayer a bit to see if I could wrap my head around the stuff and see if I could figure it out for myself, but it hasn't worked out real well. I decided to give it another whirl today, though. This time, however, my approach was a little bit different. Normally I would just search for keywords where I *think* mplayer would be doing what I would think it was doing, tinker with the code, recompile it, run it, and see what it does. A really slow process, but sometimes it works. And I really don't mind spending the time on it, either.

This time, I did things a little bit differently. I found a file where I was sure that it was accessing matroska metadata, and I read the entire thing, and took copious notes, explaining to myself the whole time, basically what I thought the purpose of each major element was, trying to figure out the pattern to this. Now, bear in mind, that I'm still learning some C++ myself, and the C syntax is pretty similar (in fact ... I still can hardly tell the difference, myself), so a lot of times I have a vague understanding of what it *might* be doing, but never enough to be sure ... so there is still a lot of guesswork involved.

Anyway, after about 10 hours of going back and forth, making notes, testing code, printing out functions and variables and metadata, I got it figured out. And the final patch is something like 2 lines long, heh. All I did was add one if statement. But, that was enough to get me going, and it solved a nagging issue for me. But, what is far more valuable, is the fact that I've learned how I can go into this code and figure out how to fix things myself. That's gonna really come in handy. I'm sure I won't be submitting patches upstream anytime soon, but if I can get what I want hacked in there, and working, I'll be happy as a clam.

For the record, the problem with the metadata was this: MPlayer has a single key=value pair that it assigns to metadata values with it is parsing it with the libavformat demuxer. That is normally well and good, except in the case of Matroska, the tags can be nested with similar names.

So, for example, say you have two target tags in your matroska container: Collection and Episode. If it were a TV show, let's say it's CHiPs. Great show, btw. Now, in the tagging specification, both of them can have a title. The title for the collection would be CHiPs. If you had a Matroska A/V file that was just one episode, then the title for that would be "Ponch Delivers A Baby on the Disco Floor" or whatever (which really does happen, I kid you not). They key for both of those would be "title", but the values would be different. The LAVF demuxer just overwrites the old value and assigns it to whatever comes last. Kind of a problem.

So all I did was told the demuxer to prefix the key names with whatever the name of the target tag was (Collection, Season, Episode, etc.). That way you can have distinct key value pairs, but they are just more verbose. The metadata property names now are metadata/collection/title instead of metadata/title. Pretty simple, really.

That was the easy part. The second part, I haven't figured out yet -- how to get it out. The metadata is all in a separate object created by the LAVF demuxer, which I don't know enough C to figure out how to access that outside of that class. So, I just hacked it to add it to the metadata myself in a rather ugly, but working fashion. Upstream probably wouldn't be interested in that patch.

Another hard day's work, and I'm still not done. And I've got a lot more to write about it, so I'll just stop here for now. I'm gonna go port the patches to my frontends.

Edit: For reference, the clean version of the patch, a sample XML file of what I would mux in with an episode, and the ugly hack I personally am using to get it all out where my lack of C knowledge is very much publicly exposed.  Note that you have to use -demuxer lavf with mplayer for it to work.

Usually I would avoid going into the code, but I'm slowly getting more comfortable doing it.  I think the Qt3 docs could stand being a tad bit more verbose, though.  In a lot of cases where I was confused, it was a matter of not understanding exactly what the function was returning, and I'd have to execute it myself to figure it out.

Aside from that, all the "original" stuff is in, but I found two more bugs that I want to hunt down.  I thought I had this first one licked, but I guess not -- if you have a file on the filesystem that is not stored in the database, then it will display the filename sans extension as the title at the top of the page (fex: Mr._Belvedere).   I've already fixed it so that it will show the "correct" title (replace _ with spaces) when displaying the grid of all files, but I can't seem to find the variable where it's showing the other title and it's a little hard going through the code trying to figure out what everything is doing.  I haven't figured *that* much out.  In fact, I know my way around just a few functions in videogallery.cpp and that's about it.  Once it gets outside of that, I'm back in Wonderland.  I'm lost.

Add on top of that there's not much documentation, if any, in the code and it makes it a bit of slow going.  Ah well, it's only a matter of time most likely.

The second bug is really annoying, and it's interesting in that it's one of those phantom ones that was always like ... "wait a minute, did something just change?"  There was a nagging feeling that something had changed, but I could never pin my finger on it.  I finally found it.  What happens is, when MythVideo has scanned the files and put the metadata into the database, it will do some kind of intelligent sorting based on the titles for display.  That is, titles prefixed with "A", "And", "The", etc. will have the prefix dropped (can't remember the correct grammatical term for those) and then sorted by the following words in the title.  I only caught it because I had added an MP3 file for the LP of "A View To A Kill" (and yes, there are children's records that tell the story of the 007 films -- how cool is that?) and I was testing some stuff in that folder and actually saw it's position change before and after it was put into the metadata database.

That one, I have absolutely no idea where it's getting sorted at all.  I don't have a clue, and it could be anywhere, since all the MythVideo displays implement that, not just the Gallery view.  I just need to send a note off to the mythtv user's mailing list and hopefully someone will know.  That would be nice to get rid of, though.  I don't like the inconsistency.

In fact, I never use the metadata database at all.  Pretty much all I see is the cover image, which I supply manually, and the title.  And I rename all my videos so that the title is part of the filename, including the episode order for the ones that are a part of a series.  I already ripped out the stuff to display the metadata before playback, since I'm not interested in that.  So, I know that it's somehow related to the metadata database, since the titles *and* the orders are affected once they are in there.  Just gotta figure out where.

Other than that, everything has gone really smooth, and it's been nice.  One thing I did notice as well was that 0.21 just seems generally snappier and much more responsive.  It could be my imagination, but I don't think so ... there just seems to be less latency and wait when navigating and moving around places.  It's pretty nice.

Normally, the process wouldn't be hard, except that I've built a custom image that is running on a solid-state flash disk that is only 256 mb in size. And yes, it's Gentoo. It doesn't have a full blown Gentoo install, of course, but it's certainly a very stripped down version of one. I've had the image on there for probably a year and a half or more, and have been extremely content to just leave it alone as it works just fine.

As time goes on, though, I've been hacking on MythVideo a bit here and there, adding a few tweaks to suit my needs. This weekend I finally got another navigation one hammered out that took me a few hours to figure out due to my lack of C++/Qt programming skills. It was worth it though -- it was one annoying UI decision I didn't like (I won't go in details, but it's how the menu position is selected when navigating back and forth through the video gallery).

The problem is that making any kind of changes to the Mini's image is always a pain for a couple of reasons. For one, if I screw something up badly, it's a bit difficult to get into the box. I don't have a USB bootable stick laying around, and in fact I've never had much luck getting one to work .. and I don't think this box will boot off of one anyway. Not sure. That means if something really goes haywire then I have to boot over the network, which is a bit of a pain to setup sometimes. Fortunately, it didn't come to that this time.

Another issue is that because space is so limited, part of the filesystem is loaded from a read-only squashfs image. That means a bit of tedious testing when it comes to unpacking the image, removing the old files, adding the new ones in place, repacking it, remounting it, and restarting the application each time just to test anything. That adds a lot of time to the process.

This time around, I did something pretty smart, in my opinion. I don't know why I didn't think of this before. The squashfs image is loading /usr/lib. This time, I installed Myth to /usr/local so that I could leave the libraries alone and replace MythTV easily. Just create a new image for that one, and drop it in anytime.

Anyway, tonight I just barely got it working with the new install. I went from a very old 0.20 install to the latest 0.21 in portage (0.21_p19961). In fact, one of the reasons I had to upgrade is because I can't even get 0.20 to compile anymore. Normally I wouldn't care, but I figure I may want to write more patches, and it's getting to be painful trying to maintain an older version that I can't even duplicate in case of a problem.

One other nice thing that's changed since I last built this is I have my still-somewhat-newish ThinkPad to build it on. So I just build the binaries on my x86 laptop, strip out all the crap I don't need or want, create a new squash image, and drop it right in. Relatively speaking, it has all gone rather smoothly. I think I've probably spent about 20 hours on it since Sunday. I vaguely recall it taking at least two weeks the first time I put it together. And of course, it took me something like three months to even get X, Qt, LIRC and all the other stuff on such a small bootable image. That was a really bumpy ride, but I wouldn't trade the knowledge to do it for anything.

That's the other thing -- I could *easily* spend less than $20 and get double the harddrive space (512MB) and be able to forego half the problems. Or, I could even spend another $20 and get a 1 or 2 GB drive and have a *lot* of room to play around in. Oddly enough, I'm really going against my normal approach and instead of throwing money at the problem, I'm taking it as a matter of pride that I can endure so much pain and still get it on such a small drive. And really, I don't need the extra space anyway. Once it's done, it's done and done. It'll be just like before, where I'll leave it alone for 18 months or more, and I'll be completely happy with it the whole time.

Just for the record, here's the harddrive current status. I managed to clean up a lot of cruft this time around and freed up a lot of space:

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             238M  184M   42M  82% /
udev                   10M   60K   10M   1% /dev
/usr/usr.lib.img       36M   36M     0 100% /usr/lib
/usr/usr.local.img     18M   18M     0 100% /usr/local
shm                   474M     0  474M   0% /dev/shm
svcdir                2.0M  116K  1.9M   6% /var/lib/init.d
//willy/media         1.4T  624G  726G  47% /var/media

And finally, here's what the menu currently looks like ... still unpatched, and with the default theme. That's for another day. I'll cover what the patch changes, too. Someone may find it useful. In the meantime, I think it's time to try and catch up on sleep.  I'm really tired.

Oh, and those icons are from the gartoon theme set.

I just added a new ebuild to the tree this week for MPlayer, which has support for the much talked about VDPAU which comes with nvidia video cards and binary drivers.  If you don't know what that is, it is probably most simply described as XvMC for more codecs: MPEG1, MPEG2, MPEG4 (H264), WMV, VC1.  The player offloads a lot of CPU decoding to the video card instead of your processor, meaning cheap video cards and cheap computers can playback HD without any hiccups.

In theory, at least.  I don't know how well it works since I haven't been able to test it much, and whenever I do, I can't get it under 50% CPU anyway.

Anyway, you are free to try it of course.  The latest mplayer ebuild is 20090226.28734.  The naming scheme changed to reflect both the release date of the snapshot (Feb 26 2009) and the SVN revision from upstream (28734).  There is a "vdpau" use flag you'll need to enable on the ebuild, and you'll need  v180.22 or higher of nvidia-drivers.  In this case, nvidia is releasing updates with new drivers, so the more recent the better.

Here's some cool stuff to read about VDPAU and what it can do:

NVIDIA 180.35 Driver Update Brings Changes

HD Video Playback With A $20 CPU & $30 GPU On Linux

Wikipedia entry

MythTV Wiki: Supported Cards

nvnews forum thread: mplayer and vdpau - see the third post for samples to test and mplayer command lines.

Oh yes, using it is pretty much a matter of mplayer -vo vdpau foo.wmv.  You may or may not need to use the -vc argument.  I haven't looked closely.  See "mplayer -vc help | grep vdpau" for a reference, or the man page.

As far as the mplayer ebuild goes, there have been a lot of changes.  I'd been queuing them up for a good while waiting to push them live.  I had hoped to have a finished document accompany the release, but I haven't given much time to it, and since VDPAU came out, I figured it would be better to release the ebuild.

It's currently masked, but won't be for long.  One nice thing it does is it splits up the real use flag into two: real and realcodecs.  I found that some users were confused and thought that they had to enable the realcodecs use flag to get any support for real codec playback, but that was never the case, as libavcodec always had support for some.  Now, the real flag will enable the internal support, and realcodecs will still use the external binary ones (not recommended).

Also, since libdvdnav got accepted into the mainstream build, we no longer have to rely on a masked, external dependency, so the dvdnav use flag is unmasked, available, and enabled by default.  You can playback DVDs browsing the navigation menus by using mplayer dvdnav:// instead of mplayer dvd://.

Other use flags that were added were faac, faad, and tremor.  If you want native support for AAC playback, just enable the aac use flag.  If you want to use the external libraries instead (faac and faad), then just disable the aac use flag and enable the other ones.  Tremor is the internal support for Vorbis playback.

The last change to the ebuild is that now lots more use flags are enabled by default.  I found out that a lot of people were going in #mplayer complaining that their builds weren't working when really it was just not compiled with much in it.  As a result, I've changed it so it will enable just about every internal library and external codec.  That should make things simpler for users who want things to "just work" out of the box.

That's it for now.  I'll be bumping the ebuild again, soon, and regularly as long as the VDPAU development in mplayer keeps moving at a hectic pace.

The only thing I use it for is a GUI interface to browse folders, display thumbnails of folders and files, and playback whatever I pick.

There's gotta be something simpler out there, though I imagine I'll probably just end up writing my own.

Now what's a good easy GUI development library that wouldn't be hard to learn?

Here's the board I got: an MSI IM-945GC.

Just looking at it, it doesn't look like a good board for multimedia playback at all. It doesn't have SPDIF, S-Video, Composite, Component or HDMI ports. Just VGA, stereo jacks, PS2 ports and three COM ports. Woots. But, it is stocked with lots of cool stuff.

The processor is a dual-core Intel Atom. Dual-core! That's just amazing, and the first I've seen. I would normally be hesitant to go from a VIA C7 chip (which is what I already have) to something else, but my netbook also has an Intel Atom CPU, and it runs surprisingly fast. This thing also runs at 1.6 GHz, which is the fastest that I've seen, and still fanless. The next thing that even comes close to this is a VIA C7 1.2 GHz single core that is also fanless. So, this thing is gonna rock.

Because it's using an Intel chipset, that means that the onboard video is also Intel's. It's got a GMA 950 onboard, which means I'm not gonna have to worry a lick about the graphics or OpenGL. My only complaint in that area is that, like all onboard video cards, it uses shared memory which I'm not a big fan of. But, the picture will look really gorgeous.

Despite the lack of media ports, there's still other reasons why I got this thing. It has a PCI Express Mini slot on it, which means I can get a wireless card and stick it in there and it'll rest on top of the motherboard. It also has a PCI slot so if I really want to, I can get a different video card in there. I doubt there are any PCI ones with HDMI, but I do know you can snag one with S-Video.

Perhaps most importantly, though, this thing supports 2 GB of RAM. I had a really hard time deciding on which features I wanted the mobo to have, and when I finally listed features by priority, this one came out on top. My current Mini only supports 1 GB, and while that's sufficient, I'm more in the market of making sure I can future proof this thing as much as possible. The harddrive will be a SSD flash module that plugs into the IDE port, and I'll run it in readonly mode using ext2 with no swap. I'll have a small partition for /var so that I can write temporary files, but that's it. Everything is going to use RAM, and that's it, so I want to make sure my option is maxed out.

Another great feature is that this thing also has two gigabit NICs on the back. Plus, there are four USB ports, all 2.0. I'm really excited for this board. I think it's gonna be pretty fast. The CPU also supports hyperthreading, so it'll look like I have four cores in there.

I decided to go ahead and forego some of the other media ports because I don't see me wanting to use them anytime soon. Or, by the time I want to, I'll probably want either a better motherboard or a completely different delivery option by then. Both of my mythfrontends are used primarily to playback TV shows and casual movies that I just feel like watching. They are not intended to deliver an amazing presentation, such as duplicating a great picture like or surround sound. When I want the best quality, I'll just pull out the DVD and turn on my receiver. But that doesn't happen very often. My HDTV that I'll be hooking this up to has a VGA port on the back, and so that's all I needed. It also has a stereo input jack, so I can just run an audio cable straight in without any fuss. The low quality playback solution works perfectly since 90% of my content is old and in stereo to start with.

This thing doesn't come even close to being able to handle an HD stream, and I'm totally cool with that. As strange as it may seem, I am an incredibly slow adopter when it comes to new technologies, and in cases like this I get extremely stubborn and stick with what works for a long time. That does have one advantage to it -- by the time I do get around to working with something, it's not in alpha or beta stages anymore, and I can usually do what I want without much of a hitch.

I'm just now barely starting to warm up to BluRay just a little bit (another post that I need to write about) ever since seeing some actual quality films. I only have three films at home -- the first three Harry Potters -- only because I got them at a great deal at Amazon ($40 for all three) and I bought them just so I could have *some* source material on hand to see what its like whenever I get the urge. Movies is pretty much the only thing I would care about when it comes to HD anyway, and since almost all of my time accessing the mythfrontend is watching TV shows from the 60s to the 90s, HD isn't even a variable, and it won't be for a long time.

So, I'm really excited to get this thing. My old setup was working perfectly well, and I just barely took it down last night. Right before I did, I looked at the uptime to see what it was at -- 141 days. Freak, that's over 4 months that this thing has been working without a hitch. I'm pretty proud of that.

This time around I bought a bigger flash drive. My old one was 256 MBs. Yes, megabytes. I had a job a few cycles ago developing an embedded multimedia operating system (based on Gentoo, of course) which is where I learned everything. The job or the company didn't quite work out so well, but the experience was a great learning one. The OS that is running on my current Mini is completely crafted from an extreme amount of TLC. Every single program that is on there has both been modified to cut out cruft and save space, and optimized where possible to run faster. I did not have any space to play with, and when you need X, MythTV, Qt3 and glibc you gotta really learn to squeeze. It is quite possible though. In fact, I think my image is closer to 180 megs in space total, after using SquashFS.

The amazing part is how responsive the thing is. Since everything was nicely tweaked, it seriously feels like I'm using my dual-core amd64 desktop because it is so snappy. In some cases, it is more responsive, the latency is just so low. There are a lot of shortcuts you can take, though, mostly in the kernel ... such as not dumping anything and turning off a bunch of other stuff you wouldn't dare do anywhere else, but building for embedded is so amazingly fun. Plus there's just nothing cooler than knowing it runs with such an small footprint. I highly recommend Building Embedded Linux Systems, Second Edition from O'Reilly if you are interested in doing some of the same. It's a lifesaver. And, of course, I recommend using a source-based distribution like Gentoo because it will help you to very easily trim down the fat and get only the bare essentials on there.

I bought a new flash IDE drive along with the new motherboard, and this one is 4GB in size, so I'm not going to have to ever worry about size. I'm not sure if I'll create a new custom build for this one as well or not. It was a lot of work getting the first one done, but a great learning experience. It reminded me a lot of when I first started installing Gentoo years ago, because up until that point, I thought I knew a lot about how things work together. There's nothing quite like getting into every single program you install in your OS and digging to see if you really need it or not, just trying to save an extra 59kb to 4MB of space. Good times.

Anyway, I'll be sure to take some pics of the new one once it gets here. I already started taking some of my old one, as I'll have to dismember it a bit and move it to a new case. I might end up replacing that one as well, since it's starting to fall apart a bit. I'm not sure I could go through the decision making process again, though.

Edit: leio-dl was asking me in #gentoo-dev why my image was so large, so I dug up a list of all the packages that is installed on the image, and here it is. 180 megs for an embedded image is actually really huge, but mine has a lot of stuff.

Edit #2: Er, just looked a bit closer. Main image is 97M, and then I have /lib in a SquashFS image which I think is about 40M, so it'd be closer to 130 total than 180.