A Django site.
June 17, 2009

Steve Dibb
beandog
wonkablog
» mplayer and matroska metadata, part two

Man, what a week it has been.  I have been plugging away at a lot of stuff, and the bug to get my whole media setup tweaked even more has really bit me bad.  I've been working on nothing but for a while.

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.

June 7, 2009

Steve Dibb
beandog
wonkablog
» mplayer and matroska metadata

I've been playing with Matroska in general a lot more, seeing what I can do, and in the past week and a half, I've found some really cool things. I'm completely braindead after staring at the mplayer code all day, so if I come across a little confusing, now you know why. It's one of those instances where I wanna get this documented though, if nothing else than for a small marker of a pretty big milestone for me. :)

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.

February 27, 2009

Steve Dibb
beandog
wonkablog
» mplayer and vdpau in portage

I was hoping to write a lengthy post about VDPAU support for MPlayer in the portage tree, but since my harddrive crashed this week and I'm still recovering from that, a small announcement will have to suffice for now.

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.

January 23, 2009

Steve Dibb
beandog
wonkablog
» mplayer patch: -use-dir-conf option

I just made a really small patch to MPlayer for something I’ve been wanting to do for a while. MPlayer has long supported a playback option -use-filedir-conf that will include a config file if you have it named <filename>.conf. I’ve taken that and just created an option for the current directory instead.

The issue I run into with my TV shows is that sometimes I need to use different deinterlacing filters or different audio delays for different series. It would be a pain to create a config file for each individual file, so this patch fits the bill. If you just use -use-dir-conf, it will look for an mplayer.conf file in the existing directory, and include that.

Pretty simple, really. I hope I wrote the patch right, since I’m no master of C. I just copied the old functionality, dropped what it didn’t look like was relevant and removed unused variables. And hey, works for me.

Patches cleanly against latest SVN (28348).

Edit: Well, crap, I just realized that it only works if you have mplayer.conf in the same directory as you are running mplayer from …. so doing mplayer -use-dir-conf /foo/movie.mp4 wouldn’t work if you’re not in /foo. Unlike -use-filedir-conf, you can’t call it from some other directory. Someone wanna help me out? :)

January 10, 2009

Steve Dibb
beandog
wonkablog
» mplayer, real support, part two

I just put a new mplayer snapshot (mplayer-1.0_rc2_p28288.ebuild) in the portage tree. This one, adds support for RV30 native playback.

RV40 was added in the previous one. Thanks, Kostya. :)

For some samples, see:

http://samples.mplayerhq.hu/real/VC-RV30/

http://samples.mplayerhq.hu/real/VC-RV40/

Have fun watching those old Paula Abdul videos. :)

December 16, 2008

Steve Dibb
beandog
wonkablog
» mplayer-resume-1.6

I just finished updating and pushing mplayer-resume-1.6 into the tree.  I’ve actually been sitting on the update for a long time, just never got around to releasing it.

There has only been a small change — the script will check mplayer’s exit code to see if it died on something.  I added it since I hit a bug on my frontend where some files wouldn’t resume, and it would delete my resume point anyway.  Kind of annoying.  This update fixes that, and really, that’s it.

December 2, 2008

Steve Dibb
beandog
wonkablog
» mplayer, dvdnav support

Oh yah, I remembered what the other thing was on MPlayer — dvdnav support is back in.  Duh.  How could I miss that one?

The use flag is masked, so you’ll have to unmask it to use it, but if you do it will pull in the forked libdvdnav and libdvdread as a dependency.  After that, you can use mplayer dvdnav:// to get funky, sexy menus when watching DVDs.  Whee!

Here’s how to unmask a use flag:

mkdir -p /etc/portage/profile/

echo media-video/mplayer -dvdnav >> /etc/portage/profile/package.use.mask

Then just set enable the dvdnav use flag for the package as normal.  Personally, I like flagedit.

flagedit media-video/mplayer dvdnav

» mplayer, real support

MPlayer got bumped yesterday to a new snapshot (1.0_rc2_p28058), which isn’t all that interesting in itself, but there is one notable update for real codecs.

