IMDA Playlist Definitions

Some technologies used by internet media devices have started as proprietary technologies and have gone on to become de facto standards. In some cases, there is no official definition or specification for these technologies. In some cases, there is an unofficial definition listed on a webpage or as a forum posting, but with the dynamic nature of content on the internet it is possible that these pages will cease to exist at some future date.

In order to make it easier for device manufacturers to implement internet media devices, the page below presents an informative guide to commonly-used playlist formats. Also given are references to other pages which, along with knowledge and experience of the internet media device sector, have been considered in the generation of these guides.

Playlist files are used as containers for one or more audio/video files/streams. For internet media streams, playlist files are served by HTTP/HTTPS and reference contained streams as absolute URLs – i.e. a URL of the form http://domain.tld/path.

M3U

M3U files are plain, newline-separated files which contain one URL on each line. An example file is shown below:

http://domain.com/intro.mp3
http://domain.com:8000

Although uncommon, it is possible that “Extended M3U” files may be encountered. The “Extended M3U” format includes lines beginning with

#EXTM3U
#EXTINF

Solutions must be able to successfully retrieve all URLs from documents containing these additional metadata.

PLS

PLS playlists use the syntax commonly found in Windows .ini files. They usually have a single section named “playlist”, and contain entries similar to those in the example below: 

[playlist]
NumberOfEntries=2

File1=http://domain.com/intro.mp3
Title1=Advertising Blurb
Length1=1890

File2=http://domain.com:8000
Title2=Cool Radio
Length2=-1

As can be seen, stream URLs are those of the form FileXXX=URL.

It is recommended that solutions do not rely on the NumberOfEntries parameter
here.

Simple ASX

ASX is a very commonly used playlist format, but there is a lot of variation in real world documents that devices need to accommodate in order to be able to play the widest possible selection of streams.

Implementing a valid, strict ASX parser is a desirable aim for Solutions that want to offer maximum interoperability with current and future releases of Microsoft™ streaming products. Solutions including such a parser must always attempt to parse ASX documents strictly before attempting to parse them in the relaxed way described in the following paragraphs.

Document Format:

Real world ASX documents are similar to XML documents, but are not necessarily well formed. Solutions must include a relaxed XML parser which

  • collapses the case of tag names – ASX file authors often mix <Entry> and </entry> tags – and
  • handles mismatched tags – ASX file authors often create documents that do not represent valid DOM trees. Use of a SAX or TagSoup parser is recommended.

Stream Elements:

The structure of real world ASX documents varies greatly. Because the DOM model fails to capture that diversity, Solutions must extract stream URLs from either

  • the href attributes of ref elements found inside entry elements or
  • the href attributes of entryref elements found inside entry elements.

An entry element may contain a number of stream URLs. In this case, the player should treat additional URLs as alternatives to try in the event that the first URL does not link to a playable stream.

The URLs extracted should be treated as resources that may resolve either to a playlist or to a stream URL in order to support nested playlists.

By way of example, the text:

<asx>
  <ENTRY>
    <ref href="http://example.com/announcement.wma" />
  </entry>

should be interpreted as a link to

http://example.com/announcement.wma

References

See also: