Re: [HOME_NETWORK_TF] Home Network Technologies

We also see facilitating discovery of content on the home network from the  
browser to be important. There is also the issue of security and privacy -  
a user should be able to determine what devices, applications and web  
pages have permission to control another device and discover content.

As a broadcaster we deliver to multiple platforms over which we have no  
direct control (terrestrial, cable and satellite transmission all operated  
by different companies/consortia). Our interest is closer to the scenario  
2(b) that you outline.

What is not clear to me is whether the DLNA/UPnP capabilities for  
discovering and playing content also work for a box that does not have the  
capability to serve or stream off-air broadcast content on the home  
network (for example, a TV with integrated tuner). This is one of the  
reasons why we have an interest in a simplified abstraction that negates  
the need for a controlling device to concern itself with the source and  
delivery method of a piece of content (as well as its format, codecs,  
device profiles etc)

There is also potential to enable a substantial accessibility win here too  
if UI can be independent of the device(s) it is controlling.

When considering the Remote UI as mentioned here, perhaps there are at  
least 3 related strands to this? Discovery/security; remote control;  
device-served remote UI.

regards



Matt

On Thu, 07 Apr 2011 20:14:19 +0100, Bob Lund <B.Lund@cablelabs.com> wrote:

> To amplify on Clarke's point a bit, it's useful to break down the  
> broadcast/cloud UI into more specific scenarios:
> 1) Broadcast content directly from the cloud, UI from the cloud
> 2) Broadcast to a UPnP media server that proxies the content on the home  
> network via content directory service, remote UI from the cloud
>
> Scenario 1 is the web, nothing special needs to be introduced.
> Scenario 2 is more of a DLNA/UPnP model. There are two ways the UI  
> served from the cloud can gain the links to refer to the media server  
> content:
> a) A back channel from the media server hosting the CDS to the cloud  
> server constructing the UI page. If the service provider controls both  
> the media server software implementation and the cloud UI server this  
> back channel can be service provider specific. The cloud UI server  
> constructs UI that references the home network content. There are some  
> subtleties around how the media LAN side IP address is referenced in the  
> UI page but it's doable.
> b) The UI page served by the cloud server to the home network device  
> contains JavaScript that uses the discovery API that is being proposed  
> to discover the CDS and the content therein. The UI page JavaScript can  
> provide whatever degree of integration is desired between the local  
> content discovered and the cloud content referenced on the UI page.
>
> Bob Lund
>
>> -----Original Message-----
>> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-
>> request@w3.org] On Behalf Of Clarke Stevens
>> Sent: Thursday, April 07, 2011 11:05 AM
>> To: Matt Hammond; public-web-and-tv@w3.org; Olivier Carmona; Russell
>> Berkoff
>> Cc: Giuseppe Pascale
>> Subject: 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=e2c163bfab8076edc2b33eba8293e8
>> 2cd2f11e3e
>>
>> 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/


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

Received on Friday, 8 April 2011 09:09:47 UTC