- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 Jul 2015 21:26:24 +0000
- To: public-secondscreen@w3.org
The specific circumstance is when the only display available is incapable of rendering generic Web content (i.e. usable in 2-UA mode) or a generic video stream (i.e. usable in 1-UA mode). However, it can function as a proxy by mapping a URL resource to a fixed set of presentation modes. This is the case that mwatson2@ alluded to in https://github.com/w3c/presentation-api/issues/138#issuecomment-119219557 for Netflix. As it happens, this is a common case for users who have Internet-connected TVs, set top boxes, game consoles, etc. most of which use DIAL [1] to facilitate remote launch of these applications. Rather than offering the user these displays as generic presentation targets but having them fail to render in many circumstances, this allows the UA to offer presentation when it has some confidence that the request will succeed (by first querying the device for compatibility with the DIAL application). If you are curious about the specific mechanism see section 6.1 of the specification [1]. Over time I hope that this is the less common case. Cast devices will all support 1-UA mode initially and there is an active effort to add Presentation API support to HBB TV 2.0 in 2-UA mode https://github.com/w3c/presentation-api/issues/67#issuecomment-118061074. Down the road we've discussed expanding the Presentation API to allow the controlling page to require more specific capabilities from the display like specific codecs, audio/video outputs, or perhaps installed applications. But we don't have a specific proposal yet that encompasses all these cases. [1] http://www.dial-multiscreen.org/dial-protocol-specification -- GitHub Notif of comment by mfoltzgoogle See https://github.com/w3c/presentation-api/issues/138#issuecomment-119347167
Received on Tuesday, 7 July 2015 21:26:25 UTC