Next Stream Ltd. Company Blog

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.

Management General, Tech

This was a busy week. Progress is slow, but constant. However, we want to share some thought on appliance development we’re starting at Next Stream Ltd. What should be the main features of an appliance product ? Our Top 3 is:

1. Easy to use
2. Stable
3. Resilient

Appliances must be easy to use. And not only for the technical staff. If you ever need to interact with the device you shouldn’t be expected to know all the technical details on the subject. This is mostly related to user interface. User-Computer(Device) interaction should be straight-forward. Define a goal and let the machine ‘walk the walk’. No one wants to have a full-time job dealing with a bunch of computers constantly needing attention. Simplified user interface with embedded/contextual documentation is a must. Whenever you enter configuration details or click a button, it must be clear what will happen. The contextual help should give you this clarity. Data validation/verification, on the other hand, should prevent you from shooting your leg[s]. So, to make an appliance easy to use:

• minimise number of configuration options
• embed documentation in configuration screens
• always validate input for logical correctness

Don’t let your users make mistakes. It is better to sacrifice configurability than allow malicious actions be taken against your device.

Next on our list, stability. Your device must be stable. It must deliver what’s promised. And it must deliver it under almost all circumstances. Its behaviour must be deterministic. To achieve stability minimise ‘moving parts’. Keep the number of options minimal, keep the number of running components minimal. Test, test, TEST ! Then test some more. We can not stress how important is testing. There are two components that mixed together will give you stability – proper design and testing. So, thing fist, code later. And when coding is finished, test ! Without entering the dark territories of proper tests management, regression testing, fuzz testing, etc, we advise to think about testing procedures during the early stages of development. At least we try to do it this way.

Stable operation is the path to resilience. Once you appliance is stable and predictable enough, you can move to making it resilient. There are many operating systems out there, but only few are really designed to work in any environment. And Linux is not one of those. Nor are most of the other open source projects. Why ? Because they follow design paradigms more than 30 years old, that were meant to accommodate computers of that era. And we all suffer from this. Our every day operating systems are not stable. How can they be resilient ?!

There is work in this direction. QNX, RTEMS, Minix 3 are several examples. New Minix 3 architecture is really impressive. Prof. Tanenbaum and his team came up with the idea of ’state server’. A system process is constantly updated with state information from other processes. When one of those processes crashes, it is automatically restarted and state information is restored in it, so it can continue operation from the moment right before the crash. Which is really a good idea if you want to make your software resilient. The code is out there, so are the papers describing the process in detail. We admire one of the Minix 3 goals, to make the computers reliable like a TV set.

In conclusion we would like to quote a story from Tom Van Vleck (MULTICS developer) about his discussion with Dennis Ritchie (UNIX developer):

… We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, “We left all that stuff out. If there’s an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, ‘Hey, reboot it.’”

30+ years later, it’s the same.

Management General, Tech