Televisions and devices supporting TV Apps are highly tuned to decode and display video using optimized hardware. For this reason, the Engine uses the TV/device to fetch, decode, and display video. Performance and media format support differ for each device based on the product decisions made by the manufacturer. Each device provides its own hardware acceleration and proprietary media player.
This section provides the TV App video encoding specifications and tips for testing video playback.
Video playback behavior and performance in the Simulator are not representative of video playback behavior and performance on a TV/device.
The Simulator uses the video playback software library GStreamer to decode and render video. Typically, the software rendering provided by GStreamer is much slower than hardware optimized rasterization. You may find that for certain videos, the audio and video playback is not in sync. This is not representative of the media player behavior on Connected TV devices, but is an artifact of the Simulator’s use of GStreamer. Detailed specifications for each device’s media player implementation do not yet exist. You can go to http://connectedtv.yahoo.com to find out more about Connected TV devices.
If you have trouble testing video in your TV App please follow these recommended steps:
export KF_GSTREAMER_USE_ALTERNATIVE_PIPELINE=1
MediaPlayerSample app (located in $HOME/YCTV-ADK/YCTV-SIM-Latest/TV/Widgets/) as a template for using the KONtx.mediaplayer API.
tv.mediaPlayer.load("http://mycompany.com/test/test.mp4");
tv.mediaPlayer.play();
You must run the commands above from a fresh start of the Simulator to avoid an inconsistent state. If these commands fail there may be a problem with the media player installation.
"Invalid argument" from the gstreamer
pipeline may be caused by the sound server. Try setting the sound server to ALSA or PulseAudio instead of auto-detect. Try to playback the
stream by entering the following command in the Simulator Console:
gst-launch playbin uri=http://mycompany.com/test/test.mp4
file:///noise.mp4).
To ensure that your TV App’s video works on all supported TVs/devices the following encoding specifications have been verified on all Connected TV devices. Deviating from these recommended video encoding parameters may render the video incompatible with deployed or legacy systems.
Progressive download over HTTP is supported. Many encoders have an option to enable Internet streaming where the stream is buffered so that playback starts before the whole clip is fully downloaded.
Some device-specific media players support seeking to particular times inside a piece of media by jumping to a relative or
absolute offset.
Video-seeking and time index changes require a special version of GStreamer (0.10.23) to test on the Simulator, so typically
time index testing occurs on the
TV/device. To support stopping at a particular point in a video, the event onTimeIndexChanged fires at one second intervals. Currently none of the devices in production support fast forward and rewind over HTTP streams.
Other supported streaming protocols vary by device. Currently one device partner supports MMS and other device partners will be supporting M3U8 and RTSP late in 2010 and early 2011. Existing devices can support a video playlist of URLs, but do not support a continuous open stream. The Engine also supports redirection for the video playlist URLs.
Currently play-listed progressive download is being used for radio apps. HTTP streaming audio is supported through a fullscreen view where you have exclusive access to the audio pipeline. In fullscreen mode, there is no mixing with any other audio signals. You cannot playback audio (or video) from the sidebar view, as it will be mixed with the audio from the TV Channel. Play-listed progressive download is supported by the current Connected TV devices, but a continuous open stream is not supported. The playlist can be a series of audio files, which play one after the other over an HTTP stream. The majority of our platform partners have all specified they are supporting HTTP live streaming protocols in their 2011 devices. Some partners will come out with updated firmware for existing devices as well. Currently our WDK Development Simulator supports live streaming for your development needs.
The following encoding formats have been tested and work across all Connected TV devices:
Optional. Both Constant Bit Rate (CBR) and Variable Bit Rate (VBR) are supported.
Yahoo! recommends choosing one resolution based on your source video’s size, and then encoding your videos in multiple bitrates to support varying connection bandwidth. The KONtx.mediaplayer chooses the best stream given the current connection speed returned from KONtx.speedtest. Support for the following video bitrates is recommended:
The recommended audio bitrate is 128 kbps for standard bitrate quality.
All devices are HD compatible and have a 16:9 aspect ratio. However, the device’s available network bandwidth limits HD resolution to 1280 x 720. PAL resolutions are supported. Depending on your content source, the following pixel resolutions are recommended:
Optional.
Optional.
Optional. Typical frame rates of 29.97 fps for video-based source material and 23.97 fps for film-based source material are supported.
Typically devices cannot buffer more than 100 MB of video. If the video metadata moov atom is at the end of the video, and the video size is larger than the device’s buffer size, the device’s media player will not play the video. Some media players can fetch the video metadata from the end of the file but not all devices support this behavior.
Some encoders, for example Quicktime, have options for Internet streaming which put the video metadata at the front of the file. For Quicktime, the qt-faststart utility rearranges the top-level atoms by shifting the moov atom from the back of the file to the front, and patches the chunk offsets along the way. This utility only operates on uncompressed moov atoms. To move the metadata to the front of the file run:
qt-faststart original.mov new_file.mov