Adobe Gives Details On FMS 3 Benchmarks, Live Streaming and DRM
At StreamingMedia.com, we operate seven different e-mail based discussion lists based on various topics with over 5,000 members. Our lists are free to join and it's a great place to get answers to your questions from others in the community. One of our most active lists is the "advanced" list where more of the technical discussions take place.
Last week Adobe gave some public info on the benchmarks for the new Flash Media Server 3 and also
addressed the topic of live Flash and DRM. Here are some excerpts on the info they gave out.
Flash Media Server 3 Benchmarks
"The benchmarks for Flash Media Server will be out shortly. I can leak that the numbers will show a staggering difference from the version 2 of the product. We are seeing 200% on Windows 2003 (SP1; Standard) increase in both VOD and Live capacity given the same hardware. In Linux, the numbers are over 300%. The key factor for streaming servers is the threshold of how much CPU usage someone will run. Similar to how high you rev the engine to get your speed. We’re seeing a 1Gbps network card saturated with just 20% CPU on Linux. Given this is our lab, which we use as a baseline for testing. RTMPE (the new real-time Encryption protocol) only adds an addition 10% to the CPU usage."
Flash Player Adoption
"We all know that Flash Player is ubiquitous across both the consumer and enterprise markets. This is the core runtime required to render a video, and connect via RTMP or encrypted RTMPE protocol to FMS. We just published the December 2007 census and Flash Player 9 now enjoys a 97% penetration in mature markets."
Flash Live Quality
"Live video in Flash can be done in 3 ways."
1) Using the Flash player’s live capture feature (SPARK/Nellymoser Codecs); (webcam quality)
2) Using Flash Media Encoder (On2/MP3 Codecs); (good quality at higher bitrates)
3) Using 3rd party partners such as ViewCast, Kulabyte, Digital Rapids and many of the ones that support Ben’s initiatives. You can see a list of them on the Adobe website.
"Adobe will also be releasing an update to the Flash Media Encoder to support H.264 live streaming in a couple months. This should put aside many of the “quality” concerns you may have. H.264 is higher quality video at much less bitrate."
Addressing Digital Rights Management (DRM) With Flash
"You will be hearing a lot more about this from Adobe over the next few months, but from a streaming point of view, DRM is built on top of 2 key requirements; Encryption of content and Access Control. When you break it down, to protect content from mis-use, you need to protect the bits as they leave the server and before you get the bits, you need to protect the access (i.e. creating a policy)."
"Streaming to Flash resolves both of these requirements WITHOUT a DRM server and WITHOUT any disruption in the playback to download a key. To set the stage, RTMPE and RTMPS (SSL version) encrypts the video bits in real time as they leave the server, and render on the player. There is no client cache (as there would be with a HTTP delivery) so you don’t need to worry about people stealing the bits after they have arrived. There is also a very advanced set of APIs that let you build out your own policy rules for accessing the content. Out of the box, you can protect access to the server using SWF Verification or Domain white listing or even restrict by version of the player. You can build time-out tokens, or anything else you need to protect the delivery channel, and the playback. Because your user is always connected to the server, you have full control over policies for content access."
Experience Does Matter
"Flash / Flex are just one part of the experience process. It’s not just the adoption of the run time that makes Flash Player / AIR the best choice to deliver these experiences. Often times we all focus so much on the adoption rate of Flash player. There is a reason why the proliferation of Flash is so ubiquitous, and there is a reason why Adobe is seeing the fastest adoption of new players then ever before in its history. The reason is from planning to playback – from the person shooting video, or designing the video player experience to the person consuming the video."
"By understanding the workflow of the creative designers and developers and ensuring that their workflow are made as easy as possible using the tools they use every day (Photoshop/Illustrator/Premiere/AfterEffects/Soundbooth….) When you make life easy for people making content, more content will be produced on the platform – it’s really that simple. All the other pieces are in place to ensure content protection, quality and reach so all that effort can be monetized and protected."
Sounds like we will be hearing a lot more news from Adobe about these topics very soon.




