-
Notifications
You must be signed in to change notification settings - Fork 1
TVersity Interoperability Guidelines
The TVersity media server supports the following industry standards for interoperability with client devices:
-
UPnP A/V - For client devices supporting the UPnP AV standard (which is the de-facto standard for connecitivity between devices in the digital home). This includes devices like game consoles, networked TVs, DVDs, Stereo Receivers, Digital Media Adapters/Receivers, Mobile Phones, Satellite and Cable set-top-boxes and more.
-
Web - For client devices with a web browser (XHTML-MP or WAP 2.0) and media streaming or downloading capabilities like Nintendo Wii, Smart Phones (e.g. iPhone), MIDs, mobile game consoles (e.g. Sony PSP), and more.
-
RSS - For client devices with an RSS reader that can handle enclosed media and either stream or download it (like the Sony PSP, iTunes/iPod and more).
-
Adobe Flash - Devices with Adboe Flash 7 or higher like the Sony Playstation 3 and the Nintendo Wii.
-
Windows Media Center hosted HTML - Devices and computers supporting Microsoft Windows Media Center hosted HTML or other compatible software.
-
REST API - For client devices that wish to build a custom user interface around a REST API. The TVersity REST API closely resembles the UPnP A/V standard with the exception that it makes use of REST instead of SOAP (for more information please check: TVersity Server HTTP Query API).
One of the unique capabilities of the TVersity Media Server is its ability to adapt media on the fly for any given target device. This requires knowledge of the device capabilities, and the media characteristics, and by correlating the two TVersity will either serve the media as is, proxy it or convert and proxy it.
Unfortunately this complex scenario is not properly addressed by any of the indsutry standards mentioned above, and while TVersity does not require any deviation from or extension to the standards, some client devices make implicit assumptions that result in poor interoperability.
-
Each client device model should use a unique ''User-Agent'' HTTP header that accurately identifies the device, the model and the firmware version. Without this TVersity won't be able to auto-detect the device and therefore its behavior won't be properly adapted for that device.
-
Client devices should not assume that the entire media is available to the server before the last byte has been sent to the device. This is because the media can be streamed over the web (live or on-demand) and/or transcoded on the fly.
-
Client devices should not do buffering as a fixed number of bytes, but rather they should do the buffering as a fixed number of seconds (using the bitrate of the media this can be translated to bytes on a per media basis). Failing to do so will result in long delays prior to media playback when low bitrate media is streamed off the web.
-
Client devices should not use short timeouts for the duration from starting a media request to the first byte of the response. The timeout should be at least 30 seconds (and even 60 seconds), otherwise Internet streaming may time out, this is especially true when the connection to the source is characterized with high latency and therefore significant buffering is done on the media server prior to making any media available to the target device.
-
Client devices should not assume the media size is known in advance. While TVersity always provides the ''Content-Length'' HTTP header, when transcoding is performed this is only the estimated size. The actual size will become evident once the entire media has been played, in such a case TVersity will close the connection and the client device can either assume the media playback is complete or can verify that the connection was not lost for some other reason by issuing an HTTP range request for the last few bytes of the file. In such a case TVersity will respond with the accurate file size in the response header.