Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
The Pulpit

<< [ The Great Apple Video Encoder Attack of 2007 ]   |  The $7 TV Network  |   [ When is a TV not a TV? ] >>

Weekly Column

The $7 TV Network: Neokast brings multicasting to the masses.

Status: [CLOSED] comments (73)
By Robert X. Cringely

The architects of TCP/IP, Bob Kahn and Vint Cerf, knew exactly how they'd bring television to the Internet. They would use multicasting, a particular IP service that allows many hosts to share a multicast address and, through that address, receive the same content whether that's rocket telemetry or Wheel of Fortune. Multicasting was seen as the most efficient way for one computer to talk simultaneously to a million others and that capability has been built into every router pretty much since the beginning, though generally not enabled by the network administrator. A decade ago Cisco Systems bought Judy Estrin's Precept Software and its IPTV video product specifically to throw television on the web and hopefully encourage admins to turn on multicast support. No such luck. That is until next week's Video on the Net show in San Jose when a start-up from Evanston, Illinois will introduce Neokast, which is effectively multicasting for the masses. Soon every computer will be able to broadcast to the world.

Multicasting hasn't broadly succeeded before now primarily because it places a large burden on the routers, which are responsible for caching and retransmitting video. Multicasting is generally turned off in routers to save bandwidth and keep the network running as fast as possible. Cisco wanted to turn multicasting on for IPTV specifically so the routers would slow down and have to be replaced. With Cisco it always comes down to routers and how to get people to buy new ones. That's evident in Cisco's purchase this week of WebEx, where we can expect Cisco to strongly push video services on those two million WebEx customers, straining the system and forcing hardware upgrades. It's not about Microsoft; it's about the routers.

Precept Software found that video worked well on a LAN but poorly on a WAN, where lack of multicast support required creating VPN tunnels that were just too much overhead for last-century PCs and networks. Much the same applied to the Mbone, or Multicast Backbone experiment from the late 1990s. Academics will argue that Mbone was a success, but if that were truly the case, why aren't we watching TV over Mbone today?

Neither our PCs nor the Internet were ready for multicasting in 1997, but today they are, the trick being to somehow enable an efficient multicast-type experience without turning on multicast support in the routers, where multicasting remains switched off.

Enter Neokast, the brainchild of a PhD candidate from Northwestern University, Stefan Birrer. Neokast uses peer-to-peer technology to effectively emulate a multicast experience.

Neokast presently operates as a .NET application, meaning it is limited for the moment to Windows computers. The player can operate as a stand-alone application or a browser plug-in. And as far as the user is concerned, connecting to a video stream is a matter of going to a web site and clicking on a link. The viewing experience is very much like cable or broadcast TV because with Neokast you aren't initiating a video stream, you are joining a broadcast in progress. There are clever ways to use Neokast for video-on-demand, but right now the company is emphasizing its broadcast-like features.

The way the P2P components work is simple to describe but hard to accomplish. I watched a Neokast demo from my office in Charleston and the stream began playing in about two seconds, which is close to instant-on in the world of Internet video. If there is buffering happening, as there simply must be, it isn't a very big buffer. Had there been no peers up and running other than mine, the video would have streamed straight from the server in Chicago, but with enough peers operating, the load on the originating server is several orders of magnitude less than for typical one-stream-per-user distribution.

For content creators this is key: the more people who watch your Neokast the more efficiently will your server bandwidth be utilized. According to Birrer, under normal circumstances the server bandwidth should plateau at 3-4 times that of a single stream NO MATTER HOW MANY VIEWERS ARE BEING SERVED. With a per-stream bandwidth of 700 kilobits per second, this means that Neokast would never require more than a continuous three megabits per second of server bandwidth per video channel.

Let's put that in a real-world context. Three megabits per second is almost precisely 1000 gigabytes per month, which is half the allotted monthly throughput for a $6.99-per-month web site at 1&1. So if Neokast's claim is valid, it would be possible to broadcast American Idol or the Super Bowl or friggin' CNN worldwide for $7 per month.

Heck of a deal, eh?

Neokast is not a video technology, it is a networking technology, so there is no proprietary video codec. For the moment Neokast uses Xvid because its free licensing appeals to a bunch of grad students programming out of several apartments in suburban Chicago. But Neokast could just as easily use another codec like H.264, possibly improving its video performance, which I found already quite acceptable.

Here's what makes Neokast different from other peer-to-peer products, especially BitTorrent. Unlike BitTorrent where you are downloading a file, with Neokast you are intercepting a video stream. Under normal circumstances the client does not end up with a local copy of the complete video, the P2P caching aspect of the product being limited to a few seconds or at most minutes of content. This makes video rights management much easier and ought to appeal to TV networks and movie studios.

Also unlike BitTorrent. Neokast is scrupulously polite. According to Birrer, the key technology is Neokast's flow-control algorithms that help the program to play well with networks and with other applications. Neokast gives a preference, for example, to local peers wherever possible, allowing a single copy of the show to come through your Comcast or AT&T gateway then ricochet around inside the local subnet, thus limiting the local ISP's Internet bandwidth hit to not much more than the native 700 kbps. This trades inexpensive intranet bandwidth for much more expensive Internet bandwidth.

Neokast uses a varying combination of TCP and UDP packets and looks to the network a lot like web surfing, so it is difficult for ISPs to limit the program with traffic shaping. But why would ISPs even want to limit Neokast? They ought to encourage its use as a more efficient protocol.

There may well be other products that can duplicate Neokast. Certainly there are others that claim to. But the ability to stream live TV is rare on the Internet, and Neokast's claim to carry live programming with no more than a 10 second total end-to-end delay might well be unique.

Neokast will be shown for the first time in public next week at Jeff Pulver's Video on the Net conference in San Jose, but for a sneak peak you can watch a short video I made about Neokast this week, interviewing the founders. That video is among this week's links.

Neokast comes from a company mysteriously called Metis Enterprise Technologies, LLC when they ought to have simply named the company Neokast. And no, I don't have any financial interest in Neokast, but thanks for asking.

The people behind Neokast have the goal of making everybody a broadcaster. I can see Neokast appealing to established TV networks or local stations that could put their present products - commercials and all - straight up on the net. It might appeal, too, to movie studios that like the idea of viewers watching without being able to necessarily copy the film. But the news implications of somebody setting up a webcam from their window in Baghdad or Darfur and serving a truly global audience is what appeals to me.

Of course it will eventually be harder to do than I have described here. 1&1, for example, would balk at having their bluff called on that loss-leader bandwidth allotment. Just finding what you want in a million-channel world would be hard, too, though less hard than figuring out what to put in 24 hours of programming per day.

All Cringely, all the time? I don't think so.

Comments from the Tribe

Status: [CLOSED] read all comments (73)

There was an interesting company that developed an AI application for parsing video. The idea was that keywords and scene shifts would automatically be used to index video streams. You could search to find the segments that you were interested in, instead of being forced to watch the whole thing.

They had sold it to CNN and others back around 2000. Great for news material! Great for 'cutting to the bottom line'.


William Halverson | Mar 27, 2007 | 2:06PM


Lonny Martello | Mar 28, 2007 | 2:37PM

Just had to note that Linux will run .Net applications (some at least). See

A. Lloyd Flanagan | Mar 29, 2007 | 3:12PM