RE: [HOME_NETWORK_TF] Home Network Technologies

Matt,

See inline below.

Bob

> -----Original Message-----
> From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk]
> Sent: Friday, April 08, 2011 3:03 AM
> To: Clarke Stevens; public-web-and-tv@w3.org; Olivier Carmona; Russell
> Berkoff; Bob Lund
> Cc: Giuseppe Pascale
> Subject: 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).

I am not clear on the question. If you mean a device that is not connected to the home network then UPnP does not address that. But, such a device would seem to be out of scope of all home network APIs. If you mean a device that is connected to the home network but does not have the capability to serve or stream off-air broadcast content, then yes, the device can host the content discovery, connection manager and A/V transport services. A TV with an integrated tuner could serve off-air broadcast content if it was also connected to the home network and had the appropriate UPnP services.


> 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=e2c163bfab8076edc2b33eba829

> >> 3e8
> >> 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 14:32:09 UTC