I’ve been busy masking realplayer support in portage due to issues, but libavcodec now has it’s own native decoder for RealVideo 4 (RV40).  Thanks, Kostya. :)

Read about it here:

Mike summarized it pretty well on his blog post:

“Also, do you dare ask why this is useful in the grand scheme of multimedia hacking? Seriously? Have you not learned by now? While it may be true that absolutely no one likes Real or their formats, there is still a huge legacy of media in the wild encoded in their formats, media that will need to be manipulated for many years to come.”

One other thing that got fixed in MPlayer that naturally only I and very few others are going to care about, is that mplayer dumpstream now supports ending chapters again.  It was removed a while back and readded recently.  It was pretty much the only reason the 1.0_rc2_p24929-r4 ebuild is still in the tree.  A specific example would be that you can do something like this: mplayer dvd:// -dumpstream -dumpfile movie.vob -chapter 2-5

Seems like there was something else that changed.  Can’t remember now, oh well.

October 6, 2008

Steve Dibb
beandog
wonkablog
» weekend multimedia notes

I’ve been spending part of the weekend working out small annoyances in my myth setup, trying to get it inching closer to my “perfect” setup.  I’m actually really close now, minor stuff is all that’s left.

Here’s a few things I want to remember as a point of reference, that took me a bit of research to figure out:

Printing options in MPlayer:

mplayer -list-options <command line arguments>

mplayer -input cmdlist <slave mode commands>

mplayer -input keylist <events>

Mapping Page Up and Page Down with my remote in MythTV:

begin
prog = mythtv
button = ch+
repeat = 3
config = PgUp
end

begin
prog = mythtv
button = ch-
repeat = 3
config = PgDown
end

Finally, I hit some snag with MPlayer and VobSubs (subtitles that originally come with DVDs).  I’ve got some movies in Matroska format, and with recent (SVN r27719) revisions, it will forcibly display the subtitles on playback, and I have no idea why.  I swear I remember reading something about this on the mailing list a while ago, but I haven’t had much luck finding anything.  Best option so far, go back to an earlier revision (r25993).  Not ideal, but it works.  Every sub, force and vobsub option I’ve tried does nothing.  I’m not passing anything by default like -slang or -sid to mplayer.

Another thing I’ve been working on (I’m really bored) is finding posters for the cover images in my movies folder.  Which got me looking at UK quad posters.  If you haven’t ever seen the posters from across the pond, they are so much better than our American counterparts.  They are a horizontal landscape, which allows for, in my opinion, a much more dramatic picture.  Check out this Star Wars one, for example.

It just looks so much better, in my opinion.  I gotta get some movie posters up on my wall (only two so far: Tron and The Adventures of Milo in the Phantom Tollbooth), and I’d love to hunt down some quads.  The old school Disney ones look even awesomer.

Speaking of cover images for Myth, I have a new patch I cranked out last night, which has an interesting story to it.  I’ll post details later, though.  I’m not in the mood for details right now.  I’m more about hunting down stupid bugs that don’t require too much brain power.

August 16, 2008

Steve Dibb
beandog
wonkablog
» mplayer + dvdnav + dvdread svn ebuilds

I updated the mplayer and dvdnav ebuilds in my small overlay, and added one for dvdread now, which has been split into a separate package.  I haven’t had time in the past while to keep an eye on what’s been going on, but I do know that the heavy flurry of development has stopped, and that the installer works better.  Plus, the software works fine for me. :)

My overlay isn’t in layman right now, so if you want to check it out, here’s the skinny:

svn co http://overlays.gentoo.org/svn/dev/beandog/

Have fun and lemme know if there’s any problems.

July 30, 2008

Doran Barton
fozzmoo
Fozzolog
» Using Perl to convert audio files in a directory tree

