Adobe technologies for video across the web, desktop, and mobile devices


 

Requirements
   
Prerequisite knowledge Required products  
This article assumes that you have basic knowledge
of using the Adobe Media Server and know how to run a
Flash based SWF client.

 

User level
All
 
 
This article introduces you to video integration across the growing collection of devices and screens supported by the Adobe Flash Platform ecosystem. After reading this article you should have a good overview of the benefits of the Flash video platform, an understanding of Flash based video options, and considerations for each type of device and screen, along with a set of resources for getting started.
 

Benefits of Flash video

 
Because of the reach and expansive capabilities of Adobe Flash Player, it is a great platform for video and media delivery across an ever-widening collection of screens. Since Flash video provides consistent codec support across different browsers, it can truly be cross platform and cross screen when approached properly. Adobe has been working very hard to provide not just the basics of video delivery on devices such as tablets, smart phones, and smart televisions but also ensure a consistent experience across emerging platforms and screens.
Building applications on the Flash Platform allow you to deliver your content to a wide range of devices. This means that users are able to engage with the same content from wherever they are, adding to the power and experience of that content.
Delivering video to a wide range of devices
Figure 1. Delivering video to a wide range of devices
  • Personal computers - over 97% worldwide
  • Mobile phones and tablets (iOS/Android/RIM)
  • Televisions (Google TV/Samsung)
For the user this means that they have access to the content they want (including video), when they want it. For content producers and those who deliver the content, this means they need to be conscious of the device consuming the video. Is it a high-power desktop computer or a device with limited processing power and a small screen? These questions now matter when building applications and creating the content that will be consumed.
The answers can be found in some of the existing and new capabilities of the Flash Platform:
  • Hardware acceleration for low CPU devices and/or HD quality media
  • Ability to deliver interactive, live and video on-demand experiences
  • Advanced peer-to-peer and multicast solutions for network and delivery optimization
  • Advanced user interface and immersive experience capabilities the Flash Platform has always offered.
These illustrate just some of the capabilities that the Flash Platform provides developers and consumers to enhance the experience of video on whichever screen you choose to use. This article addresses some of the main concepts for video delivery, concentrating on the knowledge necessary to create and deliver video content across multiple screens.
 

The Media Player

 
The media player is a fundamental component in any application that delivers video. Whether you are building a completely custom media player or starting with a framework like the Open Source Media Framework (OSMF), there are a few terms and concepts you will need to familiarize yourself with to build a solid understanding of delivering video across screens. Additional items that can affect how you build your media player can also include:
  • Network: Over what protocols will the video be delivered?
  • Security: Do we require our content to be secured and at what level?
  • Devices/platforms: What device(s) will be used to play the video?
The Flash Platform and integrated video solutions from Adobe provide excellent answers to these questions.
 

Custom Media Player

 
Custom media players can be built to suit any requirement or feature you can dream up. There are, of course, some trade-offs that you will encounter when building a media player from scratch. Many existing players and frameworks include a number of features that can be overwhelming to rebuild from scratch. At the core of any streaming Flash or AIR based media player are the following classes:
  • NetConnection: Manages the external connection to a streaming server/service if being used, or just provides the external management mechanism for HTTP based streaming
  • NetStream: Is the base class for actually loading and streaming media. Both the NetStream and the NetConnection provide various status information via a NetStatusEvent, and most if not all types of these events should be handled in some way.
  • Video: The Video class is the display object in which a NetStream (or Camera) is displayed to the end user. It is effectively the ‘window’ in which the media is shown.
Although building a very basic media player may be very easy and light weight, there are often many additional enhancements that will need to be made. Items like complex connection management and reconnection sequencing, the slight differences between Live and Video On Demand, as well as the complex integration requirements for such features as Dynamic HTTP Streaming often make custom media player development from scratch a daunting task.
 
Below are some of the pros and cons of custom players:
Pros

 

  • Light weight: You only use the classes that you want to
  • Granular control: You have direct access to the classes that are controlling playback
Cons

 

  • Development time: There is more development time upfront because you will be building everything from scratch
  • Support: You will be responsible for any new feature and/or changes that will need to be made to your player

Open Source Media Framework-Based Player

 

The Open Source Media Framework provides a supported and well thought out framework for building robust media players that can be tailored to fit nearly any media delivery requirement. By abstracting the complex media playback functionality, OSMF allows developers to concentrate on building better user experiences, while the powerful API takes care of the heavy lifting behind the scenes. OSMF also provides an amazing extensibility framework based on a plugin architecture which allows you to build your own plugins, or use others from the community.

