Dissecating ASF/ASX format

Radio Tray development is coming along fine. A lot of new features have been added, as long as some bug fixes. And it’s precisely about one specific bug fix that I’m gonna rant…err….I mean talk about. The infamous ASF format.
As you all probably know, when we do an HTTP request, the server sends a response and in that response there’s the content-type property. This property is the MIME type that identifies the following data in the response body. Radio Tray would inspect that content-type to see if it can decode the stream data. This is mostly important for the playlist formats. These are text files whose entries point to the real streams of music. So, it’s from this MIME type that Radio Tray knows which format of playlist is receiving and thus, proceed to decode it.
Now, let’s check out the "video/x-ms-asf" MIME type. This is the  MIME type returned when we have an ASF stream, the music data itself. However, for a music server, it’s allways useful to return a playlist. And so they created the ASF Playlist, which is basically a key-value text file where each entry represents a stream URL. But instead of defining a different MIME type for this playlist, they decided to use the same! So now we have a text file and a byte stream identified by the same content-type. Of course I had to figure out a way to distinguish between the two, because the content-type was not sufficient anymore.
Somewhere along the way, someone decided that the ASF playlist wasn’t good enough and decided to make a new playlist format to serve ASF streams. This time, in the form of a XML file. It was named ASX playlist. That is fine, except for one detail: they decided to use the same MIME type again! So now the "video/x-ms-asf" represents a binary stream and two completely different playlist formats.

Unfortunately, the complexity of the ASF/ASX playlists don’t end here. They decided that it wasn’t enough for a playlist entry to indentify just a media stream. So, that URL can also be another playlist. From the playlist syntax there’s no way to tell, they’re just URLs. One has to contact the URL and inspect the response. Now, the fun part begins. When I was testing this, this specific radio pointed to a playlist with just one entry. This entry ended up being another playlist. So, Radio Tray downloads the new playlist and inspects that one. Again, it had one entry. Something like "http://someurl?MSWMExt=.asf". I thought that would finally be the media stream. However, to my surprise, that URL just returned the same playlist file again. Let me repeat that: when downloading the playlist, which contains "http://someurl?MSWMExt=.asf", that URL just returns the same file. Does it mean it goes into an infinite loop ? you bet.

So how can we access the media stream ?
The rule is: when we have an http URL that ends with "?MSWMExt=.asf", substitute "http" with "mms". I just have one question: why ? Why would anyone think of such a bizarre scheme ?

Maybe I’m missing something, but it feels strange and excessive. Where has simplicity gone ?

Well, I just had to let it out πŸ™‚ But at least it was fun to dissecate this playlist format. As for the upcoming 0.6 version of Radio Tray, it’s almost there. Just a few small things missing.

Happy Listening!

Advertisements

8 responses to “Dissecating ASF/ASX format”

  1. Tate says :

    Hey, there isn’t a chance to use ffmpeg to decode that stream instead of GStreamer?. I remember that used that to listen some radios that use the crappy asf (and in argentina are a lot).

    This line, for instance, is to listen an argentinian radio which uses windows media “mplayer http://streaming.fmrockandpop.com/rockandpop

    I haven’t tested it on radio tray yet

  2. Carlos Ribeiro says :

    Yeah, I analyzed both before starting development, but GStreamer API is a lot easier to work with. For now, changing that would be a lot of work πŸ™‚

  3. fer says :

    Does VLC use ffmpeg for streaming? Just wondering because it does it very well interpreating url’s.

  4. Carlos Ribeiro says :

    Hmm, AFAIK VLC uses its own library, which is very good indeed.

  5. Tate says :

    VLC uses libavcodec which is part of FFmpeg. Maybe xine, since is ffmpeg based too. But i wanted to say is not to change gstreamer for another framework but use Mplayer (or any libavcodec based) for play asf radios.

  6. zebul666 says :

    may be let’s just say it’s been made by microsoft. That will sum it up all.

    as a side note, one problem to use radiotray is that every online radio wants you to use their flash player and does not display any url to listen to their stream. and it’s hard to find most of the time. You have to dig into html if not javascript code to find it. 😦

  7. Carlos Ribeiro says :

    @Tate That would be an alternative. But I think RT can now (development version) work with them πŸ˜‰

  8. Carlos Ribeiro says :

    @zebul666 Unfortunately, some radios just use those flash players. In some of them I couldn’t find the stream URL. That’s a shame. Let’s just hope that with HTML5, extracting the stream will become easier.

%d bloggers like this: