- From: Clarke Stevens <C.Stevens@CableLabs.com>
- Date: Mon, 11 Apr 2011 10:53:00 -0600
- To: Matt Hammond <matt.hammond@rd.bbc.co.uk>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>, Olivier Carmona <ocarmona@awox.com>, Russell Berkoff <r.berkoff@sisa.samsung.com>, Bob Lund <B.Lund@CableLabs.com>
- CC: Giuseppe Pascale <giuseppep@opera.com>
- Message-ID: <3C0068AB22D70B4DA32B9A2A965968C76FBA106A8B@srvxchg>
While the whole purpose of UPnP Control Points is to provide control, the control is defined in terms of services that can be controlled. There is no "TV Service" defined in UPnP, so there's no real TV remote capability. As was discussed previously, many TVs implement the UPnP rendering control service which has a number of typical TV controls. I've included the list below for convenience: · LastChange · PresetNameList · Brightness · Contrast · Sharpness · RedVideoGain · GreenVideoGain · BlueVideoGain · RedVideoBlackLevel · GreenVideoBlackLevel · BlueVideoBlackLevel · ColorTemperature · HorizontalKeystone · VerticalKeystone · Mute · Volume · VolumeDB · Loudness If this group decides that expanded TV remote control commands are a requirement, there are a couple of sources that we may want to consult for "canonical" lists of commands: · HDMI-CEC (must be a member to download the spec): http://www.hdmi.org/manufacturer/specification.aspx · CableLabs host specification (i.e. set-top box) remote control: http://www.cablelabs.com/specifications/OC-SP-HOST2.1-CFR-I13-110204.pdf (Section 16 discusses cable remote control commands as well as HDMI-CEC commands for cable remotes. Table 16.2-1 shows a handy list of remote control buttons.) Thanks, -Clarke -----Original Message----- From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk] Sent: Monday, April 11, 2011 9:49 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 Hi Bob, Yes that is exactly what I had in mind - the ability query and control those aspects of the TV experience - not just those involving streaming of media from other devices in the home. For the BBC it would be important to support the use cases I outlined for broadcast content that potentially never leaves the receiver device. Did anything come of Doug's suggestions? What kind of model did he have in mind? The concept of "remote control" could have several meanings: * the simulation of button pushes or other means of driving the existing UI presented on the screen by the TV itself * a content centric model for querying and control in the style of UPnP services, Universal Control API, or others The latter better lends itself to supporting dual-screen scenarios. regards Matt On Fri, 08 Apr 2011 20:25:46 +0100, Bob Lund <B.Lund@cablelabs.com<mailto:B.Lund@cablelabs.com>> wrote: > Hi Matt, > > So if I understand correctly, you're thinking about a service to > control the TV - content never leaves it. This UPnP service > http://upnp.org/specs/av/UPnP-av-RenderingControl-v2-Service.pdf > provides a remote interface to some controls of a rendering device but > probably not all of the controls a TV with a tuner would have. > > Sometime ago when Web and TV had its first workshop, Doug Schepers > solicited input for remote control events related to TV with the > intent, I believe, of defining DOM3 events for these. This would > enable remotes to work across UI implementations running on compliant user agents. > > Bob > >> -----Original Message----- >> From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk] >> Sent: Friday, April 08, 2011 9:59 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 >> >> 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<mailto: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<mailto: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=e2c163bfab8076edc2b33 >> >> >> eba >> >> >> 829 >> >> >> 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<mailto: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<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] >> >> >> >> 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<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/ >> >> >> >> >> >> -- >> >> | 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 Monday, 11 April 2011 16:53:58 UTC