The robustness of a framework can often be a drawback, especially when media load times and bandwidth usages are a concern, as it is with mobile devices, etc.

The componentized nature of OSMF solves this problem very intelligently. Developers can be selective when choosing what classes to include in their applications, as there’s no need to compile the entire framework into their .swf. Being able to include only the classes an application requires makes meeting player size requirements a much more manageable task. For example, despite OSMF’s powerful API, a basic player can be built that is only 9K in size.
Below are some of the pros and cons of OSMF players:
Pros
 
  • Extensible
  • Fully featured, with support for the latest Flash Player protocols and features
  • Adobe and community support
  • Powerful and easy to use the basics
Cons

 

  • OSMF has a steep learning curve
  • Gets very complex if you venture past the basics
 

Flash Media Playback and Strobe Media Playback

 
For developers who want all the benefits of OSMF but do not have the resources to invest in building a player from scratch, FlashMediaPlayback and StrobeMediaPlayback are great options. Flash Media Playback is a fully featured, production level OSMF player that Adobe hosts, and publishers can configure and embed the player on their web sites using an online tool. Strobe Media Playback is the open source version of the same player, and developers can either use it as is, or they can access the source code and customize the player to meet their needs.

Multiple Protocols

 
Delivering video to a wide audience can be quite challenging. Content providers need to take into consideration a constantly-expanding list of devices to deploy to, and often must navigate through restrictive networks, such as those found in many corporate environments.
The Flash Platform offers a full spectrum of delivery and capability options to deliver a professional level of video to any device across all the screens. An advanced feature that can be critical for multi-screen delivery is multi-bitrate switching - also referred to as Dynamic or Adaptive Streaming. Multi-bitrate switching automates changing between multiple streams of different encoded bitrates to adjust for performance or bandwidth limitations. Mobile devices truly see a benefit here, as their bandwidth can change drastically and often. Truly though, any screen will benefit from multi-bitrate content delivery and in general this feature is highly recommended and will be discussed further in the encoding section.
Following are the available protocols:
  • RTMP: Real Time Messaging Protocol
    Is a highly performant binary protocol built specifically for Flash. It can offer some of the best delivery performance and enhanced capabilities, but can be blocked by firewalls because it is not a standard HTTP protocol delivery. There are a number of variations of the RTMP protocol including RTMPE and RTMPS for encrypted streaming, and RTMPT for HTTP tunneling to help avoid some of the network blocks. This is generally the best solution for Video On Demand or basic unicast when using the Flash Platform.
    NOTE: AIR for iOS also supports RTMP but does not support RTMPE.
    • Live or on demand video, audio, and/or data streaming
    • TCP based
    • Tunneling over HTTP via RTMPT
    • Encryption with RTMPE or RTMPS
    • Supports Flash Access 2.0 DRM Encrypted streaming and downloaded content
    • Useful in multi-bitrate switching scenarios
  • RTMFP: Real Time Messaging Flow Protocol
    Is similar to RTMP in that it is a light weight binary protocol built for the Flash Platform, but instead it is generally used for Multicasting, Peer Assisted Networking, and Peer-to-Peer (P2P) based streaming of synchronized live content in most cases. It can also be used for Unicast streaming, and offers a number of benefits being a UDP based protocol, but can have challenges when trying to stream to users through certain NAT and firewalls.
    • Live or on demand video, audio and/or data support
    • UDP based
    • Supports unicast & multicast
    • Useful in multi-bitrate switching scenarios
    • Automatically uses a 128 bit AES encryption
  • HDS: HTTP Dynamic Streaming
    Is a HTTP transport protocol that allows H.264 and VP6 content to be packaged and segmented to enable streaming of video content to Flash Platform-based applications. Since the streaming is purely over HTTP this offers the most reliable delivery mechanism to reach all your users. OSMF has integrated support for managing the playback. It currently requires the use of a free Apache module available from Adobe, and for On Demand content does not require any other special server requirements. For Live HDS content a Flash Media Server is required to dynamically package and deliver the content.
    • True streaming over HTTP
    • Live and on demand video, audio delivery
    • Requires content packaging
    • Supports Flash Access 2.0 DRM Encrypted streaming
    • Useful in multi-bitrate switching scenarios
  • PHDS: Protected HTTP Dynamic Streaming
    Allows you to generate encrypted content without the need for a DRM License Server. When Flash Media Server packages the content, it generates the license and embeds it into the DRM metadata of the content stream. PHDS also supports SWF verification for HTTP Dynamic Streaming.
  • HLS: HTTP Live Streaming
    Is a HTTP transport protocol that lets you send audio and video over HTTP from an ordinary web server for playback on iOS-based devices such as iPhone, iPad, iPod touch, and Apple TV, as well as on desktop computers running Mac OS X.          
  • PHLS: Protected HTTP Live Streaming
    Flash Media Server allows you to create and serve protected content over HTTP to devices that support Apple HTTP Live Streaming. PHLS provides real-time AES-128 wire encryption.