Last night, a close, personal friend sent me e-mail asking me for a "script fu" favor. It would seem that my close, personal friend had somehow acquired a collection of audio files and these files were in a format that his personal media player device would not play. The audio files were encoded in the MPEG-4 Audio (M4A) format and my close, personal friend's personal media player device supports a wide range of formats including FLAC, WAV, Ogg Vorbis, MP3, and perhaps some others I can't remember at the moment. My friend (who is my close, personal friend) asked me if I could "whip something up" that could convert all his files to MP3 format.

What a nice challenge!

For a few moments, I considered tackling this problem with a shell script using time-tested command line utilities like find, sed, and grep, but ultimately, I decided to engage this challenge using Perl.

I chose Perl over shell scripting mostly because the directory tree that needed to be traversed to access all the files had file and directory entries that contained an arbitrary number of whitespace characters and other not-so-friendly-to-shell characters. While I'm sure this could have been accomodated, it didn't seem like fun and I got excited thinking about how this could be handled with Perl.

It's a fun exercise to write Perl scripts that use opendir, readdir, and other standard Perl functions to interact with the host filesystem, but I knew there were some valuable CPAN modules, maybe even some "indistinguishable from magic" modules maintained by Damian Conway, I could use.

The first module I decided to use was File::Find::Rule which provides an alternative interface to File::Find.


use File::Find::Rule;

...

my @files = File::Find::Rule->file()
                            ->name('*.m4a')
                            ->in( '/path/to/root/of/files' );

File::Find is somewhat of a relic in terms of how it operates. It doesn't provide any kind of object oriented interface for using it and requires the user to pass subroutine references which isn't very pretty. File::Find::Rule, on the other hand, works relatively nicely.

To convert the files, once we had them in a list, I figured we'd use the veritable bastion of audio versatility that is mplayer and use its built-in ability to construct standalone WAV files from media files. To do this at the command line, use the pcm audio output option and specify a filename:


mplayer -ao pcm:file=myfile.wav someotherfile.m4a

There are a couple quadrillion other options and parameters you could also add, but this is the general gist of it.

After each MPEG-4 audio file is decoded and dumped into a WAV file, we can use lame to encode the WAV to MP3 format.

The lame utility, in its simplest form, works like this:


lame myfile.wav output.mp3

Like mplayer, there are a ridiculous number of options, switches, parameters, chants, and secret handshakes you can provide to make lame do its job faster, slower, on one foot, etc.

One of the, uhm... inconveniences, yeah, of calling other programs from a Perl script is that it isn't easy to tell what's going on or how things went on... or off, or whatever. The same is generally true in a shell scripting environment, but that's not important right now. What is important is that our good man Damian has done a fantastic job of helping make this easier by providing the Perl6::Builtins module to the Perl community. Apparently, this incongruent behavior when calling external applications is not an issue in the long-forthcoming next major version of Perl (Perl 6). Damian has just ported the nice behavior back to Perl 5.

The Perl6::Builtins module gives us a new system function we can use which behaves like a good system function should.


use Perl6::Builtins qw(system);

...

system('/usr/bin/mplayer', '-ao', 'pcm:file=/tmp/out.wav', $file) or 
   die "Could not dump $file to WAV: $!";

Using the standard system function, the above code would almost always result in a call to die because the normal exit status of the system call, while sensibly being zero because there are no errors during program execution, means something else entirely to Perl. Instead, Perl detects failure.

With Damian's indistinguishable-from-magic help, sanity is restored.

So, below is the whole script, with some minor things changed to protect the... uhm... lonely.

I'm not proud of the code I wrote to create the destination paths. It works, but not gracefully.


#!/usr/bin/perl

use Readonly;
use File::Find::Rule;
use Perl6::Builtins qw/system/;

Readonly my $sourcetree = 
    '/home/friend/audio/Zarry Lotter (Cantonese)';
Readonly my $sourcetree_exp = 
    '\/home\/friend/audio\/Zarry Lotter \(Cantonese\)';
Readonly my $desttree => 
    '/home/friend/audio/zarry_lotter_cantonese_mp3';

my @files = File::Find::Rule->file()
                            ->name('*.m4a')
                            ->in( $sourcetree );

