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.