Comments (12)
@foolip @mounirlamouri do you think this is a good candidate for the F2F in May given Philip will be attending remotely in the best case and I doubt most group participants are closely familiar with Media Session API and user agent's default behaviors. Brainstorming use cases and requirements might still be useful though?
from remote-playback.
Let's discuss the behavior w/r/t other tabs making sound before and after remote playback of the current tab and also how multiple remotely played media elements interact. Also reuse of metadata.
We can define the behavior that makes sense and then express it via MediaSession API later.
from remote-playback.
Discussed at the F2F:
http://www.w3.org/2016/05/24-webscreens-minutes.html#item10
ACTION: Mounir to update issue with comments about remote and local don't fight over output, and suggestion that remote playback can access keys. No spec changes at this juncture.
from remote-playback.
François said it all, not much to add here. The conclusion from our discussion was that remote playback should not compete for audio focus with local playback. A remote playback should fight for audio focus on the device it is playing.
However, remote playback should compete for media keys on the local playback. That means that if there is a remote and local playback, one or the other might get media keys access. I don't think the Media Session spec is mature enough to allow us to hook into this so the conclusion was to do no mention of this in Remote Playback API at the moment. Later, we can either mention this in Media Session API or Remote Playback API.
from remote-playback.
This behavior makes sense, I agree. It will require changes to Media Session to decouple media key access from "active local session". If it's not a problem, I suggest leaving this and w3c/mediasession#123 until we figure that out, and implementation could inform the design.
from remote-playback.
See related discussion at TPAC
The group will wait until the Media Session spec matures before it revisits this issue.
from remote-playback.
Ok, revisiting the issue as both APIs are now shipping in Chrome.
I'd like the metadata at least to be applied to the remote playback if set on navigator
.
The actions and event handlers are harder to define though - it doesn't seem like a good experience to pause both local and remote playback, for instance. It would be okay if only remote playback is happening (e.g. on iOS as I remember, remote and local playback are mutually exclusive).
Otherwise we could add a separate, per-element MediaSession
object under remote
that would override the one set on navigator.mediaSession
if not null.
The corresponding issue on the MediaSession spec (closed as it was mostly about audio focus) is here.
from remote-playback.
One principle of the Media Session specification is that the instance on navigator.mediaSession
will hook itself to the default audio focus used by the user agent. With remote playback, the user agent uses a different audio focus than the one on the device which means that handling remote playback in the default media session would break this principle.
Adding a MediaSession
instance on the media.remote
instance can help but it sounds slightly limited as other things could benefit from a "remote" media session. I don't have any good idea though. The only thing I can think of is to allow a remote
audio focus (when the Audio Focus API happens) that could receive a media session. Though, I am not sure how useful the remote audio focus would be apart from linking to the media session.
from remote-playback.
I agree with keeping the global, user-agent media session distinct from a media session used to control remote playback.
One question is, do we expect at most one remote media session per user agent, or could there be multiple active sessions (one per remote device)?
from remote-playback.
@mounirlamouri Do you agree we can say that if the only media playing is playing remotely, the UA is only involved in one audio focus - the remote one? Using navigator.mediaSession.metadata
alone for remote playback sounds useful on its own to me agnostic to audio focus and controls.
it sounds slightly limited as other things could benefit from a "remote" media session.
What other things did you have in mind? Some things not attached to the specific media element?
from remote-playback.
One question is, do we expect at most one remote media session per user agent, or could there be multiple active sessions (one per remote device)?
I'd prefer a design that allows multiple active sessions.
from remote-playback.
@mfoltzgoogle In Chrome we only support one remote media session per system (limitation of the Cast SDK). However the Remote Playback API specification doesn't prevent remote playback of multiple elements on multiple remote playback devices in the same spirit as the Presentation API that IIRC allows multiple PresentationConnections to be established with different presentation screens.
from remote-playback.
Related Issues (20)
- Use [Exposed=Window]
- Add explicit text to define the disableRemotePlayback content attribute
- Restrict the API to Secure Contexts or discuss the decision in Security Considerations HOT 1
- Rephrase normative statement in security and privacy consideration section HOT 1
- Compatibility of Remote Playback API with AirPlay mirroring HOT 2
- [Chrome 64] The RemotePlayback API is disabled on this platform HOT 4
- Chromecast TV not detected HOT 5
- Define remote playback interaction with background playback policies HOT 3
- Explore polyfilling Remote Playback API on top of Presentation API HOT 1
- Support for TTML and IMSC captions HOT 1
- How does remote playback interact with EME? HOT 4
- RemotePlaybackState enum can become misleading when changing media.src HOT 17
- Specify the task source for each task to be enqueued HOT 1
- [meta] Publish Proposed Recommendation HOT 2
- Allow adapting the bitrate to network/receiver constraints when using MSE
- Export terms HOT 2
- A
- render a dummy video/progress bar HOT 1
- example HOT 2
- check on the flag to activate the Remote Playback API on desktop HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from remote-playback.