if( ! -d $desttree) {
    mkdir $desttree || die "Could not make directory: $!";
}

foreach my $file (@files) {
    my $dest = $file;
    $dest =~ s{$sourcetree_exp}{$desttree};
    $dest =~ s{m4a}{mp3};

    my @path_components = split /\//, $dest;
    # Remove common leading components
    for (1 .. 5) { 
        shift @path_components ; 
    }
    # Remove filename
    pop @path_components;

    my $path = $desttree;
    foreach my $comp (@path_components) {
        if(!  -d "$path/$comp") {
            warn "Making directory [$path/$comp]";
            mkdir "$path/$comp";
        }
        $path = "$path/$comp";
    }

    # Use mplayer to dump file to WAV
    system('/usr/bin/mplayer', '-ao', 'pcm:file=/tmp/out.wav', $file) or 
        die "Could not dump $file to WAV: $!";

    # Use lame to make an mp3
    system('/usr/bin/lame', '/tmp/out.wav', $dest) or 
        die "Could not convert $file to MP3: $!";
}

July 17, 2008

Steve Dibb
beandog
wonkablog
» mplayer and transcode fixes

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

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

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

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

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

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

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

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

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

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

June 5, 2008

Doran Barton
fozzmoo
Fozzolog
» Using open source tools to capture my favorite radio program audio stream

Listen to any kind of syndicated talk radio program and you'll usually hear about some companion website the program has. Usually, there are a handful of free things you can get on a program's website, but many of these sites have a pay-to-play members' area where the really good content is. This includes MP3 downloads of the shows, access to live audio and/or video streams, special behind-the-scenes content, forums, desktop backgrounds, etc.

The MP3 downloads are very convenient for people who don't have the luxury of sitting in front of a radio (or driving a car) for a solid three hours while a radio program is broadcast (with advertisements). It's also a boon for people who find radio advertisements annoying.

The only problem with the MP3 downloads is that theme music and produced portions of the program can not, by law, be included in the MP3 file because otherwise the MP3 would be a copyright violation.

Live streams, on the other hand, are not subject to the above described restriction because they're like a broadcast in nature. They're not a time-shift of the original program. So, if you listen to the live stream or even listen to a pre-recorded program as a stream, music and produced segments may be included.

I listen to the Glenn Beck radio program quite often. I used to download the MP3 files to listen to in the car, but it got annoying everytime Glenn and his producers would put together a segment like "Sportscasters at the 2031 animal-human hybrid baseball games", or "The History Of the Democratic Superdelegates" and I would hear Glenn say, "Listen to this... [pause] Oh man! That was great! Wasn't that great, Stu? Oh yeah! Alright! Dan? Wasn't that just the best? Yeah. Oh yeah."

I decided I needed to figure out how to save a stream.

I knew it was possible. Lots of software applications exist for any operating systems that will convert audio from a live stream into a static WAV file or similar. The open source program mplayer is one such example.

Breaking it down

First of all, I needed to figure out how the stream content made its way to my computer.

After I've logged into the Glenn Beck website as an Insider, I can click a link to listen to a stream of a particular hour of the program (or the whole program) in Windows Media format or RealAudio format. I figured I'd have better luck extracting the audio from the Windows Media format, so I went that route. Instead of just clicking the link and letting my web browser find some program that could handle the content, I saved the content to a file and then looked at the file.

The file it saved was a fairly straightforward XML file that looked something like this:

<ASX VERSION="3.0">
  <TITLE>Glenn Beck</TITLE>
  <AUTHOR>Premiere Radio Networks</AUTHOR>
  <COPYRIGHT>Copyright 2008</COPYRIGHT>

 <ENTRY>

    <TITLE>Glenn Beck 1</TITLE>

    <AUTHOR>Premiere Radio Networks</AUTHOR>

    <COPYRIGHT>Copyright 2008</COPYRIGHT>
 

    <REF HREF="mms://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603.WMA?auth=blahblahblahblahblah" />

    <REF HREF="http://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603.WMA?auth=blahblahblahblahblahblah
  </ENTRY>

  <ENTRY>

    <TITLE>Glenn Beck 2</TITLE>

    <AUTHOR>Premiere Radio Networks</AUTHOR>

    <COPYRIGHT>Copyright 2008</COPYRIGHT>

    

    <REF HREF="mms://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603_CLIP01.WMA?auth=blahblahblahblahblahblah" />

    <REF HREF="http://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603_CLIP01.WMA?auth=blahblahblahblahandblah" />

  </ENTRY>

