Next Stream Ltd. Company Blog

Next Stream continues work on full IPTV solution. We did lots of work in the recent mounts. Our middle-ware is about to reach initial release. Several key points include:

• Multiple Set-Top-Boxes Support
• Multiple Protocols Support
• Multiple Language Support
• User Authentication
• Flexible Channel Management
• Flexible VoD Management
• Package Management
• Standard Compliant Protocol Implementations
• High Availability Features
• Load Balancing Features
• Integrated Appliance Management
• more …

Our work in field the of IPTV has been supplemented with mobile streaming as well. Our preliminary implementation works successfully with several mobile device vendors and telecoms. We will be including this functionality in the future release of our IPTV Solution.

Stay tuned for more.

Management General

Our efforts in designing stable and configurable wireless mesh solution are shaping up. After several months of work we have working beta system with multi-vendor support. Next Stream, in cooperation with OptimWIFI, developed secure, industry standard compliant mesh node software and easy to use mesh configuration system. We are working on the final release. We also started working on a web based configuration interface that will help potential clients with hundreds, even thousands of access points or wireless nodes to configure them from a central point with a click of a button.

We understand how important the administrative work is and that it is not error-proof so we provide a way to backup all your settings for all you nodes in a centralized manner. Our interface also provides per-node backup/restore functionality.

Google Maps integration is the next area we are planning to work on. Stay tuned for additional updates.

Management General

Fist BETA of our management interface is ready. It is still rough around the edges, but it is functional. We put some serious effort to design it and implement it properly. We will not compromise our quality just for an early release. And here are several screenshots of it:

Channel Management

Package Management

Tag Management

Management General

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

We mentioned on several occasions in this blog, that we are working on IPTV solutions. Just like any other software company, we are trying to avoid reinventing the wheels, by using solid, proven solutions. So, we use Linux. And for us, most of the time Linux works great. We love Ubuntu. We have several boxes with different versions of Ubuntu Server and Ubuntu Desktop. Even this post is written on Ubuntu Desktop. We love other OSs too (Go FreeBSD !!!), but the focus of this post is our latest experience with Linux.

In our test network, we have several multicast streams. We use them for Set-Top-Box testing, middle-ware testing, fun, etc. And they all work fine. Until yesterday. We were testing a border device we’re developing and strange problem occurred. Our application is supposed to read from different streams (different multicast ip + port combinations) and process the data in a different manner depending on the source. But something wrong happened. After some testing and debugging we found that all multicast traffic reaches all readers. Kernel should register every reader to unique pair of multicast source address and port and send traffic only from this address and port to that reader. But apparently there is a bug with that. We thought it is a problem with our code and tried to debug it for several hours without any luck.

Later that day a person with more experience in this matter told us that it’s possibly a Linux kernel bug. Seems reasonable. Now, let’s confirm it.

Moral of the story: It is not always your code that is the problem, just most of the time.

Management General

Our IPTV platform is shaping up. We successfully modified our middle-ware to be compatible with our set-top-box of choice. After dealing with several industry un-standardised protocol extensions and other small glitches we are having stable multicast and unicast streaming. HD content is nicely presented on the TV. Everything works like a charm.

We examined several other set-top-boxes and home entertainment appliances to get a general idea what degree of usability the competitors provide. We are actually not that impressed. Most of the boxes are too slow. Some of those are ugly too. However, we have the basic design. Several screen layouts are being tested and modified. A bit more work and our interface will be fast and usable enough. What we need right now is a graphical designer with experience in user interface development. But, we’re working to hire such person too.

We will keep several features hidden for now. Let’s not spoil the fun of experimenting with our solutions later, but a short report I can say channel management, volume management, on-screen display and everything else you’d expect from a consumer device is now operational. Eye-candy is coming up next.

This, of course, allows us to provide OEM solutions. If you prefer custom design, custom layout, branded interface, just your logo up there or a full-blown advertisement solutions, we can accommodate your needs, fulfill your requests.

For the end of this post we would like to tease you a bit. During our High-Definition tests we were able to play 40Mbps (forty megabits per second) 1080p content using our distribution and client equipment. This is currently known as Blu-Ray. Nice and sharp picture, nice and sharp …

Management General

We are coming to a success. With some help and lots of work we are hammering problem after problem. We have stable playback on our set-top-boxes. Some modules are still rough around the edges, but the whole system is shaping up. Anyway, we can present Telco/ISP oriented, prototype IPTV system, capable of Multicast and Unicast video distribution. What is more important, flexible enough to adapt to the needs of any Internet Service Providers or Telecoms.

