Presentation display capability detection

[markafoltz]

This is a placeholder for discussion of capability detection for presentation displays. Basically, the controller may want to provide more detailed constraints on the display through the API to further filter the list of screens shown to the user.

For example:

• It makes little sense for a photo or video site to be able to present to wireless speakers, but it makes perfect sense for a music or podcasting site.
• Media sites may require specific APIs (EME, MSE) or codecs to be present on the receiving UA for video playback to succeed.

This discussion is to brainstorm ways to improve this experience, while addressing privacy and implementation concerns.

Related: https://github.com/WICG/media-capabilities (not yet drafted)

[markafoltz]

CC @mounirlamouri

[mounirlamouri]

Would it make sense to have an extended constructor for PresentationRequest that takes a list of constraints that could include these information?

[tidoust]

For reference, see related discussion at TPAC

[markafoltz]

Would be good to analyze this again with respect to MediaCapabilities.

[markafoltz]

The feedback from #444 suggests that there could be a use case for "presenting" the same page onto a VR headset, which would require knowing if there is a VR headset available for presentation. We should pick this up based on the outcome of that discussion.

[anssiko]

Closing this per F2F decision, if concerns or new information emerges we can reopen.

[markafoltz]

Had a recent conversation with a user who was surprised they could present a visual document to an audio-only networked speaker, which is possible with the current API.

Meanwhile, presenting audio-only pages to these devices makes perfect sense.

With URL-based filtering, we would need the receiver to know in advance which documents required video output and which do not. I would consider a change allow the PresentationRequest to note whether video or audio were required to be a good usability improvement.

[louaybassbouss]

+1 but I am wondering how it works for 2-UA mode. Do you expect that the receiver URL points to an HTML page that plays an audio (in this case the audio receiver device needs to parse the receiver page/run Javascript ??) or directly to the audio itself?

[markafoltz]

Yes 😄 Cast applications that run on Cast for Audio/Assistant speakers work exactly this way.