Adobe officially unveiled the P2P video streaming capabilities of Flash 10 to developers this week. The technology itself is still in its infancy, but the mere fact that Adobe decided to embrace P2P for Flash 10 made a lot of headlines earlier this year. Many people, including Om over at GigaOM, wondered whether Adobe was taking aim at the CDN market with this technology and whether we will soon all watch our YouTube videos in a P2P fashion.
The short answer is: We won’t — at least not with Adobe’s help. The current P2P implementation, which goes by the name Real-Time Media Flow Protocol (RTMFP), isn’t really suited for mass-scale video delivery. Instead, it focuses solely on scenarios in which one client exchanges live video or audio data with another client. Think video conferences, Flash-based VOIP or even multi-player games. Just not YouTube. Not anytime soon.
RTMFP is essentially based on the idea that real-time video or voice interaction between two users of Flash or Air applications shouldn’t have to deal with the latency and bandwidth burden of a server-based relay. It’s just faster and cheaper to let the kids talk amongst themselves. Adobe does use a central server to authenticate users and facilitate the exchange of the data, but the actual video streams flow directly between the users of the application in question.
Graphic from Adobe’s RTMFP FAQ.
So who is running that server? RTMFP will eventually be supported by future versions of Adobe’s Flash Media Server, but the company wants to first integrate it into its new Cocomo cloud services, which went into beta last month. For now, only a subset of all Cocomo servers run by Adobe support RTMFP, but Adobe developer Nigel Pegg assured me that his team hasn’t seen any capacity problems just yet.
Pegg first wrote about the new protocol earlier this week on Adobe’s Collaborative Methods blog, detailing how Flex developers can add RTMFP support to their applications with a few lines of extra code. He told me that one of the big advantages of this solution is that it switches effortlessly between centralized and P2P data delivery. “We tend to see performance degradations after a certain number of receiving participants is reached,” he said.
One example for such a problem would be if you use a Flash P2P video chat and your broadband connection simply can’t support to serve all participants. “What’s cool about how Cocomo approaches this is that, once that limit is reached, Cocomo’s foundation classes swap down automatically, in mid-stream (to server-based video delivery)”, Pegg explained.
Speaking of video delivery: Adobe goes to great lengths to dispel the myth that it plans to P2P-ify all web-based Flash video with this new protocol. “Flash player 10 will not enable swarming, multi-cast or broadcast quality live video,” the protocol’s FAQ (PDF) reads, and it goes on: “RTMFP will have no impact on the business of a CDN.” The company even tries to avoid the acronym P2P completely, instead talking about client-to-client streaming.
Of course, the fact that Adobe doesn’t support any YouTube — or even Ustream-like environments — with RTMFP doesn’t mean that the company won’t go down that road eventually. Adobe CTO Kevin Lynch told Om earlier this year that the company is “taking small steps” and “using P2P in a very basic form” to make sure it doesn’t break web video. Which could mean that this is a first step down a potentially very disrupting path.