Ivi TV: Let's see how long this lasts (Updated with new information)

Ivi, Inc., a Seattle-based company, has launched what it calls a "revolutionary" live television application. For $4.99 (U.S.) per month, they will stream the live feeds from 16 over-the-air television stations in New York City and 10 from Seattle straight to your computer. Their feeds include ABC, CBS, Fox, NBC, PBS, Telemundo, Univision and other affiliates, as well as independents.

Update, 14 September 2010: Ivi seems to be trying to take advantage of U.S. Copyright law that was written well before the advent of the Internet, while simultaneously avoiding FCC rules that make the company's plans patently illegal. (Keep in mind that I'm not a lawyer, so I'm bringing a layman's knowledge to the situation.) In the Code of Federal Regulations, Title 37, Section 201.17, "cable systems" as defined by this statute are entitled to retransmit ("secondarily transmit") television stations' signals under a statutory (or "compulsory") license. The cable system pays a royalty based on its revenues to the U.S. Copyright Office. This portion of the statute was written in 1978, almost 20 years before the commercialization of the Internet, and it didn't contemplate a technology that would make a national cable service feasible outside of FCC regulations.

The FCC has its own rules on permission and compensation for retransmitting the signals from broadcast television stations. Here's a direct quote from the FCC's Fact Sheet on Cable Carriage of Broadcast Stations:

The Communications Act prohibits cable operators and other multichannel video programming distributors from retransmitting commercial television, low power television and radio broadcast signals without first obtaining the broadcaster's consent. This permission is commonly referred to as "retransmission consent" and may involve some compensation from the cable company to the broadcaster for the use of the signal.

If ivi is a cable operator or other multichannel video programming distributor, the FCC's rules require the company to get permission from broadcasters before they retransmit their signals.

Under Title 37, Section 201.17, ivi claims that it's a cable system and has a right to a statutory license to television stations' programming, no matter where they're located. However, ivi claims that it's not subject to regulation by the FCC, and therefore is not a cable system. CFR 37 Section 201.17 says that cable systems are entitled to statutory licenses, even if they're not defined as cable systems by the FCC.

So, what's likely to happen? My suspicion is that there are many high-paid attorneys at the television networks and cable operators working on this right now. One option would be to get the U.S. Congress to amend or repeal Section 201.17, since the FCC's rules supercede it. Another option would be to get the FCC to rule that ivi is a legitimate cable operator, and the fact that it owns no plant doesn't mean that it's free from FCC regulation. A third option would be for programming suppliers (the major networks, movie studios and syndicators) to file suit against ivi, charging the company with interfering with their exclusive distribution contracts with local television stations outside the New York City and Seattle markets. These suppliers could petition for an emergency injunction to shut down ivi's service.

Ivi might have a better case than I anticipated when I first wrote this post, but I still believe that it's only a matter of time before it gets shut down. It may take a year or two for the necessary statutory changes to be put into place, but a preliminary injunction can be put into effect in a matter of weeks, or even days.

Capstan Channel Syndication: A format for syndicating time-based video

A few months ago, when I had an unexpected amount of time to myself, I began looking at what it would take to put video content on the set-top boxes from companies like Boxee, Roku and Popbox. It became clear very quickly that it would take a lot more than simply posting a bunch of videos to the web. Each one of these platforms has its own API, its own content description format and its own developer program. Some platforms give the set-top box vendor the power to control which content is made available to its customers. It presents a Tower of Babel for content suppliers.

On the other hand, you've got RSS, which is as close to a universal content syndication format on the Internet as you can find. RSS works extremely well for static content; what I mean by static in this context is that everything in an RSS feed is available right now, not at some point in the future. Video on demand (VOD) works fine with RSS; when you upload a new video, you update your RSS feed and either push the information to clients or let them pull the information from your server.

Broadcast and cable television work in a different way. They use schedules: Certain episodes of certain series are scheduled at specific times on specific days. Those episodes (and the program segments that comprise them) may or may not be made available on a VOD basis at a future time. RSS isn't designed for that--an RSS feed can tell you what's available right now, but not what's going to be available a week from Tuesday at 0800 UTC. It doesn't give client developers enough information to build a unified interface to live, scheduled and on-demand programming, all at the same time.

There are several other issues: The same episode of a program can shift from scheduled, to live, to on demand, over time. Content providers may want to make video available on a pay-per-view or subscription basis, so they need ways of authenticating viewers, protecting their content and processing transactions, and they would much rather not support different systems for every set-top box and client vendor.

I looked hard at making RSS do all of this, and yes, it can be done with Namespaces, but it would be like cutting the back end off of a sedan, welding on a truck bed and calling it a pickup truck. It's much better to develop a new XML Schema that's purpose-built for the application. And so, that's what I did.

I call the result Capstan Channel Syndication, or CCS. Why Capstan? Capstans are the metal spindles that guide magnetic tape through audio and video tape recorders, and I thought that "capstan" would give a retro feel to a format that's designed specifically for Internet video in the 21st Century. Rather than go into the details of CCS, there's a more detailed description of what it's for here, and a downloadable copy of the specification here.

I've made CCS available as open source under Apache License 2.0, the least restrictive widely used open source license I could find. Neither I nor my consulting firm have a horse in this race--I'm not working on, promoting or investing in any video client, set-top box or Online Video Provider companies. If you want to participate in the process of defining CCS, I invite you to do so at the ccs-format Google Code site.

I'm hoping that CCS will be adopted by client and set-top box developers to enable them to get access to much more content without having to write and market their own APIs, and by content providers who will be able to write one CCS specification instead of a different application for every client and set-top box. Adopting CCS doesn't preclude anyone from writing and promoting their own APIs, so client and set-top box developers can still encourage content providers to take advantage of special capabilities of their platforms. However, my hope is that CCS will become the "baseline" for making time-based video available on the web.