RE: [HOME_NETWORK_TF] Home Network Technologies

Matt,

UPnP currently defines a way to discover remote user interfaces, but it is pretty generic.  Here are the specs:

http://upnp.org/specs/rui/remoteui/


In this group, we're hoping to make this a bit more concrete by using HTML browsers, CSS, JavaScript, and providing some APIs for discovering and using devices and services on the home network. The back channel to the cloud service would just be a URL. That's maybe a bit oversimplified as there are other issued related to a commercial service offering, but that's the basic idea.

As for more information on DLNA CVP, here's an announcement:

http://www.dlna.org/news/pr/view?item_key=e2c163bfab8076edc2b33eba8293e82cd2f11e3e


It looks like DLNA doesn't yet have CVP for sale from its web site but W3C could encourage them to provide some more information, timelines, etc.

Hope this helps.

Thanks,
-Clarke

-----Original Message-----
From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk] 
Sent: Thursday, April 07, 2011 8:11 AM
To: public-web-and-tv@w3.org; Olivier Carmona; Russell Berkoff; Clarke Stevens
Cc: Giuseppe Pascale
Subject: Re: [HOME_NETWORK_TF] Home Network Technologies

Hi Clarke,


Could you explain how this model where a remote user interface is served  from the cloud would work for broadcast services? Does it require some kind of back channel between the rendering device and the cloud service?

I would also like to understand what services CVP enables. Are the guidelines publicly available anywhere?

regards



Matt


On Thu, 07 Apr 2011 13:40:12 +0100, Clarke Stevens <C.Stevens@cablelabs.com> wrote:

> 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 17:06:09 UTC