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 14:12:09 UTC