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

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@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@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/
participants (1)
-
Matt Hammond