|
|
| (36 intermediate revisions not shown) |
| Line 1: |
Line 1: |
| - | = ohMedia Overview = | + | =What is ohMedia?= |
| | | | |
| - | ohMedia is an open standard that allows the seamless interaction of media within your home. | + | OpenHome Media (ohMedia) is an open standard for networked audio devices in the home. Devices can implement ohMedia in place of, or alongside of, the UPnP Forum’s AV standards. It offers a number of advantages over the UPnP Forum's AV standards. |
| | | | |
| - | 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. | + | * Easier to program against. |
| - | <<picture>>
| + | ** UPnP forum services have large numbers of optional features. While this makes it easy for device manufacturers to implement a service, it is hard to write control points and interoperability between devices becomes poor. ohMedia uses options sparingly, typically at a service level. This enables clear, consistent behaviour across devices from different manufacturers. |
| - | 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.
| + | * Better support for playlists |
| | + | ** Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. your tablet goes to sleep, runs out of battery, or leaves the wifi zone). |
| | + | ** Multiple control points are supported. A second controller can discover and display a playlist setup by a different device. Edits to the playlist from either controller will be immediately reflected in the other. |
| | + | ** Storing playlists on the renderer also allows for gapless playback, avoiding gaps between tracks that were intended to merge seamlessly. This is particularly important for live albums and classical music. |
| | + | * Control the room, not just a device |
| | + | ** ohMedia topology algorithms allow multi-box systems to be easily managed from a single control point application |
| | + | * Easy to share music |
| | + | ** The Songcast protocol allows an ohMedia renderer to share its content with any other ohMedia device or listen to content from another device. Synchronised audio can be played between any number of devices. |
| | + | ** Desktop songcast applications plus mobile support (Songcast app for Android; Airplay receiver for iOS) allows content from many other devices to be shared. |
| | + | * Richer set of audio sources |
| | + | ** In addition to Playlist, Songcast and external digital and analogue inputs, internet radio and a receiver for Apple's AirPlay are also natively supported. |
| | | | |
| - | = Flaws in the UPnP AV Standard = | + | = Developers = |
| - | | + | If you are interested in ohMedia development, [[OhMediaDevelopers | further information is available]] |
| - | == 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).
| + | |
| - | | + | |
| - | = ohMeida 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. <<link to how it works>>
| + | |
| - | | + | |
| - | Problem 4 is solved through the ohProduct service specification and the ohTopology algorithm. <<link to how it works>>
| + | |
| - | | + | |
| - | Problem 5 is solved through the ohMedia server specification. <<link to how it works>>
| + | |
| - | | + | |
| - | 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. <<link to how it works>>
| + | |
| - | | + | |
| - | = How it works =
| + | |
| - | | + | |
| - | ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.
| + | |
| - | | + | |
| - | <<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>>
| + | |
| - | | + | |
| - | 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.
| + | |
| - | | + | |
| - | == 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.
| + | |
| - | | + | |
| - | <<diagram of a product with multi-in, one out>>
| + | |
| - | | + | |
| - | 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>>
| + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.
| + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.
| + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | Problem 4: No support for synchronised playback across products
| + | |
| - | | + | |
| - | The UPnP AV standard does not provide any solution to being able to synchronise playback across products.
| + | |
| - | | + | |
| - | | + | |
| - | The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.
| + | |
| - | | + | |
| - | The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.
| + | |
| - | | + | |
| - | The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.
| + | |
| - | | + | |
| - | The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.
| + | |
| - | | + | |
| - | The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.
| + | |
| - | | + | |
| - | How It Works
| + | |
| - | | + | |
| - | The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.
| + | |
OpenHome Media (ohMedia) is an open standard for networked audio devices in the home. Devices can implement ohMedia in place of, or alongside of, the UPnP Forum’s AV standards. It offers a number of advantages over the UPnP Forum's AV standards.
