Use StageVideo. Always.
For best video playback performance and to minimize CPU and better battery consumption, using StageVideo for rendering video is strongly recommended. StageVideo leverages the browser’s hardware accelerated rendering pipeline and GPU wherever available.
Starting with Flash Player 15, and when the swf is compiled for swf version greater than 26, the Flash Player will provide a software version of StageVideo as an automatic failover option when hardware StageVideo is not available. As such the content does not need to implement a Video object failover. The Flash Player will always try to use the hardware accelerated StageVideo first and only if the browser version and the GPU version does not support it, then it will automatically fail over to software version without any need to implement any fail overs in the App.
There should no longer be any reason to use the Video object, as StageVideo will always be available.
The StageVideoAvilability in this case will ALWAYS be “available”, the reason will always be “noError”. If it is not able to support HW StageVideo for some reason and fails over to SW StageVideo, it will indicate that failover with a StageVideoAvailability event, and its property called “driver” will be set to “software”.
Use of wmode=direct is recommended. For all the newer browsers as mentioned below, all the wmodes will support hardware accelerated StageVideo rendering. But some older versions of the browsers that do not have hardware rendering support will fail over to software StageVideo if the wmode is not direct. The only reason to not use wmode=direct will be if the app needs to render html overlays on top of video. Newer browsers will be able to support html overlays on any wModes, but older browsers that do not have hardware rendering support, will not be able to support html overlay for wmode=direct.
IE 11: IE has an accelerated pipeline and the FlashPlayer is HW accelerated in all wmode, so HW StageVideo should always be available. Note that the decision to use the HW accelerate rendering pipeline reside in IE itself, there are probably cases where it will fallback to older software pipelines when the driver or OS is too old. It is also possible for the user to disable the HW acceleration in the settings panel.
Firefox: There is currently no HW accelerated pipeline available in Firefox on windows and only wMode direct will have HW StageVideo available all other wMode should failover to SW StageVideo.
Chrome: Pepper has HW acceleration in all wMode, but some restrictions apply. For example Chrome will refuse to use HW acceleration on Windows XP and it has its own driver blacklisting mechanism. It is also possible for the user to disable the HW acceleration in the settings panel. Chrome exposes a somewhat useful page to allow one to see the status of its gpu acceleration: chrome://gpu/
Safari: Apple’s browser uses CoreAnimation to render the HTML pages and all wMode should expose HW StageVideo.
Firefox: This browser also uses CoreAnimation to render the pages and all wModes should expose HW StageVideo.
Chrome: Pepper HW acceleration is available like it is on Windows and all wMode should expose HW StageVideo, with the same limitations as the windows version.
StageVideo should not be used before the availability event is fired. Before this event, StageVideo is basically not initialized at all. The timing of this event is somehow dependent on the browser and it should not be guessed. You cannot base your code on a specific browser/os combination. This will be true even with the software version of the API.
Just before the StageVideoAvailability event is fired, the StageVideo array is populated with a fixed amount of planes, usually 4. At that time a stream can be attached to the plane for rendering.
The app should continue to listen for StageVideoAvailability event, if it wants to track HW or SW version of StaegVideo, as the event might be fired again when the status changes.
Once attached to a StageVideo entry, you can play the content and use its properties to move it around, zoom, pan…
- Is stageVideos.length>0 even if it’s software StageVideo?
Yes, length is for stageVideo in general, either hardware or software. Also, the length of the vector can sometimes be zero. Rather than polling the length of the stageVideos vector manually, to implement stage video correctly, you should always listen to theStageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY event. This will inform you about stage video ability. SW StageVideo is enabled when the swf is compiled for swf version 26 and above, and is supported since Flash player 15. If so the StageVideoAvilability will ALWAYS be “available”, the reason will always be “noError”.
- Is there an API to check if hardware acceleration is enabled (boolean value) or is the presence of stageVideos.length>0 enough?
Stage video availability event has a property called driver that will be “software” when it is using Software StageVideo.stageVideo.length is not representative of HW or SW StageVideo and should not be used. With SW StageVideo you can always expect this to be > 0.
- How does the value of HW Acceleration in right-click Settings panel impact StageVideo availability?
It will disable HW acceleration and HW decode. Stage video software and software decode will be used.
- What is the best way to check for StageVideo availability before trying to load video content?
The StageVideoAvailability event is called independent of video playback, so it can be checked at any time. It is recommended to be checked before it’s used, so it should be checked before it is attached to NetStream.
- Is StageVideo available to all streaming formats ?
Yes, StageVideo rendering is available for progressive, rtmp, appendBytes, or HLS formats.
- Where can I find more information on StageVideo?
Getting started with StageVideo
Clean up NetStream after use
In order to conserve memory usage for video applications, its very important that any GPU or memory resources being consumed by the app are released and cleaned up.
NetStream object holds the buffered video data and handle to HW decoders so its very important that the object is cleaned up after its used. This is specially important in the case of applications which create multiple NetStream objects and switch between them for displaying ads or to implement video playlists.
To clean up NetStream resources call Netstream.close() which will release all buffers and HW decoders and is ready for re-use if it needs to be recycled for another stream. If the NetStream isn’t needed anymore, call NetSteam.dispose() instead. In both the cases, detach the attached StageVideo object to it, by calling StageVideo.attachStream(null) which will also stop video playback and release the StageVideo object for another stream.
Special thanks to Abhinav Kapoor for putting together this article.