Desktop and Device Delivery Applications

Standalone Media Players and Applications

RealPlayer is widely acknowledged as the first really successful Media Player that incorporated ability to stream or progressively download content, launching in April 1995.[1] The UCL MICE tools, among other academic projects, pre-dated RealPlayer by nearly a decade, but RealPlayer was commercially distributed and designed for more ease of use. Yet it was not well integrated with browsers at that stage, relying on the user to sequentially pass metadata from the browser to the player to begin streaming.

I myself consider WinPlay3, appearing in 1995, as the first widely available media player application that offered a well-integrated streaming experience for the web user. This is because it included the m3u file type (close to my heart - see Section 1.3 above), meaning that so long as your computer's MIME types were set up right (as should have happened at installation), you can click a link on a webpage, launch WinPlay3, and thus start a progressive download stream of the target mp3 (listed in the m3u file) playing in a few seconds (depending on your Internet speed). WinAMP emerged in 1997, and was considerably more successful, made so by its second version including a range of user-friendly tools such as a spectrum analyzer.

Shortly after this, Microsoft released the Active Movie Player: but much like RealPlayer it had a rather faltering start. Although in 1997 it became the foundation of the much more successful DirectShow capabilities, in 1999 Windows Media Player 6.4 split from the standard Windows Release cycles. In my opinion, this was one of the best media players of its time, being simple, practical (it was rolled into the OS for many years), and reliable.

As Object Link Embedding established itself as an open portable way to embed Windows Media Player and, over time, the RealPlayer into the webpages, maturing with Active-X, it was these technologies that largely brought video playback to be a normal, and expected part of the web user's general experience. However, because the media player application was external to the browser, just because the browser could provide access to the metadata describing the stream, it was no guarantee that the player would be able to also penetrate the local firewall and access the stream.

Destiny Media Technologies introduced their Clipstream streaming Java- based mp3 player around 1998, and this technology was notable in that it allowed a single mp3 stream to be delivered cross platform, and directly into the browser (provided that Java was installed).

Clipstream opened up the thinking that cross platform was a good idea. Indeed it was also the first technology to focus on browser streaming integration through just the HTTP streaming ports, whereas Windows Media and Real Media had a number of challenges to overcome before their embedding was smooth and reliable.

While Windows Media Player was bundled with the OS, and Real Player was “freemium,” Clipstream based their business on a model of “player activations” that - while it may well be more acceptable in today's mature market - meant that their technology was (comparatively) marginalized. Its tight port control meant that security conscious enterprises took interest in Clipstream for inward marketing, but Clipstream was not really well positioned to take advertising forward to consumer markets. The nascent advertising market was not warm to the idea of paying for a player instantiation for each advert in addition to the CDN delivery costs.

Fast starting for VoD assets emerged in early 2000. Windows Media server, in particular, introduced a number of ways to their configuration workflow to simply insert adverts as pre-roll and mid-roll. In the case of live streaming - particularly multicast - this helped the user experience. Because the multicast usually took a few seconds to join up and buffer, the pre-roll time was an excellent opportunity to give the viewer something to watch instead of a “buffering” message.

By the mid-2000s Adobe had really got going with its acquisition of Macromedia's Adobe realized that video capabilities could be easily added to their Flash executable. Because Flash was so widely installed for rich-media website development (not least because it was excellent at cross-platform support) and because it was invoked within the browser, it could share the same HTTP session as the browser for accessing the content - meaning it was typically simpler for firewalls and offered a widespread, fast-starting, low- latency, and cross-platform video delivery option.

Advertisers loved that, and relatively quickly Flash became the de facto model for launching video streams - particularly in the freemium web-user targeted IP video space. Microsoft ran to try to catch-up, by launching their own “rich Internet application” - Silverlight - bringing cross-platform access to Windows Media streaming. But until Microsoft stole a bit of a march on Flash by introducing Adaptive Bitrate “Smooth” Streaming in around 2008, there was a period between 2003 and 2008 when Flash became strongly dominant in the video delivery and CDN space.

QuickTime is the other key technology in the major vendor space. Introduced as far back as 1991 by Apple, becoming publically available in 1992, the early QuickTime was actually outsourced for development by Apple, and Apple subsequently took the developers to court (although settled) for stealing several hundred lines of QuickTime code when they developed the source at the heart of what became Windows Media Player. This incestuous relationship between QuickTime and Windows Media was probably a complex issue for the companies involved, but ultimately it is also probably one of the key contributing factors to today's cross-platform support for media.

However, it wasn't until version 4.0 in 1999 that QuickTime added streaming support. This made it four years behind Real and Windows Media (whose Active Movie player release in 1995 had supported streaming). This loss of position took some time to recover. Ultimately Mac platforms were targeted by Flash-based publishers, until Apple made a strong separation from Flash to introduce HLS, which was very similar to Microsoft's smooth but was the only way to stream to the disruptive iPhone and subsequent iPad. Leveraging their device dominance, the QuickTime components, and smooth handling of the stream between the i-devices' browsers Apple set the stage for the rapid switch to HTTP-based, native browser targeting that has risen since the smartphone era transformed the video streaming landscape.

Before we jump into the browsers though, we should mention mplayer and VLC. VLC is one of the largest collaborative open source media player projects. The project started in 2001, so it was relatively late to the stage, but it brought together a number of traditional media player features for the consumer, with a range of encoding capabilities for the producer. Until then only

QuickTime had really included any degree of authoring tools, and these were fairly simple. VLC added the ability to compress, packetize, and serve a variety of streaming formats, and though never really a production-ready tool, as a desktop toolkit for a webcaster or streaming engineer it was the one tool that gave a producer a depth of control and insight into the streaming process that meant quick tests, models, and device interop debugging could be conducted through a GUI.

I still always have VLC installed, and while I would never consider using it for a production client, if I receive a file that is difficult to play back, or if I want to test the very latest beta CoDec or try out streaming quickly on a LAN, VLC is a quick and dirty “Swiss army knife” for all of these types of workbench tests.

VLC has been ported to many OS and provides a relatively consistent experience. However, in 1999/2000 there was still extremely limited support for video streaming to the rapidly emerging Linux operation system.

Into the Linux space came mplayer. The mplayer was a command-line media player, with a counterpart mencoder that provided compression and muxing/ packetizing for basic streaming. Schisms in the coding team formed mplayer2 as a fork, although mplayer2 had a GUI and did not ship with mencoder.

The mplayer and mplayer2 are still commonly found in appliance-based streaming systems, such as those used for digital signage. They are relatively simple, and being GPL-based coders, they can access the source, which is much more restricted than VLCs, and relatively quickly set up simple Linux appliances that can render video to a display. In my IP Set-Top Box start-up (Set Top Solutions Ltd, 2004-2006) we used mplayer at the heart of the system. It is certainly possible to make it production ready, although it tends to be relatively fussy to add a fluid UI.

  • [1]
< Prev   CONTENTS   Source   Next >