Simplifying StageVideo with StageVideoProxy

Adobe recently took a large step in changing the way video gets rendered in the Flash player. For the most part the player has always taken a large role in rendering video to the screen. With the release of Flash player 10.2 this has all changed. Now if you explicitly tell the player to, you can offload the video completely to the hardware which decreases CPU usage (literally to 0%), lowers memory usage, enables higher frame rates, and overall enables greater pixel fidelity and video quality.

Obviously with all the upcoming phones, tablets, and connected TVs this has an even higher impact on a video applications experience. At Dreamsocket we’ve been fortunate enough to be an early adopter with projects on these platforms. From developing video player’s tailored for Android phones to creating Cartoon Network and Adult Swim’s GoogleTV apps, we’ve been able to see the impact this new change has, in addition to figuring out the best way to integrate it into existing applications.

All that said, the one thing that really struck us was how unique the new StageVideo API is. I say unique because it is a completely new API and is completely different than working with the Video object. I understand the differences, however do you really need to force someone to go back and recode everything just to use it? I know it forces a user to explicitly think and spend time putting StageVideo into an app, but why? It should be EASY. I mean really EASY.

Enter StageVideoProxy. We wanted to go into all of our video applications and simply swap out a Video object reference for a new Class that would use StageVideo if present and fallback to using a standard Video object if it failed. By having a simple class that extended Video, we could just swap out the instance and proxy all the calls to StageVideo when it was available. This made it EXTREMELY easy to retro fit any existing application with StageVideo functionality. In addition, we kept all 10.2 API references in places that would not get called in players below 10.2, making the code backwards compatible.

Super right? Well we did find a few limitations. First, StageVideo doesn’t really have a way to clear the video, so we had set the size to 0 width and 0 height to “clear” it. Second, we don’t really know depth of display objects vs other display objects easily, so we don’t have a way to determine z depth for the videos. The second step doesn’t really matter though, given the implementation currently only supports a single StageVideo instance. I’d like to add support for multi videos, but I’m still unclear on how many I can have and what dictates that. I understand how to know when they are there and when you hit your limit, but I’d still like to fully understand it before I add it in.

Regardless, this is super useful code so merry nerdmas! Here you go in all its MIT licensed glory