ASFRecorder

As fantastic as streaming audio and video are, sometimes it's nice to reply things later. As far as websites which host .flv go, the act of saving the media file is fairly trivial, and is done by a wide range of browser plugins. Websites which actually rely on a client-side stream player are a different story though...

I was after a simple option, and ideally something single-purpose. Apps like VLC are up to the task, but a bit too big to bundle in a plugin, and lack some desired features (like resuming, in the case of VLC). There is a Japanese app called GetASFStream which appears to do a good job, and even rebuilds the header based on the streams chosen (which as far as I can tell simply chooses the first audio and video streams). There's a couple of problems though - it's in japanese, doesn't appear to be open source, and doesn't appear to have commandline support. So the search continues...

I then stumbled across the code for an application called ASFRecorder. It appears to be unchanged since 2001, and as a result, lacks a few features.

For starters, it doesn't recognise the content type "application/vnd.ms.wms-hdr.asfv1", which Microsoft gives little data on, but it appears I'm not the only one to come across this problem.

Once I'd patched the code to take newer ContentType values, I came to another problem - it doesn't parse the payload parsing information section properly - instead of actually interpreting it as per the spec (which is freely downloadable), it appears as if the original author picked a few common values, or found them from trial and error, instead of calculating the length as a general case function. Once this is fixed, ASFRecorder happily dumps the stream to a file, but we're not done yet!

As described here, ASFRecorder only downloads the first stream, and dumps the header has it. This is quite messy, but the attempt is quite a valid one - if the stream is dumped directly to a file, then in theory it can be played straight back. However, it appears the code was only ever written for single stream broadcasts, which means the user is limited to either audio streams, or soundless video streams (ie. radio or porn), and so despite the file being written with a multi-stream header, only the first stream is saved.

I decided to undertake the rewarding task of building my own header parser app (which I might post if anybody cares enough to look at the code) so I could compare the (incorrect) output of ASFRecorder with the (correct) output of GetASFStream. After comparing the two headers, and trying (unsuccessfully) to simply paste the header from the correct dump onto the incorrect one (which stopped it from playing completely), I discovered that the reason ASFRecorder was only dumping a single stream was because that's all it was asking for.

By changing the hardcoded reply message so that it asks for two streams instead of one, my dump is suddenly working correctly! However, there is a bit more tidying that needs to be done, and some of it is necessary before release, but there is also some I can save until later

• Actually coding a general parser for the payload parsing information
• Changing the handler to take all MIME types for ASF files
• Parsing the return value from the server to give a proper selection of streams
• Processing the whole header, writing a new one, and arranging the streams accordingly
• Building a proper resume function to compensate for the new header
• Somewhere along the line incorporating this into a browser plugin

And that's all.... looks fairly straightforward.

One final comment to make about the ASF file format - it's actually logical. The last time I messed with m$ file formats was DIB and WAV files, each with their own quirks and rude deviations from the standard. It seems when m$ does their writing from scratch, they do a proper job of it.