Motivation for BBC use cases (was Re: webtv-Issue-20: TV Querying and Control)


Jean-Claude - thanks for your question - I think its a pertinent one. I'll  
try to explain my perspective and motivations in more detail:

Our interest in the web and TV interest group is as a content and service  
creator wishing to be able to content and services that bring web and TV  
together. In particular, as we presented at the last IG workshop, from a  
starting point of dual-screen styles of application. Therefore we have  
submitted use cases (scenarios?) with the intent of suggesting what  
content and services should be enabled.

Yes - from that perspective, we would hope to be able to create content  
that can communicate with TVs and other devices across a range of  
platforms and manufacturers. This is extremely important to us. As a  
content creator, costs of production can quickly become prohibitive if we  
have to substantially repurpose content for every platform and device we  
wish to serve on.

When envisaging the creation this kind of content/services: access to UPnP  
services does not feel ideal (without substantial abstraction) since we  
perceive them to be lower level and more complex than, for example, a web  
api of the form that we experimented with, and which we have publicly  

However I acknowledge the substantial existing support for UPnP. I can  
also see that parts of UPnP do cover these scenarios in some cases. It has  
been helpful to find out from other TF participants precisely what can be  
done with UPnP - it has been not at all obvious to me whether some of our  
scenarios could be supported for the case of a single device receiving  
live broadcast content (eg. TV with integrated tuner) - especially as it  
seems that deployments of UPnP standards focus on the streaming of media  
between devices.

I have tried to recast our contributions in a relatively technology  
agnostic form, and am happy to continue to refine them when overlaps with  
suitable existing technologies are identified.



On Mon, 06 Jun 2011 18:47:25 +0100, Jean-Claude Dufourd  
<> wrote:

> I agree with Russell's points.
> The use case can be implemented today with UPnP, yes, I have done pieces
> of that, and I believe Matt's team did more.
> But I wonder about Matt's intent.
> Is the intent of the use case that the HNTF-chartered WG would define a
> standard interface to those TV services, so that any companion device
> can connect to it without knowing the make of the TV ? In other words,
> that WG would define an abstract service to change the volume, change
> the channel, etc... in a way that can be mapped onto UPnP services.
> If so, I do not know if I support it.
> Best regards
> JC
> On 6/6/11 10:17 , Russell Berkoff wrote:
>> Hello,
>> The submitter's test case appears redundant with long standing UPnP
>> function. We agreed to convey these requirements in a generic way as
>> part of  Issue-17 as well as in a UPnP specific way as discussed on
>> the previous call.
>> The Justification section appears to incorrectly characterize UPnP:
>> I've repeated the Justification  section since the W3 tools do not
>> allow comments to be attached to submitted document.
>> *Justification:*
>>     * Allows the creation of user interfaces utilizing companion
>>       device features, such as touch screens. Such interfaces may have
>>       greater usability than can be achieved with a traditional
>>       infra-red button based remote control and on-television interface.
>> UPnP allows any device to act as an external control point. This
>> device can determine the current state of the rendering device as well
>> as control the device.
>>     * Standardisation could facilitate a new ecosystem of interfaces.
>>     * Existing standards for home network communication are not
>>       available from the browser context
>> Actually CEA-2014-B has a web-binding for UPnP devices. PHP has a
>> binding for UPnP Devices (GUPnP). A desirable goal of this TF is to
>> have W3C also publish these (or similar bindings).
>>     * Existing standards (UPnP?) do not support query and control of
>>       content playback where the content is not being streamed between
>>       devices
>> UPnP embodies no such restriction. There is nothing in UPnP that
>> precludes a MediaRenderer from publishing locally based changes of
>> device state. If anything this would be encouraged to provide a
>> consistent user experience.
>> Regards,
>> Russell Berkoff
>> Samsung

| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London

Received on Tuesday, 7 June 2011 08:35:05 UTC