Comments (7)
The TAG review request is w3ctag/design-reviews#145 (which I'm saying so there's a link both ways).
from remote-playback.
Thanks for the feedback @cynthia. The open screen protocol that @mfoltzgoogle is working on is indeed one of the solution we are considering for this interoperability issue.
This said, the Remote Playback API completely abstracts the protocol to the web developer contrary to the Presentation API. That means that websites will not have to do sniffing and will only be told that there is or is not available devices depending on the user's setup. Because of this, we believe that the Remote Playback API will offer a good interoperability story for the platform. In other words, if the browser supports Chrome Cast, and the user has a one in its network, the API will reflect that the device is available but the page doesn't need to know the Cast protocol. If the user switches to a browser that only handles AirPlay, the API on this browser will report no available device. The interop issue will mostly be for the user as changing browser might provide a different experience depending on their hardware setup.
from remote-playback.
@cynthia based on the dicsussion at the last spec review meting it doesn't appear you've see @mounirlamouri's response above.
Does it address your concerns about the protocol?
Also, w.r.t the failure to play remotely, the spec defines throwing DOMException
of different types in different situations (like NotSupportedError
, NotFoundError
, NotAllowedError
and so on).
from remote-playback.
@avayvod Yes, you are correct - for some reason that reply slipped through my attention. (I blame a large backlog of mails, but that's mostly an excuse. Apologies to @mounirlamouri .)
First of all, I understand the rationale for the abstraction - I had a quick chat with @anssiko about the background when I was first tasked to look into this. Unfortunately, it doesn't address the concerns - but more on that below.
If the user switches to a browser that only handles AirPlay, the API on this browser will report no available device.
This is the part that I'm worried about. While the Safari-Apple TV and Chrome-Android pairing would be relatively obvious to the user after a bit of trial and error (and the tradeoff of not having to yak shave a transport protocol into the specification for this quirk makes sense) - this requires users to switch browsers for remote playback compatibility, which doesn't quite feel like something an open web standard should be doing.
e.g. For a user with a Apple TV that uses Chrome as their main browser, it would not show up as a playback device. The application running in Chrome wouldn't have any way of knowing that the user has an Apple TV which is incompatible with Chrome, so it wouldn't even have the contextual information needed to notify the user to switch to say, Safari. Users would intuitively need to know when to switch to what browser, based on experience. For a tech-savvy user, this wouldn't be a problem - I'm not sure how well this would work for the average user though. And as noted above, there are obvious pairings - but it's also not entirely obvious what browsers from vendors with no companion device offerings (e.g. Mozilla) would support, even to a tech-savvy user.
My understanding is that websites which plan to use this will need to explicitly make the users aware of the browser-playback device pairing in some form of documentation as their best bet, possibly with a list of working pairs of browsers and devices. This isn't great, both from the content developer or user's perspective.
It is understandable that utilizing existing transport mechanisms were the most logical way forward, and the TAG can't really stop implementations from shipping. The ideal way to deal with this is to implement a cross-implementation compatible transport, but I understand that is a long term goal.
This issue was raised in hope to find a better way to deal with the problem at hand and deliver a better experience to the users. I'd be happy to sit down and throw around ideas to at least make the user experience aspect better if that is the most pragmatic way forward.
(I'm pretty sure this comment could have been made a bit more concise.)
from remote-playback.
@cynthia you are right that this is not ideal but one goal of this API was to offer a way for the web page to trigger the current "fling" feature that browsers have implemented by default (Chrome and Firefox offer Cast on Android, Safari offers Air Play). A user trying to "fling" a video shouldn't have to care whether it is using the API or the built-in feature. The concerns of not being able to use an AirPlay device from Android is larger than this API and anyone with such a configuration will be aware of the issue. Therefore, in our opinion, it is very unlikely that a user will have an unexpected/bad experience with this API.
from remote-playback.
I don't think the issue can be realistically acted upon apart from getting the Open Screen Protocol supported widely and have device makers and user agent use it. This way, if UA_1 supports OSP, it will be able to connect to all devices implementing the spec and if UA_2 also supports OSP, switching from an UA to another would not affect the user's ability to connect to their devices.
Given that OSP is a new Working Group item, I believe we are on track to get there, or at least, we putting the pieces together. I am going to close this issue but please feel free to re-open if that doesn't sound reasonable.
from remote-playback.
We believe the OSP spec has added the features necessary to support interoperable Remote Playback. See https://w3c.github.io/openscreenprotocol/#remote-playback-protocol for the details.
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.