RE: [HOME_NETWORK_TF] Home Network Technologies

Hi Matt,

So if I understand correctly, you're thinking about a service to control the TV - content never leaves it. This UPnP service http://upnp.org/specs/av/UPnP-av-RenderingControl-v2-Service.pdf provides a remote interface to some controls of a rendering device but probably not all of the controls a TV with a tuner would have.

Sometime ago when Web and TV had its first workshop, Doug Schepers solicited input for remote control events related to TV with the intent, I believe, of defining DOM3 events for these. This would enable remotes to work across UI implementations running on compliant user agents.

Bob

> -----Original Message-----
> From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk]
> Sent: Friday, April 08, 2011 9:59 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
>
> Hi Bob,
>
> Your latter example is what I had in mind: a device that is connected to
> the home network and receives off-air broadcasts, but does not serve or
> stream that content around the home network. Instead the device itself
> includes a display, or is connected directly to one using HDMI or
> similar.
>
> It is not clear to me if the A/V transport service (or whichever service
> is appropriate) facilitates remote control type functions such as
> changing channel or playing back a recording, as distinct from choosing
> content to stream to another device.
>
> regards
>
>
>
> Matt
>
> On Fri, 08 Apr 2011 15:30:58 +0100, Bob Lund <B.Lund@cablelabs.com>
> wrote:
>
> > 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=e2c163bfab8076edc2b33eba

> >> >> 829
> >> >> 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/

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

Received on Friday, 8 April 2011 19:26:52 UTC