RE: [HOME_NETWORK_TF] Home Network Technologies

Hi Matt,

See inline below.

Regards,
Bob

> -----Original Message-----
> From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk]
> Sent: Monday, April 11, 2011 9:49 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,
>
> Yes that is exactly what I had in mind - the ability query and control
> those aspects of the TV experience - not just those involving streaming
> of media from other devices in the home. For the BBC it would be
> important to support the use cases I outlined for broadcast content that
> potentially never leaves the receiver device.
>
> Did anything come of Doug's suggestions? What kind of model did he have
> in mind? The concept of "remote control" could have several meanings:
>
> * the simulation of button pushes or other means of driving the existing
>    UI presented on the screen by the TV itself
>

It is this model - how a remote control device interacts in a generic manner with a device presenting HTML based UI. How the remote and UI device "discover" each other is out-of-scope. A common "discovery" scenario is I point my remote at the UI device I want to control.

> * a content centric model for querying and control in the style of UPnP
>    services, Universal Control API, or others
>
> The latter better lends itself to supporting dual-screen scenarios.
>

Forgive me if I'm restating what is already obvious but the UPnP services allow a UI device to discover media players and servers, each of which are separate devices. A single UI device can control a multiplicity of servers connected to players. Thus, the UI device is in many senses a remote control. This UI device can send user input to a server or player that itself is presenting UI.

So there is support for two paradigms: a remote controlling a UI device that is probably right in front of you and a UI device controlling multiple servers and renders anywhere on the home network.



>
> regards
>
>
>
> Matt
>
> On Fri, 08 Apr 2011 20:25:46 +0100, Bob Lund <B.Lund@cablelabs.com>
> wrote:
>
> > 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=e2c163bfab8076edc2b33

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

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

Received on Monday, 11 April 2011 20:26:15 UTC