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


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

Received on Friday, 8 April 2011 15:59:24 UTC