TelVue’s Director for Systems Engineering, Chris Perry, gave an informative talk at the AHECTA meeting in Memphis, about IPTV system basics. Chris, never a fan of boring presentation slides, dispensed with the bullet points and cut right to the heart of the matter. In the audience was a mix of IT and TV operators and administrators, some of whom have already implemented IPTV, some of whom are just dreaming of it.
Keeping that range of expertise in mind, Chris started with this sample diagram of a working IPTV system (where green represents the IPTV portion of the system, blue=data, and red=SDI):
(Hard time reading the fine print? Download a .pdf version of the diagram here.)
Now there’s a lot of detail in that diagram, but the takeaway is this:
The first step is to get all video sources into IP form, whether the source is from a linear feed, signage, or even the output of a legacy analog router.
From there the video streams can go into a network switch and delivered to an IPTV server to centralize, manage, and stream out.
Finally, the media can be multicast straight into the network, or decoded to baseband for distribution over a baseband network, making IPTV a powerful, flexible, and scalable solution.
Chris also talked about LAN vs. cloud. Multicast, for the most part, is designed for a local area network, preferably at least a gigabit LAN. Multicast is an efficient way to distribute many kinds of data over a network, and that’s why IT departments, for example, might use it to distribute software packages to computers on their network.
But things are different when the public Internet gets involved. For example: MPEG2 Transport Stream (TS over IP), the standard for much of the IPTV broadcasting, is a reliable and stable format, but doesn’t travel well over the public internet, especially at 18mbps.
That’s why some live stream operations like LiveStream or UStream look at other ways to deliver HD video over the public Internet: like RTSP or RTMP, both of which are flavors of RTP – which re-orders packets – though with additional metadata. But this form of delivery is not infallible, and can break down under certain network conditions.
Apple developed HLS for their devices. HLS will chunk the video and stitch it back together, which allows for recovery from dropped data. Likewise QVidium offers streaming with a type of forward error correction, which can request a resend if a stream is missing something.
Chris went into some detail about software and hardware packages that can do Transport Stream Analysis, a key tool for troubleshooting an IPTV system. To make his point, he displayed a live StreamXpert program as it analyzed a multicast stream on our network, and showed how it checked the MPEG structures for problems along the way. It’s easy to see if a transport stream is having a problem that way. “You wouldn’t buy an analog system without a waveform monitor. Why would anyone think of running an IPTV system without a way of analyzing it?” Chris asked.
At this point a question from the audience launched a discussion about how to monitor a multicast system like the Knowledge Network, which is the first linear channel ever to be distributed over Internet 2. The Knowledge Network is a consortium led by the National Science Foundation, and dedicated to publicizing the best of research in institutions of higher education. The question was: How do you monitor a huge network?
The big operators have to do this all the time of course. Comcast, for example, has to monitor tens of thousands of streams, though not all at the same time. Stream analysis, Chris points out, is often a per-instance thing, rather than a need to monitor all streams all the time.
In answer to a question about what would be involved in making the transition from analog to digital, Chris had the following food for thought: “Making that jump requires a shift in many ways – it is a change of equipment, of your way of doing things, of a paradigm.”
He then followed up with some practical advice, about how to “phase in” an IPTV system by leaving the legacy system intact, upstream, and only weaning the operation off analog once everyone is comfortable with the workflow and the reliability of the new system. Another piece of critical advice is to get your network in order, installing new infrastructure to be able to handle, for a smallish operation, around 50 ports. And, of course, an IPTV server.
What about legacy infrastructures? Harnessing an existing infrastructure is invaluable for anybody who already has a big network in place. Cat 5e can carry up to gigabit ethernet and a lot of universities already have those drops in every room. Additionally when integrating with a legacy RF network the suggestion is to work with what they already have, especially since FCC regulations mean that anything made in the past five years is already ATSC compliant, and thus can handle clear QAM based signals. IP multicast video can very easily be converted onto QAM channels and then modulated onto the coax network.
So the recommendation is to gradually upgrade the edge locations to modern technologies over a couple of years, and once that is done, implement the rest of the solution. The IPTV transition can be done without wreaking a lot of havoc on your system, workflow, or personnel.
The last question was probably the most basic: Is there consensus that we are definitely going to an IPTV platform?
Chris’ point of view on this is that it starts to get into the theories behind programming. Do you want to sit home and select a program, or be fed a program to watch? We are going to see this sort of deployment for linear systems, but it will be interesting to see if the Internet as a distribution network is going to take over, and what form such a system would take. The truth is, we could already take most of the gear described in that IPTV diagram, and move it into the cloud and virtualize, making IPTV the ultimate solution.