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.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis
- Designing Foils with XFLR5