Re: [HOME_NETWORK_TF] Home Network Technologies

As amended. ConnectionManager for connection setup/teardown and AVTransport
for playback control. The two services are typically implemented together in
the same device.

G.

On Fri, Apr 8, 2011 at 8:06 PM, Clarke Stevens <C.Stevens@cablelabs.com>wrote:

> That would be AVTranport service.
>
>
>
> -Clarke
>
>
>
> *From:* Jan Lindquist [mailto:jan.lindquist@ericsson.com]
> *Sent:* Friday, April 08, 2011 2:39 AM
> *To:* Glenn Adams; Clarke Stevens
> *Cc:* Matt Hammond; public-web-and-tv@w3.org; Olivier Carmona; Russell
> Berkoff; Giuseppe Pascale
>
> *Subject:* 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
>
>
>
> G.
>
> On Fri, Apr 8, 2011 at 12:08 AM, Clarke Stevens <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]
> Sent: Thursday, April 07, 2011 8:01 AM
> To: Clarke Stevens; Matt Hammond; 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] On Behalf Of Clarke Stevens
> Sent: den 7 april 2011 14:40
> 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,
>
> 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/
>
>
>
>