Content Security

 
Getting your video delivered efficiently to the largest number of people is only part of the equation. Content often needs to be protected. Again, the Flash Platform steps up with solutions that allow you to secure your videos at multiple levels:
  • RTMPE & SWF Verification
    • User/Token Authentication
      • Client & Server
    • Requires Flash Media Server
  • DRM Using Flash Access 2.0
    • Industry approved standard
    • Coming to mobile and TV soon
    • Can be implemented as a service via BuyDRM & EZDRM
For more information on the various security options and configuration refer to these articles: http://www.adobe.com/devnet/flashmediaserver/security.html
 

Delivering video across screens

 
Now that you have a better understanding of the media player and the benefits provided by the Flash Platform for delivering your content, we can examine the intricacies of content delivery across screens. We will consider the following high-level ideas:
  • Content Creation & Encoding
  • Development Considerations
  • Testing & Debugging
  • Deployment Options
For each of these ideas we will address the three target endpoints that we think of as ‘screens’:
  • Desktop/Laptop
  • Mobile: Smart Phone/Tablet
  • Television

Content Preparation & Encoding

 
Encoding audio and video content can become one of the most complex and important steps when delivering media to any screen. With more screens the complexity increases as the requirements for each screen can vary. The same video that may look great on a phone will likely look very poor on a HD TV, so plan on creating content specific to screens. This will result in more files, but better optimization and experience for your end users. Instead of going into details for each screen in this article, the links below are provided for reference:

Hardware Acceleration

 
When deploying video to multiple screens, especially HD video to mobile devices, set-top boxes, and televisions, the end-user’s processing power must be considered carefully. By leveraging a device’s GPU (graphics processing unit), content providers can deliver higher-quality video experiences to a wider range of devices than they can when relying solely on the CPU to handle the processing load.  
 
StageVideo
 
With the release of Flash Player 10.2 for desktop, mobile devices, and TVs Adobe has added something truly amazing. It is called StageVideo and it offers the ability to offload the traditionally very CPU-intensive operations of both decoding and rendering to the video hardware on the computer or device. For the desktop this can enable the ability to playback full HD 1920p video with 20% CPU usage (or less, depending on the hardware and support). In general any hardware that supports H.264 decoding/rendering applications should see a decrease in CPU usage and likely see an increase in pixel fidelity. Aside from requiring Flash Player 10.2, StageVideo will generally only work in FullScreen mode unless you change the wmode to “direct” in the HTML Object/Embed code. There are exceptions to this as some of the next generation’s browsers are released, but it is recommended at this time set the wmode to “direct”. When compiling your application it is also required that you use a new compiler argument to generate a SWF with the proper support. The compiler argument is -swf-version and it must have a value of 11 (-swf-version=11). For more information on how to get this set up, please check out the article “Getting Started with Stage Video support in OSMF and Strobe Media Playback” by Andrian Cucu.
When using StageVideo for hardware acceleration it is important to know that the video will actually be rendered underneath the Flash Application’s display list in a flash.media.StageVideo rather than the traditional Video object. So if you have any background graphics they must be hidden or removed from the display list as they will be on top of the StageVideo.
Tip: If you hear your audio from the video but can not see the video this could be because something is overlaying the video with StageVideo in use.
For mobile devices and TVs, hardware acceleration is vital for optimal playback due to generally limited CPUs but powerful video decoders. The only mobile device platforms that currently support StageVideo are Android 3.0+ and the BlackBerry Playbook. However AIR for TV does currently have StageVideo support. Desktop implementation of StageVideo may support a number of simultaneous StageVideo instances but mobile and TVs generally will only support one instance of StageVideo at a time.
The following are properties of the StageVideo Class that you should familiarize yourself with:
  • StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY
    Dispatched on the Stage and indicates there is a change in the current availability of StageVideo.
  • StageVideoEvent.RENDER_STATE & VideoEvent.RENDER_STATE
    Dispatched by a StageVideoEvent is dispatched by a StageVideo instance and the VideoEvent is dispatched by a Video instance. The status property of the event indicates the hardware acceleration is in the following mode:
    • VideoStatus.ACCELERATED: The video is being decoded and composited through the GPU.
    • VideoStatus.SOFTWARE: The video is being decoded through software and composited by the GPU, if dispatched by StageVideo, or through software, if dispatched by Video.
    • VideoStatus.UNAVAILABLE: The video hardware has stopped decoding and compositing the video.

