Although the hardware you choose for streaming media is similar to that which is required for any LAN or WAN data transmission, the software determines how efficiently that hardware is used, and, ultimately, what hardware you should purchase. Apple provides an open-source version of their streaming server called the DARWIN Streaming Server. It requires the execution of the Apple Public Source License (see Resources). The DARWIN Streaming Server can stream “QuickTime Hinted” files, which are proprietary to Apple, but because the server is open source, it is likely that it can be modified to support other file formats.
QuickTime is not currently supported on the client side under Linux. Lucent Technologies recently announced the free availability of its OptiMedia MediaServe streaming media server application for Linux (see Resources). They claim to use the industry-standard Real-Time Streaming Protocol (RTSP) and to support a variety of file formats that should make the server useful across many client platforms.
All the other streaming servers I have reviewed are closed source. Some, like Entera and RealNetworks, run on Linux (see Resources). Entera's TeraCAST and TeraEDGE streaming servers use open standard RTP/RTCP streaming protocols in conjunction with RTSP. RealNetworks has it own proprietary RDP protocol that they use with RTSP to communicate to RealPlayer clients. In contrast, Microsoft's proprietary technology, has not (yet?) been ported to Linux.
Let's review some basic streaming technologies that are usually mentioned glibly as acronyms. What are they and how do they interact with each other? The ultimate goal is to introduce you to QoS, the Internet term that refers to the performance, reliability and adherence to any real-time requirements and any other aspect of Internet service that could impact communication between the source and destination. Many of the commercial streaming-media products differentiate themselves in the market by their QoS capabilities. Be careful. You will be confronted with many decisions on hardware and software purchases based on the level of QoS you want to provide to your expected audience, but unless you control the complete end-to-end path from source to destination, you will always be subject to QoS provided by the poorest performing link in the path. All you can do is make sure that your piece of the path is the best it can be and that your server software makes optimum use of existing QoS protocols.
IP (Internet Protocol) is the most basic protocol used over the Internet. According to the DOD STANDARD INTERNET PROTOCOL, 1990, IP provides “...the functions necessary to deliver a package of bits (an Internet datagram) from a source to a destination over an interconnected system of networks”. All the other streaming protocols and mechanisms sit on top of IP.
UDP (Unreliable Datagram Protocol) is the usual choice of packet types to send over IP if it is not critical that the data arrive at the destination. This is a low overhead protocol that is especially useful for RTP.
RTP (Real-Time Protocol) is a real-time transport protocol that sits on top of UDP because it cares much more about “letting the show go on” than sitting around waiting for perfect data. RTP was originally designed to support multicast-multimedia conferencing, but it can be used for other applications.
TCP (Transmission Control Protocol) on the other hand, has been engineered to provide robust, error-free data transmission. It operates at the same level as RTP but is used in most time-insensitive Internet communications or connections that require high reliability of data.
RTSP is an application-level protocol that uses the lower-level elements of RTP to manage multiple streams that must be combined to create a multimedia session. These streams can originate from many sources, even geographically detached locations.
RTCP (Real-Time Control Protocol) packets are carried over TCP connections to work in conjunction with RTP packets to monitor QoS and present feedback to the participants in an RTP session so they can take any actions possible to improve the QoS.
RSVP (Resource ReSerVation Protocol) is closely tied to QoS. RSVP has been designed to work as a separate process that allows an application to request various QoS levels. Nodes along the route to the requested data analyze the RSVP requests, decide if the requester has the rights to that QoS level and that the requested QoS level is available, and either report back that they will provide the requested QoS or report an error.
You do not need to completely understand any of these protocols, but you should know that RSVP is an extremely rich protocol that gives server vendors a lot of room for QoS improvement. Before you choose your streaming-media server software, it would be useful to ask how their product handles QoS issues, especially via the RSVP protocol.
- Readers' Choice Awards 2014
- Handling the workloads of the Future
- Android Candy: Google Keep
- diff -u: What's New in Kernel Development
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Synchronize Your Life with ownCloud
- Days Between Dates?
- December 2014 Issue of Linux Journal: Readers' Choice
- Non-Linux FOSS: Don't Type All Those Words!
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane