W3C home > Mailing lists > Public > public-web-and-tv@w3.org > April 2011

Re: [HOME_NETWORK_TF] Home Network Technologies

From: Matt Hammond <matt.hammond@rd.bbc.co.uk>
Date: Mon, 11 Apr 2011 16:49:03 +0100
To: "Clarke Stevens" <C.Stevens@cablelabs.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>, "Olivier Carmona" <ocarmona@awox.com>, "Russell Berkoff" <r.berkoff@sisa.samsung.com>, "Bob Lund" <B.Lund@cablelabs.com>
Cc: "Giuseppe Pascale" <giuseppep@opera.com>
Message-ID: <op.vtr571v7mko9fo@r44116>
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

* 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.


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


-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/
Received on Monday, 11 April 2011 15:49:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 11 April 2011 15:49:55 GMT