For more information on StageVideo see Thibault Imbert’s article: “Getting Started with stage video” - http://www.adobe.com/devnet/flashplayer/articles/stage_video.html
 
OSMF & StageVideo
 
The following points are specific to the use of StageVideo hardware accelerated video playback and the use of OSMF based players. Below are a few pointers to take note of:
Hardware Considerations
 
When developing applications, especially video delivery applications, for multiple screens, you will need to consider the following for each screen you want to support:
  • Device capabilities
  • Screen resolution, density & size
  • Flash Player versions and capabilities
  • Network requirements, type and availability

Personal Computers

 
Fast, powerful, and capable of displaying very high-quality video…sometimes. It can’t be assumed that, just because a viewer is watching your video on their desktop machine that they’ve automatically got the faster processor available, along with a GPU and the latest version of Flash Player. The smart application developer will plan for a variety of situations.
 
Device capabilities
Until recently, this is where requirements for an application have started. This platform has fewer limitations than the others. This means that creativity and features are, for the most part, un-bounded. You will need to think about the range of devices that your video will be delivered to so you can tune your content and applications for the best experience. Some things to think about are:
  • Operating System
  • RAM
  • CPU
Flash Player Version and Capabilities
You will also need to account for multiple versions of the Flash Player. This means that different functionality and capabilities will be supported depending on the version of Flash Player. It’s possible that a future version of the Flash Player runtime could alter how your application executes. To avoid runtime errors, and to provide the best-possible user-experience across devices, it’s important to account for this scenario. By modifying what features are available in the application, and by notifying users when changes are made, developers can ensure a smoother experience for the end user.  

 

Mobile: Phones/Tablets

 
Mobile is a platform that has exploded and Adobe has taken some big strides in providing tool sets that allow for mobile development across a wide range of devices. This brings us to our first consideration for the mobile platform. There are a large number of devices that will need to be considered when creating your content and building your applications. Considering the number of phones and tablets that are currently on the market, the ability to account and adjust for these different screens is paramount when creating your videos and applications.
 
Hardware Constraints
 
Each device you encounter can have different limitations imposed on your application by the device hardware. This means that some features cannot be available in your application from one device to another. For instance, the iPad doesn’t have a front facing camera where the iPad 2 does. New capabilities are added when new hardware is released, so you will need to determine what features are core to your application and target devices that have the capabilities to support the core features. Then additional and optional features can be added to the application and made available when the device supports the capabilities required for the additional features.
 
User Interface & Display Considerations
 
Across screens there is a wide range of display sizes and user interactions that need to be considered. This is made more complex by the differences in pixel density and physical dimensions that were not so much an issue historically. The mobile market has had a major impact on average pixel density and is no longer conformed to the standard 72 dpi. High resolution, small physical dimension screens add challenges in general and especially for video. The first is user interface elements. Now setting a simple width and height is no longer so simple. The pixel dimensions to maintain usability for a touch device for a UI control need to be roughly at least a half an inch. The simple width/height in pixels for a physical dimension needs to take in account the screen depth or DPI (Dots Per Inch) - in this case synonymous for PPI (Pixels Per Inch). Luckily the device DPI is available from the Capabilities object in ActionScript via the Capabilities.dpi property. To determine the physical size of a control take desired size in inches and multiply it by the device DPI.
The other challenge more directly pertaining to video, is with greater pixel density devices in turn require better quality video to maintain the visual acuity that becomes the standard for that device. This is of course manageable, but generally the larger the video dimensions are, the more bandwidth is needed to maintain quality - this can make video delivered via cellular data connections hard to maintain at high quality. Also the more pixels/resolution that needs to be rendered the greater the system hardware requirements.
The following outlines the basics for the needed details to make proper sizing decisions:
  • Resolution (Capabilities.screenResolutionX & Y)
  • Density (Capabilities.screenDPI)
  • Physical Dimensions (resolution/dpi)
