[RTW] Fwd: Second screen, low-delay control channels (Re: BOF agenda uploaded to IETF servers)

Matt Hammond matt.hammond at bbc.co.uk
Thu Feb 17 18:40:10 CET 2011


Hi,

Dan mentioned that he had posted here regarding second screen and remote  
controls, so I thought I should chip in. As he mentioned, I was also at  
the W3C Web and TV workshop and presented some work we have been doing at  
the BBC in this area.

>> On 15 February 2011 15:10, Harald Alvestrand<harald at alvestrand.no>  
>>  wrote:
>
> I'm not sure - to me it seems like second-screen applications need 2
> types of data:
> - Media data from a server, which are pretty well served by current
> streaming-over-HTTP efforts
> - Control data that go between the devices, which frequently could
> benefit from a direct link to keep latency down.
>
> In this use case, we could easily imagine using the RTC-web channel
> establishment functionality, but not pass media over them. This could
> be appropriate/important for some home situations, such as "TV on
> fixed network, remote on WLAN network, phone on 3G".

I am thinking of control, not streaming of media. The approach we've  
worked on is to enable high level control of a TV's functions from a  
"second screen"/"remote control" client device. The kinds of functions to  
be controlled would include: changing volume, querying what  
programme/channel is currently playing, changing channel, booking  
recordings, playing recordings, etc. Clients could be browser based, or  
phone/tablet/PC applications or dedicated single purpose/embedded devices.  
An interesting example might be an 'accessible' remote control for a user  
with motor impairments.

The first interest for me is in establishing a direct channel between  
devices in the home LAN - hence in our experiments we put an HTTP server  
on the TV. However, I agree with Dan that there are many very interesting  
possibilities that present themselves if that channel can bridge outside  
of that domain.

If you think this could fit into the group's remit, then we would try to  
bring some less hazy use cases to the table to help with the scoping.

regards


Matt

> What do others think? Should we add such a scenario to our (so far
> virtual) list of scenarios?
>>
>> Last week I attended W3C's "TV and Web" Workshop in Berlin.
>> http://www.w3.org/2010/11/web-and-tv/
>> There's a workshop report in preparation but the raw materials are
>> linked from  
>> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Feb/0007.html
>>
>> There were a number of presentations (including mine) on theme of
>> using devices (smart phones, tablets) as "second screens", for remote
>> control functionality, but also to provide additional information,
>> interactivity, social functionality etc to accompany TVs and related
>> media centre devices. I showed some work that used XMPP to provide
>> such a communications channel, and Matt Hammond from the BBC showed
>> their HTTP/REST-based efforts. In both cases, "second screen"
>> scenarios have some familiar difficulties, and the RTC work was
>> discussed as a potential effort that could address these problems.
>>
>> When using classic server-mediated XMPP, remote control apps suffer
>> from latency. XMPP allows us to address devices logically, but its
>> point-to-point use in LAN-local scenarios, or when the devices are on
>> different networks, is relatively immature (although JINGLE and
>> XEP-0174 show it growing in that direction).
>>
>> When devices expose TV services over HTTP (as in the BBC work) things
>> are relatively simple so long as both devices are on the same LAN, but
>> otherwise there are difficulties.
>>
>> There is interest in the W3C TV Interest Group community towards
>> standardising something in support of "second screen" remote control
>> TV / media centre scenarios. But also a healthy concern to avoid
>> re-inventing wheels - hence this message.
>>
>> My small understanding of RTC is that you will be addressing nat
>> traversal issues, and will likely have some kind of control channel
>> for direct (non-server mediated) signalling between endpoints. I would
>> be grateful for any help in understanding whether these pieces
>> could/should/might be relevant to any hypothetical new "TV-style
>> remotes" W3C work as sketched above.
>>
>> Thanks for any advice, and sorry that the requirement/scenario is
>> sketchy, some of us are working to come up with a more detailed
>> picture asap,
>>
>> cheers,
>>
>> Dan
>>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web


-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/


More information about the RTC-Web mailing list