Windows Media Server has been able to peg a 1GB connection for YEARS so a 200% increase over WMS, when Adobe's POS server couldn't even do 20% of WMS currently is totally unbelievable and unrealistic.
No I haven't seen it given the products previous performance capabilities I say no way.
Posted by: BS | Friday, February 22, 2008 at 11:58 PM
Hi Dan,
I am a newbie to this streaming biz. But, I don't understand one thing you have mentioned, so I would greatly appreciate if you could clarify it for me:
You have mentioned that "The key factor for streaming servers is the threshold of how much CPU usage someone will run." As I understand streaming, the core CPU usage should happen only on the client side as it tries to render the stream in real time. The server is essentially an I/O device: it picks up a file from the disk and puts it out onto the network interface. And if the h/w is designed properly, I guess most of this heavy lifting (moving data from disk to n/w card through the bus) should happen through DMA. Which means that the CPU should "practically" not figure in the whole discussion. If that understanding is correct, then what should really matter, and thus be counted, is the internal bus bandwidth, not CPU utilization. Am I correct on that? If not, what am I missing? Please explain.
Regards,
Mahesh
Posted by: Mahesh | Saturday, February 23, 2008 at 08:34 AM
Hi Mahesh, the comments in the post are Adobe's, not mine. I don't have enough expertise when it comes to this topic to be able to say what is best or what it should be.
Your best bet is to join the discussion list where this topic is being talked about and ask your question.
Posted by: Dan Rayburn | Saturday, February 23, 2008 at 10:38 AM
Mahesh, CPU has always been a bottleneck for FMS, especially when it comes to live streams but also for on demand. Remember that FMS can take webcam originated streams and make them available to other users. With this architecture I have deployed some popular videochat applications and quite often we maxed out the server CPU on a fairly beefy setup when 1500 or so streams were being pushed. With FMS3 this has become less of an issue and the CPU hit has been a lot less.
Like it or not, but CPU does take a hit in line with concurrent streams, both live and on demand.
Posted by: Stefan Richter | Saturday, February 23, 2008 at 04:55 PM
This is not old news but a nice recap.
I follow Flash and digital media a lot.
I personally think the more interesting topic here is what Adobe plan to do with this technology. I wrote a blog called.
"Adobe’s plan for world domination"
http://www.crafted.com.au/blog/2008/01/31/adobe%e2%80%99s-plan-for-world-domination/
Where I look at the future digital media in the living room and Adobe.
But back to the questions people have asked.
FMS2 was mainly JAVA based. Java is a good back end system for Web sites, but it is not known for line level performance. You need real coders doing a real programming language. (C++ and in some case machine code). It is not hard to get interface max performance then. General computers are so powerful these days.
This is especially important if you are planning to generate thousands of keys for DRM requests. This needs to be fast.
So really, the reason why FMS3 took time is probably because they were re-writing a lot of it in C++.
This explains the dramatic improvement in performance, but really, it is probably on par with Windows media server now (If that matters to you.)
James
Posted by: James Gardiner | Saturday, February 23, 2008 at 04:58 PM
BS,
I think you misread the article. They claim that this new version of FLASH media server is running at 200% over their first version, NOT 200% better than Windows Media Server.
Also, they said that they can pump out a constant 1GB rate into the network using only 20% of the servers CPU.
I didn;t see any comparisons to Windows Media Server at all...
Posted by: not total BS | Saturday, February 23, 2008 at 07:04 PM
I'm myself a reseller of a flash live solution
and my understanding is that flash is better
in the client side that in the server side.
flash video often appears to work better in http than in rtmp , is that a feeling shared by others ?
Posted by: damien wetzel | Monday, February 25, 2008 at 06:58 AM
..Reading between the lines i find a big gap when it comes to DRM - it looks like FMS has only got COnditional Access sorted - so it is catching up with Helix as of 4 years ago, but still not really offerring a DRM?
Its nicely written, but content control which only exists when the content is served from a specific type of server is NOT DRM it is Conditional Access, and it is wrong of Adobe to promote thier product as a DRM capable product at this point.
Posted by: Dom Robinson | Monday, February 25, 2008 at 07:42 PM