An excellent article for understanding and applying key concepts for dynamically sizing multi-screen applications is Christian Cantrell’s article titled Authoring Mobile Flash Content For Multiple Screen Sizes http://www.adobe.com/devnet/flash/articles/authoring_for_multiple_screen_sizes.html
Paul Trani also wrote an excellent article called Sizing Graphics Correctly Across Screens:  http://www.paultrani.com/blog/index.php/2010/12/sizing-graphics-correctly-across-screens/
Aside from properly sizing the UI elements themselves (such as video control bar), the elements need to be designed and sized for the proper user interactions. On mobile devices where touch is the primary interface control, designs for the elements need to be appropriate for the resolution and the user experience. Consider the control bars below comparing possible UI differences across the screens.
Designing and sizing UI elements
Figure 2. Designing and sizing UI elements
 
Device Detection
Knowing what device your application is running on, or at least the capabilities of the device, is a tool that can help you to dynamically mold the application to suit the capabilities for optimal user experience. The flash.system.Capabilities class is the workhorse for detecting the type of device that your application is running on.
Generally when developing a cross screen application you will want to determine the following:
  • Is it a mobile device
    • If the Capabilities.cpuArchitecture equals “ARM” then its likely mobile
  • Determine what the physical size of the screen is (phone vs. tablet)
    • This is done by getting the Capabilities.screenResolutionX and Capabilities.screenResolutionY and dividing them both by Capabilities.screenDPI
  • There also may be special considerations for different operating system like iOS
    • To determine the OS use Capabilities.os
