RE: [HOME_NETWORK_TF] Home Network Technologies

Matt,

I think some of the functionality you want is already defined in DLNA/UPnP and the rest will be very soon. As I mentioned earlier, the URL that points to the content does not need to be on the home network. This allows for content that can be offered from service providers. Similarly, a service provider could serve a remote user interface from the cloud. Features such as volume change and mute are already provided, so a "second screen" could get a user interface from a service provider and point to content remotely served by that service provider.

There is also a DLNA guideline called CVP specifically designed for content service providers. The first version is available now but is somewhat limited. The second version is in development and I believe it provides the remainder of the services you are looking for.

Thanks,
-Clarke

-----Original Message-----
From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-request@w3.org] On Behalf Of Matt Hammond
Sent: Thursday, April 07, 2011 2:52 AM
To: public-web-and-tv@w3.org; Olivier Carmona; Russell Berkoff
Cc: Giuseppe Pascale
Subject: Re: [HOME_NETWORK_TF] Home Network Technologies

Hi Russell,

Your description matches my understanding of DLNA/UPnP - which is useful confirmation for me - many thanks!

I agree that this model works well for streaming between home devices. But it makes the assumption that all content is streamable between home devices. A TV or set-top-box that can receive broadcast or IP delivered TV or radio does not necessarily match this. In order to be able to implement some of the second-screen scenarios presented at the last workshop, I would hope that APIs for home networking are also able to query and control TV functions such as changing channel or retrieving broadcast programme metadata.

This is why I am interested in APIs that can support both in (if possible) a single simple unified way. The approach we took at the BBC with our Universal Control (UC) API is one possible way to achieve this.

If a TV implementing UC API needed to be able to discover and stream content on other devices in the home then it would almost certainly use DLNA/UPnP or other similar technologies to do this, but the client/controller device does not need to know the difference. From the perspective of a client of the UC API implementing TV, streamed content is discoverable and selectable for playback in the same way as a television channel or programme would be.

regards



Matt

On Thu, 07 Apr 2011 08:39:18 +0100, Russell Berkoff <r.berkoff@sisa.samsung.com> wrote:

> Hi Matt,
>
>
> Let me try to answer "frame" your question/observation and hopefully 
> provide some brief answers:
>
>
> Q1: Does DLNA/UPnP distinguish between the description of content, i.e.  
> metadata describing content (title, description, available media
> formats) and the device actually supplying the content?
>
>
> Q2: Does DLNA/UPnP allow metadata and content to reside on separate  
> devices on the home network?
>
>
> Q3: Does DLNA/UPnP allow the remote commanding of playback devices?
>
>
>
> A1: Yes...DLNA/UPnP has a distinct metadata service (ContentDirectory  
> Service). The metadata provided by this service can refer to content  
> elsewhere on the home network.
>
>
> A2: Yes
>
>
> A3: Yes...UPnP/DLNA allows remote commanding of playback devices. A  
> Digital Media Controller can obtain descriptive content metadata and  
> tell a playback device to "pull" a piece of content from a distinct  
> "content source" on the home network.
>
>
> The Digital Media Controller in this scenario would examine the metadata  
> from both the Playback Device (Digital Media Renderer) and from the  
> metadata service (Digital Media Server - ContentDirectory Service) and  
> insure a media format is chosen that both the Content Source can provide  
> and the Playback Device can render. Once a match is found the Digital  
> Media Controller, would command the Playback device to fetch the content  
> from the Content Source.
>
>
> Regards,
>
> Russell Berkoff
>
> Samsung Electronics
>
>
>
>
> -----Original Message-----
> From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk]
> Sent: Wednesday, April 06, 2011 5:03 AM
> To: public-web-and-tv@w3.org; Olivier Carmona
> Cc: Russell Berkoff; Giuseppe Pascale
> Subject: Re: [HOME_NETWORK_TF] Home Network Technologies
>
>
> Hi Olivier,
>
>
> On Wed, 06 Apr 2011 12:22:38 +0100, Olivier Carmona <ocarmona@awox.com>
>
> wrote:
>
>
>>
>
>> Hi Matt,
>
>>
>
>> DLNA 1.0 is about two-box pull model: on one side you have a Digital
>
>> Media Player (a client in your description) and on the other side you
>
>> have a Digital Media Server (a rendering device in your description).
>
>> DMP discovers and then browses DMS, and can request one of the browsed
>
>> items to be played. The only difference with your model is that this the
>
>> DMP that based on the information exposed by the DMS, decides wherever
>
>> it can play the content.
>
>
> My explanation was not as clear as it should have been - please accept my
>
> apologies for that. The client that I described does not display media  
> and
>
> does not send or receive media streams. It is the server that will
>
> render/display media, and it is up to the server to work out what media  
> is
>
> available to it and to arrange to stream (or otherwise obtain) it. This
>
> aspect would be completely opaque to this client. The server/renderer
>
> could well use DLNA to discover and stream that content from a 3rd  
> device,
>
> but the client would not be aware of this.
>
>
> For me, the attraction of this model is that it is more abstract that  
> just
>
> streaming and can easily subsume access to local storage but also access
>
> to services such as live television broadcast. A television programme is
>
> just another item of content that the server reports it has available to
>
> it, and which the client can ask it to display.
>
>
>
>
> regards
>
>
>
> Matt
>


-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/

Received on Thursday, 7 April 2011 13:29:03 UTC