Author Archives: Multimedia Mike

My Own Offline RSS Reader

My current living situation saddles me with a rather lengthy commute. More time to work on my old Asus Eee PC 701 (still can’t think of a reason to get a better netbook). It would be neat if I could read RSS feeds offline using Ubuntu-based Linux on this thing. But with all the Linux software I can find, that’s just not to be. I think the best hope I had was Google Reader in offline mode using Google Gears. But I couldn’t get it installed in Firefox and the Linux version of Gears doesn’t support the Linux version of Chrome. I did a bunch of searching beside and all I could find were forum posts with similar laments: Offline RSS readers don’t allow you to read things offline. Actually, to be fair, I think these offline RSS readers operate exactly as advertised: They allow you to read the RSS feeds offline. The problem is that an RSS feed doesn’t usually contain much meat, just a title, a synopsis, and a link to the main content. What I (and, I suspect, most people) want in an “offline reader” is a program that follows those links, downloads the HTML pages, and downloads any supporting images and stylesheets, all for later browsing.

I didn’t want to have to reinvent this particular wheel, but here goes.

Here’s the pitch: Create a text file with a list of RSS feeds. Create a Python script that retrieves each. Use Python’s XML capabilities (which I have already had success with) to iterate through each item in an RSS feed. For each item, parse the corresponding link. Fetch the link and parse through the HTML. For each CSS, JS, or IMG reference, download that data as well. Compute a hash of that supporting data and replace the link with that hash. Dump that data in a local SQLite database (you knew that was coming). Dump the modified HTML page into that database as well.

Part 2 is to create a Python-based webserver that serves up this data from a localhost address.

One nifty aspect of this idea is that my Eee PC does not have to do the actual RSS updating. If the relevant scripts and the SQLite database are stored on a Flash drive, the updating process can be run on any system with standard Python.

See Also:

  • Part 2, where I get this idea to a minimally functioning state
  • GhettoRSS, what I eventually called the software when I released it

Compatibility Testing With FATE

Once upon a time, I made a valiant effort to create a compatibility page for FFmpeg. The goal was simple– document how to use FFmpeg to generate media files that would play back in the most common media players of the day. At the time, this included Windows Media Player and Apple QuickTime Player. The exercise was naturally obsolete quite quickly due to the fact that I used some random SVN revision (actually, this is so old that I think we were still using CVS at the time).

I still think this is a worthwhile idea. I now realize that the idea can be improved by FATE. Create a series of test specs that map to a certain encoding combination known to work on a popular media player (or even a popular media device– this could be used for testing, e.g., iPod profiles) and document the command lines on the website. When one of the command lines breaks for all configurations, it will be worth investigating to learn why and whether the website example needs to be updated, or whether FFmpeg needs to be fixed.

Testing process:

  • Develop command line that should produce content playable for popular software player or device
  • Transcode sample media with command line
  • Test media on target player to make sure it plays
  • Enter FATE test spec
  • Document command line on compatibility page

Such a FATE test will be contingent upon a built-in file checksumming feature as I have outlined for a future revision.

Testing Older Snapshots With FATE

Suppose FATE had the infrastructure to test arbitrary branches of FFmpeg. I just realized that it wouldn’t necessarily help because the FATE test specs keep changing as the code is adjusted. This implies that there needs to be more sophisticated test management.

This occurred to me due to the chatter surrounding the recent FFmpeg 0.51 security release. Running the FATE suite against 0.51 doesn’t work since the current state of the various FATE tests are contingent upon the current mainline FFmpeg source. Possible solutions going forward? Perhaps upgrade the FATE database to support some kind of versioning? However, this would also limit my ability to monkey with the existing FATE suite of samples.

IRIX CD-ROM

A little while ago, an article made the rounds which detailed a visit to The Weird Stuff Warehouse in Silicon Valley. Since I have a thing for weird, obscure stuff, I knew I had to pay a visit.

I didn’t find much interesting material there, though that’s probably more an indication of my own changing interests (there was a time when I would have enjoyed buying up vintage hardware for cheap). They did have an old MPEG-1 ISA bus video decoder board. There wasn’t much in the way of old entertainment software, which is my current interest. However, I did find an old SGI IRIX OS CD-ROM. Since SGI was more or less synonymous with multimedia back in the 1990s, I thought this disc might have some classic multimedia examples.



The manual that comes in the jewel case seems to focus exclusively on using FlexLM.

When ripped, ‘file’ identifies the disc image as “SGI disk label (volume header)”. Is that the same as SGI’s XFS? I installed Linux’s XFS module but was unable to mount the filesystem. Scanning through the image, I didn’t fnd any strings that would indicate more common multimedia types from the era.

Weird Stuff Warehouse also had an SGI Octane machine for running the OS. You have no idea how hard it was to resist the urge to buy it and run the FATE client on it.