12:42 a.m.
Hi,
I've more information about URI in PlayList DIDL_S file.
About URI, there is a way to describe an URI without using IP/domain name
information.
There are 2 solutions, DLNA PlayContainer URI and DLNA PlaySingle URI.
Unfortunately, these solutions could not be used for DIDL_S playlist items.
We also thought the main advantage of IP URI is the possibility to create a
playlist with various items, from the server or on the net or on the local
storage.
Wrong, URI shall be from the same media collection.
About the URI format, in the DIDL_S description, it's said we should follow
various Guidelines:
guideline 7.4.1.3.10:
7.4.1.3.10 MM URI Rules
7.4.1.3.10.1
[GUIDELINE] If a content binary conforms to a DLNA media format profile,
then the URI value shall be an absolute URI, with the IP address in the
a.b.c.d IPv4 address format (i.e. quad-form network byte order).
NOTE: This guideline mandates that content URIs will use absolute URIs that
use IP addresses.
7.4.1.3.10.2
[GUIDELINE] URIs shall be properly URI-escaped in a UTF-8 encoded form.
NOTE: This guideline requires UPnP AV endpoints to provide URI values that
are URI-escaped in a UTF-8 encoded form. This guideline also allows a UPnP
AV MediaServer control point to assume that URIs obtained from a UPnP AV
MediaServer do not need any escaping.
-----
So, to resume, with DIDL_S we must provide IP URI.
With DIDL_V, we should provide PlaySingle URI.
We face 2 issues, one with the device, one with Rygel.
If a device is configured without a static IP/Port, when the device is
restarted and Rygel relaunched, we will have a new IP/Port.
All DIDL_S files previously created have now invalid IP URI for the
playlist items.
There is 1 hack that could be implemented in Rygel to fix these issue. As
we know all DIDL_S items reference an object in the media collection of the
DMS, we could replace all IP base address of each item with the new IP/Port.
It's evil. It's a hack. It's the only solution I think about to fix the
problem with DIDL_S file and dynamic IP.
There is a second solution that will be to use DIDL_V instead of DIDL_S
files.
With DIDL_V we could define DLNA PlaySingle URI that are not IP/Port
dependent.
But that imply to have a PlaySingle URI encoder/decoder and to update the
renderer to be able to use DIDL_V/Playsingle URI.
-----
I also found these information:
MM playcontainer-param (DLNA PlayContainer Flag)
7.4.1.3.31.1
[GUIDELINE] The playcontainer-param flag indicates support for a DLNA
PlayContainer URI operation. If the flag is true for a protocolInfo, then
it means that the UPnP AV MediaRenderer can play that type of content in a
DLNA PlayContainer URI operation.
The playcontainer-param flag shall be false when the context of the
protocolInfo involves a media collection binaries (e.g. DIDL_S and DIDL_V
playlist files). Furthermore, when performing a DLNA PlayContainer URI, the
MediaRenderer shall not render media collection binaries when traversing
the CDS hierarchy. Note that this restriction against playing media
collection binaries applies only to media collection binaries defined by
the DLNA guidelines.
So I need to set these flag to false when creating a Playlist.
It's not clear yet if I should set this info for each item, or for the
playlist item.
--
Ludovic Ferrandis
Open Source Technology Center
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
2:28 a.m.
Hi Ludo,
Thanks for investigating this. So to summarise, it seems to me that
there are 3 ways control points can create playlists on DMSs that
reference DMS content.
1. They can create playlist items on a DMS containing a M3U/DIDL-S file.
This is nice and simple but it suffers from the problems you mention in
your email, in that these files contain URLs and not ids of DMS objects.
Unless you have tight control over your DMS and your network
infrastructure, these URLs could become obsolete simply by restarting
your DMS or by losing your DHCP lease.
2. They can create playlist items on a DMS containing a DIDL-V file that
itself contains PlaySingle URIs rather than real URLs. This way the
items in the playlist can always be resolved to the correct URL,
providing of course the relevant server is still connected to the
network and the referenced files still exist. The problem here, and
this is a big problem, is that this will only work on DMRs that support
both DIDL-V and PlaySingle URI. Bear in mind that PlaySingle URI
requires the DMR itself to be a control point so that it can resolve
server and object IDs to URLs, i.e., it would need to use something like
media-service-upnp. I doubt there are many renderers that actually
support PlaySingle URI.
3. The control point creates a container in which it creates either
references to media items that exist elsewhere on the server or objects
with an existing res element that contain PlaySingle URIs. The DMS can
then automatically publish a res on the container that points to a
DIDL-S file containing URLs for all the items in the container. This
file can be generated on the fly by the DMS and so it will always
contain valid URLs. Note that the case where PlaySingle URIs are
allowed in the container would require the DMS to be able to resolve
PlaySingle URIs from other servers. The DMS would also need to support
CreateReference.
3 seems to be the best option for me as it requires no special support
from DMCs and DMRs. It will even work with DMCs and DMRs that do not
support playlist files, providing the DMC is prepared to manage the
playback of the playlist, by traversing the playlist container. The
third solution also works nicely with PlayContainer, should we or Rygel
DMR provide support for this feature in the future. However, it does
suffer from the continual problem that it will not work on most servers
as I imagine most DMSs do not support CreateReference.
So for this to work with Rygel, some modifications would be needed to
Rygel, and maybe its plugins. Perhaps we could start without support
for PlaySingle URI. This would restrict playlists to pointing only to
items on the same DMS on which the playlist is stored. We would also
need to change our implementation of CreatePlaylist in
media-service-upnp. Perhaps we could still support a way of creating
DIDL-S playlists files on servers, via a new method CreatePlaylistItem.
This method could accept URIs rather than object paths.
What do you think? Should we pursue option 3?
Regards,
Mark
2:54 a.m.
Hi Again,
Perhaps there is a 4th solution that would work with all DMS.
We could simply implement playlists in media-service-upnp itself. So
media-service-upnp would expose a new d-Bus PlayListManager object that
would allow playlists to be created, modified, deleted, etc.
Media-service-upnp would store the playlists locally in one or more
files. It could contain a method to generate DIDL-S or M3U versions of
a playlist object when required to do so by a client.
The beauty of this approach is that it doesn't require any changes to
Rygel and will allow us to create playlists containing items from all
DMSs, regardless of their levels of support. The downside is that the
playlists will only be accessible to DMCs and DMPs that are written
using dLeyna and will only be available on the device on which they are
created. They would be local playlists as such.
Regards,
Mark
On Wed, 2013-01-09 at 16:28 +0100, Mark D Ryan wrote:
Hi Ludo,
Thanks for investigating this. So to summarise, it seems to me that
there are 3 ways control points can create playlists on DMSs that
reference DMS content.
1. They can create playlist items on a DMS containing a M3U/DIDL-S file.
This is nice and simple but it suffers from the problems you mention in
your email, in that these files contain URLs and not ids of DMS objects.
Unless you have tight control over your DMS and your network
infrastructure, these URLs could become obsolete simply by restarting
your DMS or by losing your DHCP lease.
2. They can create playlist items on a DMS containing a DIDL-V file that
itself contains PlaySingle URIs rather than real URLs. This way the
items in the playlist can always be resolved to the correct URL,
providing of course the relevant server is still connected to the
network and the referenced files still exist. The problem here, and
this is a big problem, is that this will only work on DMRs that support
both DIDL-V and PlaySingle URI. Bear in mind that PlaySingle URI
requires the DMR itself to be a control point so that it can resolve
server and object IDs to URLs, i.e., it would need to use something like
media-service-upnp. I doubt there are many renderers that actually
support PlaySingle URI.
3. The control point creates a container in which it creates either
references to media items that exist elsewhere on the server or objects
with an existing res element that contain PlaySingle URIs. The DMS can
then automatically publish a res on the container that points to a
DIDL-S file containing URLs for all the items in the container. This
file can be generated on the fly by the DMS and so it will always
contain valid URLs. Note that the case where PlaySingle URIs are
allowed in the container would require the DMS to be able to resolve
PlaySingle URIs from other servers. The DMS would also need to support
CreateReference.
3 seems to be the best option for me as it requires no special support
from DMCs and DMRs. It will even work with DMCs and DMRs that do not
support playlist files, providing the DMC is prepared to manage the
playback of the playlist, by traversing the playlist container. The
third solution also works nicely with PlayContainer, should we or Rygel
DMR provide support for this feature in the future. However, it does
suffer from the continual problem that it will not work on most servers
as I imagine most DMSs do not support CreateReference.
So for this to work with Rygel, some modifications would be needed to
Rygel, and maybe its plugins. Perhaps we could start without support
for PlaySingle URI. This would restrict playlists to pointing only to
items on the same DMS on which the playlist is stored. We would also
need to change our implementation of CreatePlaylist in
media-service-upnp. Perhaps we could still support a way of creating
DIDL-S playlists files on servers, via a new method CreatePlaylistItem.
This method could accept URIs rather than object paths.
What do you think? Should we pursue option 3?
Regards,
Mark
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
2:56 a.m.
I think there will be issues also regarding the certifications
On Wed, Jan 9, 2013 at 4:54 PM, Mark D Ryan <mark.d.ryan(a)linux.intel.com>wrote:
Hi Again,
Perhaps there is a 4th solution that would work with all DMS.
We could simply implement playlists in media-service-upnp itself. So
media-service-upnp would expose a new d-Bus PlayListManager object that
would allow playlists to be created, modified, deleted, etc.
Media-service-upnp would store the playlists locally in one or more
files. It could contain a method to generate DIDL-S or M3U versions of
a playlist object when required to do so by a client.
The beauty of this approach is that it doesn't require any changes to
Rygel and will allow us to create playlists containing items from all
DMSs, regardless of their levels of support. The downside is that the
playlists will only be accessible to DMCs and DMPs that are written
using dLeyna and will only be available on the device on which they are
created. They would be local playlists as such.
Regards,
Mark
On Wed, 2013-01-09 at 16:28 +0100, Mark D Ryan wrote:
> Hi Ludo,
>
> Thanks for investigating this. So to summarise, it seems to me that
> there are 3 ways control points can create playlists on DMSs that
> reference DMS content.
>
> 1. They can create playlist items on a DMS containing a M3U/DIDL-S file.
> This is nice and simple but it suffers from the problems you mention in
> your email, in that these files contain URLs and not ids of DMS objects.
> Unless you have tight control over your DMS and your network
> infrastructure, these URLs could become obsolete simply by restarting
> your DMS or by losing your DHCP lease.
>
>
> 2. They can create playlist items on a DMS containing a DIDL-V file that
> itself contains PlaySingle URIs rather than real URLs. This way the
> items in the playlist can always be resolved to the correct URL,
> providing of course the relevant server is still connected to the
> network and the referenced files still exist. The problem here, and
> this is a big problem, is that this will only work on DMRs that support
> both DIDL-V and PlaySingle URI. Bear in mind that PlaySingle URI
> requires the DMR itself to be a control point so that it can resolve
> server and object IDs to URLs, i.e., it would need to use something like
> media-service-upnp. I doubt there are many renderers that actually
> support PlaySingle URI.
>
>
> 3. The control point creates a container in which it creates either
> references to media items that exist elsewhere on the server or objects
> with an existing res element that contain PlaySingle URIs. The DMS can
> then automatically publish a res on the container that points to a
> DIDL-S file containing URLs for all the items in the container. This
> file can be generated on the fly by the DMS and so it will always
> contain valid URLs. Note that the case where PlaySingle URIs are
> allowed in the container would require the DMS to be able to resolve
> PlaySingle URIs from other servers. The DMS would also need to support
> CreateReference.
>
> 3 seems to be the best option for me as it requires no special support
> from DMCs and DMRs. It will even work with DMCs and DMRs that do not
> support playlist files, providing the DMC is prepared to manage the
> playback of the playlist, by traversing the playlist container. The
> third solution also works nicely with PlayContainer, should we or Rygel
> DMR provide support for this feature in the future. However, it does
> suffer from the continual problem that it will not work on most servers
> as I imagine most DMSs do not support CreateReference.
>
> So for this to work with Rygel, some modifications would be needed to
> Rygel, and maybe its plugins. Perhaps we could start without support
> for PlaySingle URI. This would restrict playlists to pointing only to
> items on the same DMS on which the playlist is stored. We would also
> need to change our implementation of CreatePlaylist in
> media-service-upnp. Perhaps we could still support a way of creating
> DIDL-S playlists files on servers, via a new method CreatePlaylistItem.
> This method could accept URIs rather than object paths.
>
> What do you think? Should we pursue option 3?
>
> Regards,
>
> Mark
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dLeyna mailing list
> dLeyna(a)lists.01.org
> https://lists.01.org/mailman/listinfo/dleyna
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
--
Ludovic Ferrandis
Open Source Technology Center
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
3:06 a.m.
Hi Ludo,
On Wed, 2013-01-09 at 16:56 +0100, Ferrandis, Ludovic wrote:
I think there will be issues also regarding the certifications
Do you mean that implementing local playlists only would prevent us from
getting UPnP or DLNA certification for applications built on top of
dLeyna? Is it not possible to certify DMPs and DMCs that cannot create
server side playlists?
Regards,
Mark
3:36 a.m.
We need to check if Playlist feature could be certified or not.
Otherwise, I don't know. As you mention, the big issue is that playlist
will be only available for DMP builded on top of MSU.
I can see several issues:
- DMP/DMC: When playing a Playlist, the various items should be chained. I
mean, when the first item has finished to play, we then start the next one,
until the end of the playlist.
it's easy for a renderer, but for a DMC, that would implies to make
specific code that have nothing to do with DMC only to manage items.
- MSU will need to manage files. This implies to have a Read/Write storage
and to manage data directory, configuration... It's add complexity to the
component.
- The feature won't be implemented in Rygel (mainly the component
interested by the feature)
I think we should find servers (open source, like serviio or commercial
one) that implement this feature to test it.
On Wed, Jan 9, 2013 at 5:06 PM, Mark D Ryan <mark.d.ryan(a)linux.intel.com>wrote:
Do you mean that implementing local playlists only would prevent us
from
getting UPnP or DLNA certification for applications built on top of
dLeyna? Is it not possible to certify DMPs and DMCs that cannot create
server side playlists?
--
Ludovic Ferrandis
Open Source Technology Center
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
3:57 a.m.
Hi Ludo,
- DMP/DMC: When playing a Playlist, the various items should be
chained. I mean, when the first item has finished to play, we then
start the next one, until the end of the playlist.
it's easy for a renderer, but for a DMC, that would implies to make
specific code that have nothing to do with DMC only to manage items.
Option 4 is no different to our current implementation in this respect.
In both cases the DMP/DMC can retrieve a URL to a DIDL-S playlist file
which they can pass to a DMR to play. The only difference between the
two solutions here is that in our current solution the DIDL-S file is
served up by the DMS and in option 4 it would be served up by MSU (MSU
would need to run a small HTTP server)
- MSU will need to manage files. This implies to have a Read/Write
storage and to manage data directory, configuration... It's add
complexity to the component.
This is true but we could remove some complexity in MSU by removing the
current playlist implementation, which is in itself quite complex.
- The feature won't be implemented in Rygel (mainly the component
interested by the feature)
Yes, but it will work with all DMSs. Surely, this is the best option
from the users perspective. BTW, options 3 and 4 are not mutually
exclusive. In the long run we could implement both. There would be no
problems support local and server side playlists.
I think we should find servers (open source, like serviio or
commercial one) that implement this feature to test it.
Yes, I'd be interested to see how other servers support the user
creation of playlists. However, from reading the standards I can't see
any options other than those outlined in my previous two emails, except
of course for proprietary APIs or a UI for creating server side
playlists. Am I missing something here? Can you see a 5th option.
Regards,
Mark
3539
days inactive
3545
days old
6 comments
2 participants
participants (2)
-
Ferrandis, Ludovic -
Mark D Ryan