Re: [HOME_NETWORK_TF] Home Network Technologies

Here is a more expanded list of UPnP services relevant to the topic being
discussed:

   - ContentDirectory<http://upnp.org/specs/av/UPnP-av-ContentDirectory-v3-Service.pdf>
   - ConnectionManager<http://upnp.org/specs/av/UPnP-av-ConnectionManager-v2-Service.pdf>
   - AVTransport<http://upnp.org/specs/av/UPnP-av-AVTransport-v2-Service.pdf>
   - ScheduledRecording<http://upnp.org/specs/av/UPnP-av-ScheduledRecording-v2-Service.pdf>
   - RenderingControl<http://upnp.org/specs/av/UPnP-av-RenderingControl-v2-Service.pdf>
   - RemoteUIServer<http://upnp.org/specs/rui/UPnP-rui-RemoteUIServer-v1-Service.pdf>
   - RemoteUIClient<http://upnp.org/specs/rui/UPnP-rui-RemoteUIClient-v1-Service.pdf>

See the PrepareForConnection() and ConnectionComplete() actions for
information on how to initiate a media push to a MediaRenderer device (which
implements the ConnectionManager service).

Glenn

On Fri, Apr 8, 2011 at 4:39 PM, Jan Lindquist <jan.lindquist@ericsson.com>wrote:

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