Our IPTV design currently consists of several layers and a number of modules:

• Video Data Acquisition
• Media Library
• User Management
• Load-balanced Content Distribution
• Theme-able User Interface
• HD-enabled Customer Premises Equipment

Basic prototypes of all of the above are present and working. Our work is focused on what I can describe as “commercialisation” of the particular products. We are fixing bugs, adding relevant features. Making devices and appliances user-friendly and intuitive is a main goal. We understand that the packaging sells. We want our customers happy.

But it is not all bells and whistles. We are fighting every day with the lack of standardisation in IPTV. Many protocols exist. Many hardware and software vendors. And all of them usually interpret every protocol in different way. Which is worse, many IPTV related protocols make room for disambiguations. It is usually, up to the implementor to decide how te deal with this. And most implementors do so they favour particular device or manufacturer. Which breaks compatibility, which requires dirty workarounds in the code.

Well, the RFCs give you freedom. They actually let you create unique product. When we speak of IPTV, they even let you break compatibility with proprietary extensions. But please, do know what you are dealing with, and please, do it right. One of my recent findings was that a big IPTV company “extends” particular IPTV related protocol with encapsulation of XML data in the payload. And I can find some logic in this. XML is, de facto, the standard for data representation these days. XML is well understood. XML is wide-spread. Many libraries exist to work with XML content.

What I don’t understand is how you can ship a product that works with malformed XML. And further more, why  would this product refuse to work with correct XML ?!

Please, make all our lives easier. Obey the standards !

Management Advertising, General, Tech

In a previous post we discussed some problems we had with High-definition Set-Top-Box we plan to use for our IPTV work. After several days of work, digging network traffic dumps and patching middle-ware components we can safely say, we fixed this problem. But a new problem emerges. We are currently working on a permanent solution to rework the whole device firmware with the device manufacturer. Great thanks to Michael and John for the cooperation and understanding.

Until we finish that, we plan to release a product targeted at Telcos/ISPs that will take care of acquisition of data for IPTV networks. We would like to provide full, flexible IPTV solution for different setups. Starting from Telcos/ISPs and going “down” to public buildings, advertisement and entertainment installations. Organising appliance requires more than just putting it all together. We want it to have nice look and feel, be intuitive to work with, save you more troubles than it causes. A preliminary design is ready. Some of the prototyping too.

What is more interesting about this appliance is that we will use it to introduce internal project we’ve been working on for some time now. We are talking about secure, centralised configuration solution, scalable enough to handle datacenters. Our goal is to lower the bar for system administration of large number of devices, make it accessible and comfortable. We have several more devices planned down the road that will probably follow the same architectural schematics and depending on the success of this we may even provide stand-alone builds of the configuration system as separate product.

Stay tuned !

Management General, Tech

We’ve been working on an IPTV project for quite some time now. We have great part of the middle-ware, content distribution system and firmware for a number of set-top-boxes. However, with High-Definition becoming dominant standard we’re moving on to the HD world. We needed new platform for our HD-enabled enterprise system. And we found one. Actually, this new platform is almost perfect. We need to make some modifications to the distribution and middle-ware, but it is doable. Everything seemed fine. Until yesterday!

After playing for several hours with the device, hitting failure after failure, we started to suspect there is something fishy in our setup. Preliminary test showed everything on “our side” of the system is OK. But still no success. Everything on the “other side” seems to be OK too. But still no success. So … what can be the problem ?!

This is the moment when every network engineer should dig deeper. Capture some raw network data using tcpdump or Wireshark (I’d recommend Wireshark for being more user-friendly application) and start analizing it. Our experience with protocol development from the past paid off. Some digging in the network flow and reading the RFC, for the protocol in question, showed us where the problem is. For some strange reason our “so damn good” set-top-box refuses to follow the RFC by the book. It was trying to send requests to a server without previous session establishment. Well, what the heck, let’s just return “OK” message and see what will happen. Ten minutes later our server breaks the RFC too. It does not complain about out-of-session data. But the problem remains.

Digging a little deeper unveiled another mystery. Not only that the set-top-box expects out-of-session communication, but it actually expects specific kind of attributes and values during this packet exchange. We suppose this is some trick to limit usability to a subset of servers, approved by the manufacturer. The issue is open. We have two ways to address this problem: try to reason with the manufacturer to provide us with RFC-compatible firmware or reverse-engineer what we have and modify our middle-ware to cope with it.

Expect more on this saga soon. We will be struggling to provide you with the best IPTV experience possible.

Management General