Difference between revisions of "Developer:Media Server Extensions"
(New page: = Introduction = The ContentDirectory service, (one of the services found in a UPnP media server), has various limitations which become apparent when implementing control points on ...) |
|||
| Line 7: | Line 7: | ||
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 become 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. | 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 become 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. | 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> | |
It is proposed that a new property is introduced to the object class called '''ArtworkURI''' which contains a list of URIs.''''''<br> | It is proposed that a new property is introduced to the object class called '''ArtworkURI''' which contains a list of URIs.''''''<br> | ||
| − | + | <br> | |
For pragmatic reasons the property should perhaps be called '''albumArtURI'''as I suspect that the vast majority of control points in the market today do not use the class type to figure out what properties to parse from the DIDLLite XML and so will automatically use the albumArtURI property if it present in the object's XML description. | For pragmatic reasons the property should perhaps be called '''albumArtURI'''as I suspect that the vast majority of control points in the market today do not use the class type to figure out what properties to parse from the DIDLLite XML and so will automatically use the albumArtURI property if it present in the object's XML description. | ||
| Line 32: | Line 32: | ||
These systems are fundamentally flawed as they are trying to infer what a control point want, rather than allowing a control point to ask the media server for the information it wants. | These systems are fundamentally flawed as they are trying to infer what a control point want, rather than allowing a control point to ask the media server for the information it wants. | ||
| + | <br> | ||
| − | + | It is proposed that the albumArtURI URI allows a parameter '''size''' to be specified. This parameter '''size''' allows a control point to ask for the artwork 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 artwork 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. | |
| − | It is proposed that the albumArtURI URI allows a parameter '''size''' to be specified | ||
Revision as of 10:58, 12 April 2010
Introduction
The ContentDirectory service, (one of the services found in a UPnP media server), has various limitations which become apparent when implementing control points on different hardware platforms. This document outlines some ideas that address some of the ContentDirectory specification's shortcomings.
Artwork
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 become 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 a new property is introduced to the object class called ArtworkURI' which contains a list of URIs.'
For pragmatic reasons the property should perhaps be called albumArtURIas I suspect that the vast majority of control points in the market today do not use the class type to figure out what properties to parse from the DIDLLite XML and so will automatically use the albumArtURI property if it present in the object's XML description.
Artwork Resolution
Every hardware platform that a control point is written on has different constraints, e.g. memory limits. This means that a control point on a PC is capable of displaying images of a high resolution, where as a resource limited PDA can only display images of a much lower resolution.
Currently available media servers try to solve this problem in various ways,
- 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 want, rather than allowing a control point to ask the media server for the information it wants.
It is proposed that the albumArtURI URI allows a parameter size to be specified. This parameter size allows a control point to ask for the artwork 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 artwork 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.
