In our IBC shorts last week we at least over-simplified the contribution that Digital Fountain is trying to make to video quality for IPTV, using its Forward Error Correction Technology, and following up with them we felt it was worth a re-visit.
‘Within three weeks of any IPTV system rolling out HD either we, or someone like us gets a call,’ says Alex Hayward, Director of IPTV at Digital Fountain.
The potential for visual artifacts, those glitches on the screen caused by some damage to an I-Frame, goes up as more data is being sent across a network, and the more compressed it becomes. In fact as encoder manufacturers get more and more experienced with the H.264 standard used for HD encoding, the more damage a single lost or corrupt packet can be in IPTV. For instance the standard allows for B frames and P frames to refer back not to just the last I-Frame, but all the I-Frames in a scene including the one coming next.
In this way if a scene is flashing between two faces in a conversation, then the delta frames will be far lighter if they take their starting point from one of the I-frames created around the correct face.
But that means that a single error on that I-Frame can recur throughout a scene. H.264 encoding is in its infancy, and so many of these techniques are not yet used, but they will be, making it ever more important that data integrity is ensured.
There are two ways forward, one is to use the TCP/IP protocol or something like it to request packet resends, and the other is to send correctional codes so that lost data can be ‘calculated’ from the packets that did get through ‘ or Forward Error Correction.
Packet resends are used at the application level in the original Fastweb system, and it uses UDP for distribution, so that packet resends do not operate at the protocol level, as it does in TCP. This has become the de facto way of handling IPTV since Fastweb first installed it.
It creates a bandwidth overhead, and similar solutions are being offered by Cisco (no-one has taken it up on its offer yet) with a series of products called Visual Quality Experience (VQE), effectively a network appliance that services requests for replacements for lost video packets. Cisco sits this in the 7600 Series routers that drive the multicast sessions, but store the next few hundred milliseconds of each channel stream in case there is a request for a retransmission. The round trip lasts less than 100 Milliseconds, which is less than the buffer period in most existing IPTV set tops. Microsoft’s MediaRoom we understand, has something similar programmed into its D servers.
Digital Fountain has already been selected as the FEC of choice for DVB-H and MBMS, the two mobile TV standards, and now it is spearheading the FEC approach in IPTV.
The more scientifically gifted of you out there might be able to follow the maths behind the Digital Fountain Raptor codes, but for those of us that either can’t or don’t want to, they are based on the ideas behind Fountain and Luby Transform (LT) codes which are pretty well understood these days in mathematics, invented by one of the founders of Digital Fountain Michael Luby in around 1998. Since then he and others have helped moved along the Luby Transform over the past few years.
The Raptor codes are when an outer code is used to transform packets of data, and then a piece of each packet is stored or sent in multiple other packets. Suffice it to say that to reconstruct packets when a network is suffering a loss of roughly 10% of those packets, you need to send around 110% of these packets, creating a 10% overhead. The codes are linear, in that in order to be in good shape to recreate 20% of missing or corrupted packets, the system needs to send 120% of the original number packets, 5% needs 105% etc..
The system can be layered so that from point A to B in a network you might expect a loss of 3% of packets, and so tune the FEC to send 3% extra packets, whereas from B to C the system might be shown to lose more data, and so more packets are sent.
In fact the Digital Fountain Raptor codes can be arranged to correct a different amount of loss for each line that is linked to a DSLAM, with no change on the set top software. In this way the FEC can be applied to meet the packet loss expectations of individual lines, where interference or partial packet delivery has been experienced, even if it is not understood why this is happening. It’s a simple case of sending more packets to that destination, and they are decoded in the same way. So if a customer keeps complaining, then that customer can have better protection against data loss.
Digital Fountain has already used this idea of each line needing a different level of protection in the Netherlands where the IPTV had interference created by the electromagnetic interference from the tram system, something the designers had not come across before.
‘People talk to us about having bit error rates of 10-8 on their networks, but it doesn’t work like that. That may be the performance of their network measured over a long time, but for just a small period of time an individual customer may have a packet loss of 10% or 12%.
‘What they actually have is a Quality of Experience problem and that leads to high churn,’ said Hayward.
‘We definitely view those offering packet retransmission as rivals,’ he went on, ‘the problem with retransmission is that there are always scalability issues, and each server or router resending packets can only deal with so many set tops.
‘But at some point in the future a hybrid system using FEC and then packet resend for the few packets that are lost, might work,’ he conceded.
One of the problems with retransmission approaches is that they are almost always custom built. Packet resends can’t be used in a multicast because one request for a lost packet will mean the packet is retransmitted to everyone, and since most packet losses occur once the streams separate after the DSLAM, that would mean resending virtually every packet, with the resulting chaos. So they all use multicast and then some kind of unicast back channel to deal with the resends.
There has been a similar problem with the FEC approach until now in installing the FEC, which was usually placed OEM into another piece of equipment like the encoder or loaded onto a blade and put into the head end. That meant that the FEC was changed at the source of the stream, so every set top needed to have the same level of protection.
Digital Fountain decided to partner with IPTV server specialist Neptuny, creating its ToughStream Server product from Digital Fountain on any standard Linux box. Neptuny ensure that the device can be deployed in redundant configurations with low switching times to enable continuous, uninterrupted, service.
This set up creates multiple layers of FEC at the center, and any single layer or multiple layers can be used by set tops.
‘It takes us about 3 weeks to integrate our FEC into a new set top, another 6 weeks to test and optimize it,’ said Hayward.
‘The system doesn’t put any strain on the new set tops, the Sigma chips that are used for most HD easily have enough processing power to cope. The system load at the set top is a little like the load that DRM places on the set top, no more, and it requires just a tiny piece of memory to process in,’ said Hayward.
Already the approach is being pushed into IPTV standards through the DVB Project, and it looks like yet another standard will emerge based on the Raptor codes.
The sole province of FEC used to be wireless broadcast networks, because they are one way, with no return path to request packet re-transmission, but in this implementation we are seeing the first breakthrough on a fixed line. We’re sure that more and more touches will be added, over time, to the sophistication of FEC, and the likelihood is that a specialist outfit like Digital Fountain is largely where this progress will come from. And given the rates at which data, and especially digital video data delivery is going up and up, we wouldn’t bet against FEC being more economic than packet re-transmission in fixed line broadcast applications.