...and so on.

This XML defines the MMS URLs for each segment of the show. There are several segments each hour. These individual MMS URLs are what I needed to feed to the application that was going to convert the audio stream to a file. In my case, I decided to use mplayer because it's just so good at everything it does!

The command line for doing the stream-to-file conversion looks like this:

mplayer -vc null -vo null -ao pcm:fast:file=dumpfile.wav \
    'mms://a0011.v67134.c6713.g.vm.akamaistream.net/blahblahblah...'

The real magic in the above command is where I use -ao pcm to tell mplayer to use the PCM file writer audio output driver (instead of sending the audio to my speakers).

This gives me a WAV file which I'll want to convert to an MP3 or Ogg-Vorbis file.

To convert a WAV file generated by the mplayer command above to an MP3 file, I use the open source lame tool:

lame -mf -q2 dumpfile.wav GlennBeck.mp3

Or, convert it to Ogg-Vorbis (the completely open and better-sounding-than-MP3 lossy audio codec):

oggenc -q2 --downmix -o GlennBeck.ogg dumpfile.wav

I've now covered the basic mechanical components of converting an audio stream into an MP3 or Ogg-Vorbis file. Next I automate it all.

Automation

Because I'm a long-time Perl junkie, I investigated how I could use a Perl script to act as the glue between the components and get the whole process of capturing a stream and converting it to MP3 or Ogg-Vorbis.

In the above walk-through, I manually logged into the Glenn Beck website with my web browser. To really completely automate this puppy, I wanted the script to log in for me. It didn't take me very long to figure out the Perl CPAN module WWW::Mechanize was what I needed to use.

WWW::Mechanize does several handy things for the programmer. It loads and parses web pages and can follow links, populate forms, and other basic kinds of interaction. It keeps track of its own cookies and session data too.

To get into the Insider area of the Glenn Beck website, members must enter their username and password on the Insider login page.

Looking at the HTML source for this page, I learned the form was named "aform", the username field was named "iUName", and the password field was named "iPassword".

I now had all the information I needed for WWW::Mechanize to log in:

my $agent = WWW::Mechanize->new(
    cookie_jar  => {},
);
   
my $resp = $agent->get('http://www.glennbeck.com/content/insider');
   
if($resp->is_success) {
    $resp = $agent->submit_form(
        form_name   =>  'aform',
        fields      =>  {   'iUName'    =>  'myusername',
                                'iPassword' =>  'shhhhhhhh!', },
        button      =>  'submit');

Walking through the code above: First, I create the WWW::Mechanize object with an in-memory cookie jar (cookie_jar => {}). Next, I use the object to get() the log-in page. If everything works well so far, I tell the object to find the form named "aform", fill in the username and password fields, and submit the form.

One thing I realized as I was debugging my script was that after I logged in on the Insider page, I was immediately redirected to another page. In order for my script to work, it needed to follow the redirect. This was an easy fix:

my $agent = WWW::Mechanize->new(
    cookie_jar  => {},
    redirect_ok => 1,
);

The page I got redirected to has the links on it for the streaming audio, so I'm exactly where I want to be if I want to capture and convert the latest and greatest Glenn Beck Program audio stream.

WWW::Mechanize can find links within the page with a variety of methods. One of these leverages Perl's excellent support for regular expressions. You can also search for links by the order in which they appear. The link I'm looking for looks like this:

<a href="http://www.premiereinteractive.com/cgi-bin/members.cgi?stream=shows/GLENNBECKWIN20080604&site=glennbeck&type=win_show"><img src="http://media.glennbeck.com/images/common/header_media5off.jpg" name="icon5" width="26" height="34" border="0" id="icon5" onMouseOver="MM_swapImage('icon5','','http://media.glennbeck.com/images/common/header_media5on.jpg',1)" onMouseOut="MM_swapImgRestore()" /></a>

So, my script has the following:

$link = $agent->find_link( url_regex => qr/${datestr}.*win_show$/);
$resp = $agent->get($link);

This assumes I have a scalar variable $datestr that contains a formatted date for the show I want to capture.

Originally, I was going to use one of Perl's several XML-parsing modules to make sense of the XML in the stream link, but in the end all I needed was a regular expression to extract the mms: URLs.

my $xml = $resp->decoded_content;
my (@urls) = $xml =~ m/HREF="(mms:[^"]+)"/msg;

