RE: [HOME_NETWORK_TF] Home Network Technologies

Hi Glen,

Which UPnP service helps push content to the TV. The Rendering Contorl only covers the "remote control" like functions but to push the content on the TV requires another service.

Regards,
JanL

________________________________
From: Glenn Adams [mailto:glenn@skynav.com]
Sent: den 8 april 2011 02:32
To: Clarke Stevens
Cc: Jan Lindquist; Matt Hammond; public-web-and-tv@w3.org; Olivier Carmona; Russell Berkoff; Giuseppe Pascale
Subject: Re: [HOME_NETWORK_TF] Home Network Technologies

FYI there is a specific UPnP service defined for this purpose called "RenderingControl". See the following for details:

http://www.upnp.org/specs/av/UPnP-av-RenderingControl-v2-Service.pdf

<http://www.upnp.org/specs/av/UPnP-av-RenderingControl-v2-Service.pdf>G.

On Fri, Apr 8, 2011 at 12:08 AM, Clarke Stevens <C.Stevens@cablelabs.com<mailto:C.Stevens@cablelabs.com>> wrote:
A rendering device (e.g. a TV) may implement volume control. If it does, a control point (e.g. a tablet acting as a remote control) could adjust the volume on the TV.

-Clarke

-----Original Message-----
From: Jan Lindquist [mailto:jan.lindquist@ericsson.com<mailto:jan.lindquist@ericsson.com>]
Sent: Thursday, April 07, 2011 8:01 AM
To: Clarke Stevens; Matt Hammond; public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>; Olivier Carmona; Russell Berkoff
Cc: Giuseppe Pascale
Subject: RE: [HOME_NETWORK_TF] Home Network Technologies

Hello Clarke,

Just a clarification when you state that the volume change and mute are already provided. The presentation of the content I am clear and can be done using RUI but I am not clear on how the control like volume change and mute is performed. Is the controlled provided locally or did you mean that the service provided can provide the control through RUI back to the first screen in a second screen example.

Regards,
JanL

-----Original Message-----
From: public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org> [mailto:public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org>] On Behalf Of Clarke Stevens
Sent: den 7 april 2011 14:40
To: Matt Hammond; public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>; Olivier Carmona; Russell Berkoff
Cc: Giuseppe Pascale
Subject: RE: [HOME_NETWORK_TF] Home Network Technologies

Matt,

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> [mailto: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<mailto: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<mailto: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<mailto:matt.hammond@rd.bbc.co.uk>]
> Sent: Wednesday, April 06, 2011 5:03 AM
> To: public-web-and-tv@w3.org<mailto: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<mailto: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/