Difference between revisions of "Developer:Media Server Extensions"
| Line 1: | Line 1: | ||
= Introduction = | = Introduction = | ||
| − | The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. | + | The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups. |
| − | == | + | = High = |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Image Resolution == | == Image Resolution == | ||
| Line 32: | Line 18: | ||
<br>It is proposed that all image URIs allow a parameter '''size''' to be specified. This parameter allows a control point to ask for the image at a specified size, e.g. if the media server provided the URI http://server/artwork.jpg then the control point would make the following request to get the image at a resolution of 512x512, http://server/artwork.jpg?size=512. It is then up to the media server to try and service this request as best possible. If the size parameter is omitted from the URI then the media server will supply the artwork in its native resolution. | <br>It is proposed that all image URIs allow a parameter '''size''' to be specified. This parameter allows a control point to ask for the image at a specified size, e.g. if the media server provided the URI http://server/artwork.jpg then the control point would make the following request to get the image at a resolution of 512x512, http://server/artwork.jpg?size=512. It is then up to the media server to try and service this request as best possible. If the size parameter is omitted from the URI then the media server will supply the artwork in its native resolution. | ||
| − | == | + | == albumArtURI<br> == |
| + | |||
| + | 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. | ||
| + | |||
| + | <br> | ||
| − | + | 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. | |
<br> | <br> | ||
| − | It is proposed | + | 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.<br> |
| + | |||
| + | = 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.<br> | |
<br> | <br> | ||
| − | + | 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. | ||
<br> | <br> | ||
| − | It is proposed | + | 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. |
Revision as of 15:59, 28 June 2010
Contents
Introduction
The ContentDirectory service has various limitations which become apparent when implementing control points on different hardware platforms. This document aims to outlines some ideas that address various shortcomings of the ContentDirectory specification. The ideas have been categorised in low, medium and high priority groups.
High
Image Resolution
Control points running on different platforms have different memory limits. This means that a control point on a PC is capable of displaying images of a high resolution, where as a control point on a PDA can only display images at a much lower resolution.
Currently available media servers try to solve this problem using one of the two methods below,
- 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
These systems are fundamentally flawed as they are trying to infer what a control point wants, rather than allowing a control point to ask the media server for the information it wants.
It is proposed that all image URIs allow a parameter size to be specified. This parameter allows a control point to ask for the image at a specified size, e.g. if the media server provided the URI http://server/artwork.jpg then the control point would make the following request to get the image at a resolution of 512x512, http://server/artwork.jpg?size=512. It is then up to the media server to try and service this request as best possible. If the size parameter is omitted from the URI then the media server will supply the artwork in its native resolution.
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.