This gives me a list of URLs stored in @urls. Now I just need to feed them to mplayer:

$i = 1;
foreach my $u (@urls) {
    my $seq = sprintf("%02d", $i);
    my @cmd = ( 'mplayer', 
            '-vc', 'null', 
            '-vo', 'null',
            '-ao', "pcm:fast:file=${datestr}-${seq}.wav", 
            $u);
    system(@cmd);
    if ($? == -1) {
        print "failed to execute: $!\n";
    }
    elsif ($? & 127) {
        printf "child died with signal %d, %s coredump\n",
        ($? & 127),  ($? & 128) ? 'with' : 'without';
    }
    else {
        printf "child exited with value %d\n", $? >> 8;
    }

    $i++;
}

This little ditty creates an output file for each of the segment streams. These are named something like 20080604-05.wav.

When the loop is finished, I have several WAV files sitting on the disk. Now I need to somehow sew them all together into one big WAV file so I can convert it to an MP3 or Ogg-Vorbis file. For this, I turn to sox. I decided to have the Perl script generate a shell script to run all the sox and lame commands needed.

open FH, ">/tmp/${datestr}.sh";
foreach my $j (1..($i-1)) {
    my $seq = sprintf("%02d", $j);
    print FH 'sox ', "${datestr}-${seq}.wav", " -t raw - | cat >> /tmp/${datestr}.raw", "\n";
}
print FH 'sox -w -s -c 1 -r 22050 ', "/tmp/${datestr}.raw ${datestr}.wav\n";
print FH "lame -mf -q2 ${datestr}.wav ${datestr}.mp3 ";
print FH "--tt \"Glenn Beck Show - $datestr\" ";
print FH "--ta \"Glenn Beck\" --add-id3v2\n";
close FH;

Then, I run the shell script:

system('sh', "/tmp/${datestr}.sh");

Finally, I do a little cleanup:

unlink "/tmp/${datestr}.sh", "/tmp/${datestr}.raw", map({"${datestr}-$_.wav"} (1..($i-1)));

And, I'm done. There are many other ways I could have gone about doing this, but I found a way that worked and ran with it. I'd love to hear from people who have done something similar and how they did it.

May 29, 2008

Hans Fugal
no nic
The Fugue
» XvMC

