Standards in IPTV
These days IPTV looks pretty much like VoIP did several years ago. No standards, whatsoever. Different manufacturers provide different platforms. Interoperability is nonexistent. And the fact there are several different options, using solutions that intersect with one another makes things ever worse.
First, you have codecs. A great number of those exists. Some you can use for free, for some you must pay royalties. Usually, manufacturers support somewhat proven combinations of audio and video codecs. Most of the time MPEG in different versions is supported. Some IPTV providers, however, use things like RealVideo, WMV, H.263 or VP6/VP7. With those, you must be careful. Not every Set-Top-Box will understand unpopular standards. Test everything before signing anything. It is pretty much the same with audio codecs. MPEG and AAC are generally well supported, but there are exceptions as well.
Next, you are presented with a broad variety of containers. Transport Stream, Program Stream, Windows Media Video, MOV, etc, etc, etc. Again, you may put differently encoded streams in different containers. Some devices understand one type of containers, others will blindly refuse to even look at the content. Anyone dealing with Set-Top-Boxes or Middle-ware should be extremely careful to pick the right combination. You really don’t want to send MOV with MPEG-2 data to a device that “understands” only Transport Streams with MPEG-2 data in them.
To make the matter worse, there is a number of transport protocols you can choose from. Real Time Protocol (RTP) seems very popular. However, keep in mind, that it sometimes comes with RTCP. And your device or middle-ware should be clever enough. Plain UDP is also possible. It is probably the most simple and stable solution. TCP is a valid option too, but its strengths make it somewhat unfit for the duty of real-time streaming protocol. We should also mention the HTTP protocol. For many reasons it is not the right protocol for the task. But it is so easy to implement middle-ware components based on HTTP so many manufacturers and system integrators prefer it. Last but not least, it is the RTSP. Real-Time Streaming Protocol is designed with sole purpose to make streaming real-time data (usually in a separate stream) easy. RTSP is flexible, relatively simple, relatively fast. RTSP is open protocol. It uses others protocols and techniques to describe external streams. And this is somewhat problematic. Some manufacturers expect XML stream descriptions, others expect SDP. From the looks of it, there are no limits, text, binary, you name it, you can use it to describe your streams in a RTSP session. Flexibility does not works for you if you’re stuck with stream descriptions your software is unable to parse.
Last option, we gonna discuss is the “cast” method. There are two option available here: unicast or multicast. Both have pros and cons. Unicast is easier to implement, requires less sophisticated equipment. But it unicast uses lots of network bandwidth. If you have 10 clients and every one of them watches 8 Mbps stream you have 80 Mbps constantly flooding your network. Multicast is more complex. For implementation it requires OS support, modified middle-ware. For deployment it requires “smart” equipment. One that understands IGMP, PIM, etc. But it has one advantage, it doesn’t matter how many clients watch the stream. Required network bandwidth is constant. With one 8 Mbps stream and 100 clients it is still 8 Mbps.
This is all nice. Lots of options, lots of possibilities … until you try to compete in the ever-changing world of IPTV.