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.
Concentric Hosted IT
Solutions and Web Hosting
Click here to save cost on your IT demands