I bought an MSI NX6200AX-TD256H D2 video card (It's an NVIDIA GeForce 6200 256MB 8x AGP card) to drive the MythTV frontend, since MythTV can't manage to play even the most modest content using my trusty old Radeon 7000 (MythTV doesn't support VIDIX, only XVideo). I hoped that the upgrade would allow me to watch live HD television, which means XvMC.

Before I go any further, the other relevant stats: the computer I'm using (for the purposes of this post, anyway) is an 64-bit AMD Athlon 2800+ running 32-bit Ubuntu 8.04. The motherboard is a VIA K8T800. I'm actually using TwinView to share the Desktop computer with MythTV, but I tested everything with a single-screen (the CRT) to avoid confounding, and using TwinView doesn't seem to make a difference one way or the other.

All the normal stuff works great, but XvMC does not though it should. Whenever I try to use XvMC, the client (mythfrontend or mplayer, for example) freezes up and must be killed. I tried all the standard tweaks that Google could suggest: enable/disable sync on vblank, enable/disable OpenGL vsync, various xorg.conf settings. I tried just about everything I could think of and then some, and the only thing to make any difference at all is this setting in xorg.conf:

Option "NVAGP" "0"

That is, I disabled AGP. When I do this, XvMC works as it should. After a little research, it perhaps shouldn't be too surprising that AGP is the problem on a VIA motherboard. At least it's a lead.

Interestingly, when I downgraded the driver from the latest (173.14.05) to the newer legacy driver (96.43.05), XvMC works fine with AGP enabled. As one would expect, it outperforms the newer driver with AGP disabled. Here's a performance table:

               (% CPU when playing SD/HD in MythTV)
Driver                       Xv     Xv+linear    XvMC+bob
173.14.05 (AGP disabled)  20/100+    30/100+      12/60+ (OSD is too much)
96.43.05                  20/100+    30/100+       8/45

There's a few caveats to XvMC, either way I get it to work. When deinterlacing is on, the OSD gets deinterlaced too. This isn't a pretty sight, though it's functional. The OSD is always grayscale, in spite of setting XvmcUsesTextures to false in xorg.conf and choosing chromakey. But that doesn't bother me much, I don't much like the color schemes of the OSD themes I've seen.

I have one more straw to grasp before I consign myself to using the legacy driver (which I may do if it runs FlightGear and X-Plane ok) or crossing my fingers for a fixed driver before the Olympics (I intend to submit a bug report). I'm going to try poking around with AGP driving strength settings in the BIOS. I tried 0xEA and X wouldn't start at all, but with the same symptoms I get with XvMC. That hints at the same cause, so maybe with some kind of binary search I can stumble on a compatible setting.

So in conclusion, I'm going to try using the legacy driver even though my card is supported by the newer driver, and for OSD reasons only use XvMC for HD.

May 24, 2008

Steve Dibb
beandog
wonkablog
» what i’m working on

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

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

GPNL / Packages

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

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

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

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

MPlayer / Transcode

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

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

Sword ebuilds

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

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

lds-scriptures 3.0

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

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

May 1, 2008

Steve Dibb
beandog
wonkablog
» mplayer + dvdnav svn ebuilds

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.

February 28, 2008

Steve Dibb
beandog
wonkablog
» mplayer + dvdnav support … kinda

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. :)

February 14, 2008

Steve Dibb
beandog
wonkablog
» mplayer snapshot bump

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.

January 13, 2008

Steve Dibb
beandog
wonkablog
» mplayer-resume-1.5

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. :D

January 2, 2008

Steve Dibb
beandog
wonkablog
» switching aspect ratio on the fly

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.

November 2, 2007

Steve Dibb
beandog
wonkablog
» “it came from dvdnav!”

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. :)

September 14, 2007

Steve Dibb
beandog
wonkablog
» the star trek test

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.

September 13, 2007

Steve Dibb
beandog
wonkablog
» pimp my mythtv

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. :D

August 15, 2007

Steve Dibb
beandog
wonkablog
» mplayer + nvidia + xvmc

Another small mplayer tip, that I had to google for. When building MPlayer with XvMC support, so that it will use the video card’s hardware for MPEG2 decoding (and therefore, less CPU load on your box), mplayer -vo xvmc alone won’t work. You have to add -vc ffmpeg12mc as well, to force mplayer to use that codec for playback.

And, of course, I just noticed it says that right there on the man page. Whoops. So much for RTFM.

Anyway, if you like to use profiles, it makes things easier. Just drop this in ~/.mplayer/config and then do mplayer -profile xvmc movie.avi

[xvmc]
vo=xvmc
vc=ffmpeg12mc

I really can’t tell much difference in CPU load myself, since I’m running a fast box, but if you’ve got an older box with a decent (nvidia geforce 4 and up), give it a try. It’ll only work with MPEG2 videos, and the nvidia-drivers as well. I believe it works on the Intel i810 video cards too, though I don’t have one I can test it on.