Repository navigation
Presentation display capability detection #348
Description
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)
Activity
markafoltz commentedon Sep 16, 2016
CC @mounirlamouri
mounirlamouri commentedon Sep 22, 2016
Would it make sense to have an extended constructor for
PresentationRequestthat takes a list ofconstraintsthat could include these information?tidoust commentedon Sep 26, 2016
For reference, see related discussion at TPAC
markafoltz commentedon Sep 21, 2017
Would be good to analyze this again with respect to MediaCapabilities.
markafoltz commentedon Nov 1, 2017
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 commentedon Nov 7, 2017
Closing this per F2F decision, if concerns or new information emerges we can reopen.
markafoltz commentedon May 7, 2018
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 commentedon May 8, 2018
+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 commentedon May 9, 2018
Yes 😄 Cast applications that run on Cast for Audio/Assistant speakers work exactly this way.
Marvin-Brouwer commentedon Dec 28, 2024
I'd like to add that the
navigator.mediaDevices.getUserMediaalso allows for media constraints.So to me it makes sense to allow this for the
Presentation APItoo.