With the all-new Kindle Fire and the Kindle Fire HD, there are several changes to the way media is handled in the browser. The biggest change is that Flash is no longer supported in the browser, due to significant changes to the version of Android used on the devices. Instead, our HTML5 support is improved, with support for both the HTML5 <video> and <audio> tags.
On the new tablets, as with the Kindle Fire (1st Generation), we open an Android player activity to handle playback, rather than playing video embedded in the browser. This approach means the referring web page will not be visible during video playback. We’ve also chosen to disable auto-play to prevent a jarring customer experience where page load would be immediately followed by a jump into full screen video, with no initiating action by the customer. Instead, the auto-play attribute is ignored, and JavaScript calls to play video are disabled until after the customer has interacted with the page at least once. Note: As long as a document remains loaded the 'has interacted' state is preserved, it is only reset when a new page is loaded or the existing page is reloaded.
Because video is handled by the Android player, HTML5 features such as custom controls or drawing over the video are not going to work as expected. We do bridge some video status events from the external player into the browser's JavaScript environment, but we recommend you not try to control playback using the JavaScript API as the customer experience is likely to be confusing.
The browser gets updates from the Android player activity and will emit JavaScript events to simulate how an embedded video would work. Supported events are: loadstart,loadedmetadata, loadeddata, durationchange, canplay, canplaythrough, play, waiting, playing, progress, timeupdate, pause, ended, abort, emptied. Other events such as those for seeking, rate changes, volume changes, etc. should not be counted on. Since customers can't see the browser pane while video is playing, we discourage any reliance on these events. The most useful event in our current implementation is the ended event, emitted when the video window is closed either due to hitting the back button or reaching the end of the video. In either case, the video will appear to have played to completion. Duration events provide accurate duration times, but we don't generate regular progress events, only the ended event.For the moment there's no way to start a video playback anywhere other than at the beginning, seeking is not supported. Pause works, though using it will probably not provide the best customer experience as any web UI that would normally accompany this event would not be visible. Of course, customers will be able to skip forward and backward, pause, and so forth using the native controls of the Android player.
We currently support MP4 and WEBM video formats. If your<video> tag contains multiple formats we'll prefer MP4. The audio encoding in video streams must be at most stereo, the Kindle Fire family of devices doesn't support 5.1 audio. RTSP and HLS are supported by the Android player activity, for details on formats see http://developer.android.com/guide/appendix/media-formats.html.
We know that publishers want support from the browser for embedded video and that is something that we’re investigating.
Image support has also been improved. In addition to all the expected browser image formats, we now support SVG via both the HTML5<svg> tag and .svg resources in <img> tags.
We fully support the HTML5 <audio> tag and playback happens in the browser. The default controls are improved from earlier devices, and custom controls are supported. Playback of multiple streams works as expected. MP3, OGG, and WAV audio are all supported, and JavaScript support is good, enabling algorithmic PCM Audio using data URIs, for example.
There is no current support for any kind of background audio, meaning that audio playback is paused when a tab loses focus.
Click "Continue Reading" for a complete list of supported formats.