The following code snippet shows a rough skeleton that can be used for determining the platform and device from ActionScript.
protected function analyzeEnvironment():void { //if mobile processor if( Capabilities.cpuArchitecture=="ARM" ) { var dpi:Number = Capabilities.screenDPI; trace(Capabilities.os); //check if iOS. IF true don’t play h.264 var iOS:Boolean = Capabilities.os.toLowerCase().indexOf("iphone") > -1; //determine the size of the screen in inches - this is for UI controls var screenWidthInches:Number = Capabilities.screenResolutionX / dpi; var screenHeightInches:Number = Capabilities.screenResolutionY / dpi; //See if screen is larger than 5 inches; width or height if( screenWidthInches > 5 || screenHeightInches > 5 )// Tablet { if( iOS ) { //CONFIGURE IOS TABLET } else { //CONFIGURE TABLET } } else // Phone { if( iOS ) { //CONFIGURE IOS PHONE } else { //CONFIGURE IOS PHONE } } } else // Desktop { //CONFIGURE DESKTOP } }
 
Network Type & Availability
 
Knowing when the application is online and offline is an important factor with any application. With mobile applications, knowing when you are online and offline as well as the type of network you are on are important pieces of information you can use to make the user’s experience much better within your application. The ability to allow the user to work offline and then sync changes or updates when the user regains a connection or not allowing large downloads unless the user is on a Wi-Fi connection can mean the difference between your application being useful or unusable. In addition, there may be significant costs or restrictions associated with downloading large files over a pay-for-use network. For example, in the case of iOS, without the use of HLS streaming and an audio only channel Apple restricts application approval to streaming content under 10 minutes of duration.
 
File Size Limitations
 
File size limitation can not only affect the performance of the device and your application, but eating up too much space on a device with limited storage can be detrimental to an application destined for a mobile platform. Taking care to account for each byte you add to your application will help in keeping your application from being removed from a device because it consumes too much storage space.
It is recommended that you evaluate any frameworks that are being used in your application.

 

Platform Specifics
 
The following lists contain some key points of data for the specific mobile platforms. Many of these details have already been covered, but nonetheless are provided here as a quick-view descriptor for key points across each platform.

Android

  • AIR 2.6 and greater support

     

  • Android 3.0 and greater will support StageVideo

     

  • Varying hardware across each device

     

  • Varied screen size and densities

     

  • Supports all Flash Video playback methods

     

    • RTMP

       

    • RTMPE

       

    • RTMPS

       

    • RTMFP - Multicast & P2P

       

    • HTTP (HDS)

       

    • Progressive

       

  • All Flash supported file formats & CODEC’s

     

    • H.264

       

    • FLV

       

  • Flash Access DRM support

     

iOS

  • Cross compiled

     

    • iOS packaged AIR application cannot load SWFs with code

       

      • This can apply to media players if the control bar skin for instance is external
    • Can work on iPad or iPhone

       

  • RTMP & RTMFP is supported for Sorenson Spark and VP6 encoded content

     

  • RTMPE is not supported

     

  • Restricted video performance

     

    • Recommended no more than 600kbps

       

    • Think smaller dimensions

       

  • StageVideo hardware accelerated content is supported with H.264 in progressive playback or HLS for single or multi-bitrate streaming

     

RIM

 

  • Flash 11.1 & AIR 3.0 support

     

  • StageVideo is currently supported

     

  • Supports all Flash Video playback methods

     

    • RTMP

       

    • RTMPE

       

    • RTMPS

       

    • RTMFP - Multicast & P2P

       

    • HTTP (HDS)

       

    • Progressive

       

  • All Flash supported file formats & CODEC’s

     

    • H.264

       

    • FLV

       

  • Flash Access DRM support - coming soon!

     

  • Extended selection of codecs  - H.264, MPEG4 & WMV

     

 

Televisions

 
Adobe AIR for TV enables your AIR applications, games, services and content to be deployed to TVs. With up to 5 hours a day spent in front of the television this opens the door for your content to be delivered to many more consumers.
 
TV Development Considerations
As with all of the devices that we are discussing, there are some high-level considerations that need to be made when developing for TVs.
  • Device support - Television manufactures will be responsible for the certification of Adobe AIR on their hardware. This means that you don’t have to worry about the device capabilities in the same way that you would with mobile devices.

     

  • Make sure that when developing applications for TVs that you select the correct device profile.

     

  • Test on the device. We will cover this in more detail in the Testing & Debugging section.

     

  • TVs can be a difficult medium to develop for. They have large display screens but limited hardware resources. It is best to consider the performance capabilities of a TV as not better than a mobile device if not less.

     

Display Considerations
When working with AIR for TV you will need to consider the size of the screen for your applications. As a best practice use the Stage class to determine the following:
  • Resolution - When developing a multi-screen application that includes TV you can use the Capabilities.screenResulutionX and Capabilities.screenResulutionY to set the size for the stage.
  • Stage viewing area - Adobe recommends 7.5% on each edge of the stage to be reserved to account for overscan (the portion of the screen that is not visible). The diagram below and the accompanying link help describe the implications and considerations of overscan.
Implications and considerations of overscan.
Figure 3. Implications and considerations of overscan.

 

For more information on the TV stage and available area, please see the article “AIR for TV applications and the “safe viewing area” (aka “title safe area”)”, by Jackie Levy of the Flash Platform Doc team.
  • Quality - set the value of stage.quality using the StageQuality.High to specify the rendering quality of all Stage objects.
File System Limitations
As an AIR application, your application will have access to the file system of a Television. To protect the system files of the TV, AIR for TV applications have limited access to files on the device and the ‘directory’ names that you use to access files on the device are not the actual names of the directories on the device. This is done to avoid inadvertently accessing files on the device.
For some reference material see the Delivering Video And Content for the Flash Platform on TV: http://www.adobe.com/devnet/devices/articles/video_content_tv.html
 

Testing and debugging

 
Testing and debugging applications across screens can be a difficult task with the number of different devices that are available. Flash Professional and Flash Builder are both excellent tools that cannot only build these cross-screen applications, but can help debug any issues that you might run into as you are developing your applications. The quickest and easiest way to start your debugging is to use the ADL to simulate your device. This option exists for each of the platforms. Debugging on some devices can be more difficult than others, the following is a list of pointers for debugging in regards to each platform.

Deployment Options

 
Last but not least is deploying your finished applications to the world or region. In the mobile and TV space this is primarily done through the various application stores available through the providers. The application stores provide the best exposure possibilities as well as payment processing. Of course they come at a trade for such features, especially when money is involved and expect to share some of the profits with the store provider.The following references may be able to help along the way to getting the final release builds of your application published and submitted to their respective stores:
Where to go from here
 
This article has gathered and presented a lot of information for considerations and capabilities of video delivery across devices. It provides the ideas and resources for you to understand the implications of video application development across multiple devices. The fact that the majority of a code base can be used to create an application that can be deployed to so many different devices is a testament to the power of the Flash Platform and the work that Adobe has put into to making cross screen development a reality.
With the increase in available bandwidth, devices and power of those devices, video is an ever-increasing medium that can be used to reach, entertain and inform your users. The Flash Platform provides a powerful and flexible way of getting your content in front of your user wherever they are - on the train or in their living room.
 
Additional Resources:
Best Practices for Mobile Device Video Player Optimization http://download.macromedia.com/flashmediaserver/mobile-video-player-opt-v1_3.pdf