RE: [HOME_NETWORK_TF] Home Network Technologies



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

The Content Directory Service can expose broadcast, IP delivered TV or radio so UPnP players can access this content. Whether it does so is a function of the device implementing the CDS.

Bob Lund

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

Received on Thursday, 7 April 2011 15:01:42 UTC