From OpenHome

Revision as of 16:31, 30 July 2012

ohMedia Overview

ohMedia is an open standard that allows the seamless interaction of media within your home.

ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers. This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.

Developer information is also available here

Flaws in the UPnP AV Standard

Problem 1: No support for gap-less audio

The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.

Problem 2: No support for a user's playlist to continue playing when a control point is turned off

The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.

Problem 3: No support for multiple control points

The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.

The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.

When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.

With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.

Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system

A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.

The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.

Problem 5: Media's URI changing when media server rebuilds its database

The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).

ohMedia Solutions

The ohMedia standard has been designed to solve all the problems described above.

The first three problems are solved through the ohPlaylist service specification.

Problem 4 is solved through the ohProduct service specification and the ohTopology algorithm.

Problem 5 is solved through the ohMedia server specification.

The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back.

How it works

ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.

The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.

ohProduct and ohTopology

ohMedia models a home as a number Hi-Fi systems, which are located in rooms.

ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.

A product is modelled through the ohProduct service specification.

When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,

1. discover all the products in the home that have an ohProduct service
2. group the discovered products based on the room they are in
3. create a hierarchical tree structure by matching source names to product names
4. discover source functionality based on source type
5. discover additional functionality based on product attributes

e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.

<!-<picture of example>-->

Sources

ohMedia defines four source types,

1. Playlist – product supports on device playlists
2. Radio – product supports internet radio with presets
3. Receiver – product supports receiving ohSongcast broadcasts
4. UpnpAv – product also implements the UPnP AV media renderer specification

If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.

Attributes

ohMedia defines three attributes,

1. Volume – product supports volume control
2. Info – product supports providing information about the currently playing media
3. Time – product supports providing the current time within the currently playing media
4. Sender – product supports ohSongcast broadcasting

ohPlaylist

The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.

The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.

The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.

ohSongcast

<<to do>>

Server

<<to do>>

Developers

If you are interested in ohMedia development, more information can be found here