Difference between revisions of "Developer:Media Server Extensions"
(→Example) |
|||
| Line 1: | Line 1: | ||
= Introduction = | = Introduction = | ||
| − | The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. | + | The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outline some ideas that address the various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups. |
= High = | = High = | ||
| + | |||
| + | == Index maps == | ||
| + | |||
| + | Large lists are difficult to navigate, especially on mobile devices. Mobile devices added the idea of an index map to improve this situation. The index map allows a users to jump to different sections in a large list, similar to what is possible with a scrollbar on desktops. If a control point would like to generate an index map for any particular level in a ContentDirectory hierarchy the control point first needs to download all the objects in the container and then figure out how they were sorted and then calculate the index map. This is far more efficiently handled by the server. | ||
| + | |||
| + | The proposal is to add a desc element, that contains the index map, to the DIDL-Lite XML that is returned by the media server. | ||
== Image Resolution == | == Image Resolution == | ||
Revision as of 15:39, 19 February 2015
Contents
Introduction
The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outline some ideas that address the various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.
High
Index maps
Large lists are difficult to navigate, especially on mobile devices. Mobile devices added the idea of an index map to improve this situation. The index map allows a users to jump to different sections in a large list, similar to what is possible with a scrollbar on desktops. If a control point would like to generate an index map for any particular level in a ContentDirectory hierarchy the control point first needs to download all the objects in the container and then figure out how they were sorted and then calculate the index map. This is far more efficiently handled by the server.
The proposal is to add a desc element, that contains the index map, to the DIDL-Lite XML that is returned by the media server.
Image Resolution
Control points running on different platforms have different memory limits and display technologies. This means that a control point on a PC might want to display artwork at a high resolution, while a control point on a PDA might want to display artwork at a much lower resolution.
Media servers often try to solve this problem using one of the following two methods:
- A configurable parameter that scales all artwork to a user defined size
- A profile system where a user can create profiles for each class of control point they have and configure a parameter that scales all artwork to a user defined size per profile
The first solution is highly problematic because it limits the resolution of artwork across the whole network. But a single network very often contains control points that can display high resolution images AND control points that can't.
The second solution is just architecturally poor, turning the relationship between a control point and a media server on its head. Why should the media server try to infer what a control point needs through configuration when the control point is perfectly capable of telling the media server its exact requirements in every single circumstance.
So, it is proposed that compliant media servers include a size element in their artwork uri's, where the size is the image's largest dimension. This allows a control point to ask for an image at a specified size.
Example
If the original artwork was 400x512, then a media server would provide the following albumArtURI: <uri>?size=512. If it is not possible for the media server to obtain the original resolution then the media server would provide the following albumArtURI: <uri>?size=0.
The presence of the size element tells the control point:
- the media server implements the image scaling extension
- the original size of the image.
Now the control point can request the image at any resolution by using <uri>?size=x, where x is the size it wants.
So, in this example, <uri>?size=1024 gets an 800x1024 image, and <uri>?size=200 gets a 156x200 image.
albumArtURI
The current specification only allows retrieval of artwork for a musicAlbum container through the property albumArtURI. When browsing a music library on a control point it quickly becomes clear that to implement a graphically rich control point the ContentDirectory service should provide a way to retrieve artwork for all of the content directory classes, not just musicAlbum containers.
There has become a somewhat defacto standard where just about all media server provide an albumArtURI property for a musicItem item as well as for a musicAlbum container, however this is still not good enough to implement a graphically rich control point.
It is proposed that an optional property is introduced to the object class called albumArtURI which may contain an attribute title, e.g. <albumArtURI title="Font Cover">http://Front Cover.jpg</albumArtURI>. The object class can contain zero or more albumArtURIs elements.
Medium
Low
Dynamic IP Addresses
At present all media servers return URIs that contain a reference to their IP address, e.g. http://172.20.1.1/music.flac etc. This means that if the media server's IP address were to change across reboots, then any control point or media renderer with URIs that referenced the media server before the reboot will become invalid.
It is proposed that a media server should always reference itself by host name and not by IP address in any XML that it sends to external devices, i.e. http://mynas/music.flac.
Disc Information
It is proposed that two new properties are added to the musicTrack item called OriginalDiscNumber and OriginalDiscCount
Replay Gain Information
It is proposed that four new properties are added to the musicTrack item called ReplayGainAlbum, ReplayGainAlbumPeak, ReplayGainTrack, and ReplayGainTrackPeak.
webURI
The current specification does not easily allow a control point to provide rich information about objects in the browse hierarchy.
It is proposed to add an optionally property to the object class called webURI which will contain a URI to a website that provides a rich collection of information about the object, e.g. for a musicArtist container it would provided a link to a website that provided information about the artist.
