Comments (18)
@anssiko any particular label we should use? Would F2F suffice?
from remote-playback.
@avayvod F2F label works fine. When we work through the issues at F2F, I'd prefer to give priority to issues that would benefit from the F2F discussion & decision the most.
We have the Tuesday morning reserved for the Remove Playback API, so I'm positive that by the time we break for lunch on that day we have a spec that is FPWD-ready and we can start publication preparations soon after.
from remote-playback.
Discussed at the F2F:
http://www.w3.org/2016/05/24-webscreens-minutes.html#item11
Goal is to collect edits from the F2F before publication.
ACTION: Anssi to send a CFC once edits are done
ACTION: Anton to collect edits and coordinate timing with Anssi
from remote-playback.
As agreed at the F2F, we will publish the First Public Working Draft (FPWD) of the Remote Playback API when the edits documented as PROPOSED RESOLUTIONs (below) have landed to the Editor's Draft. Time-wise, we agreed to target the end of June FPWD publication. Factoring in a reasonable 10 working days Call for Consensus (CfC) and some wiggle room, I'd like us to have a publication ready spec by 13 June to be referenced in the FPWD CfC.
@avayvod @mounirlamouri Does this timeline sound reasonable to you?
All - please let me know if you have any questions or concerns with this plan.
PROPOSED RESOLUTIONs from the F2F (land before FPWD):
- onstatechange vs. onconnect, onconnecting, etc. (#36)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item04
- PROPOSED RESOLUTION: break up the statechange into 3 different events as described in: #36 (comment)
- Allow websites to stop the remote playback (#4)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item05
- PROPOSED RESOLUTION: For issue #4, no "stop" method, add guidance that UA should provide a way to disconnect, and rename "connect" method into something like "showDevicePicker"
- Define the UA behavior when the disableRemotePlayback attribute is added during the remote playback (#6)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item06
- PROPOSED RESOLUTION: Refine behavior of existing alg's for attribute, i.e. Promise rejections would reference it.
- Allow the user agent to choose which media element source to play remotely (#7)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item07
- PROPOSED RESOLUTION: @avayvod to update spec to be clear that entire source list is considered for availability (if possible) and remote playback
- Specify the transition between the local and remote playback when changing remote.state (#25)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item08
- PROPOSED RESOLUTION: @avayvod to define local and remote player concepts in spec as source of behavior for media element. In connecting/disconnected state, local player is active. In connected state, remote player is active.
ACTIONs from the F2F (good to land after FPWD):
My expectation is that these ACTIONs we are fine to address after the FPWD, since they seem not to alter the technical scope of the spec, and as such do not impact the Call for Exclusions triggered by the FPWD publication. We can bake these changes into the subsequent Working Draft publication that follows FPWD.
- [Meta] Guidance for HTMLMediaElement, HTMLAudioElement, HTMLVideoElement behaviors during remoting (#41)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item09
- PROPOSED RESOLUTION: Extend the requirements doc as a start, best effort for UAs to reflect remote state locally otherwise.
- Do we need remote.getAvailability()? (#39)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item03
- ACTION: @avayvod to craft a PR to use observe/unobserve pattern for availability
- Define the interaction with Media Session (#10)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item10
- ACTION: @mounirlamouri 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.
- Allow the user agent to choose which media element source to play remotely (#7)
- F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item07
- ACTION: Investigate HTML source selection algorithm to decide if it is applicable, possibly on @foolip
from remote-playback.
Hi Anssi,
Thanks for summarizing the proposals so neatly! Note, that Mounir and I both will have limited availability (at an internal offsite and BlinkOn) the week of June 13 so more wiggle room might be needed.
That said, I'm going to draft PRs for the proposed resolutions in advance this week and the next in hope there will be no more than minor adjustments to the proposals before the 10 working days deadline (which is June 8, right?). That should allow us to land the PRs in time for June 13, so the plan SGTM.
Thanks,
Anton.
from remote-playback.
Also, ideally I'd like to see issue #39 resolved before FPWD as it means backwards incompatible changes to the spec.
from remote-playback.
ACTION: Investigate HTML source selection algorithm to decide if it is applicable, possibly on
Is the idea here that the UA would be free to pick from any of the source
child elements which resource to use from the remote playback? In general I would be very cautious about that, the resource selection algorithm works by picking the first source that works, and doesn't ever switch once playback is in progress.
Is the problem at hand what to do when the resource playing locally cannot be decoded on the remote?
from remote-playback.
Oops, will comment on #7 instead.
from remote-playback.
Hi Anssi et al,
My priorities have switched to another feature in Chrome for the next couple of weeks so I doubt I'll have enough time to fix the issues blocking the FPWD by June 13. Could we move the date to whenever all the blocking issues are closed?
Thanks,
Anton.
from remote-playback.
@avayvod Thanks for the heads up. Unless Mounir or someone else is able to back you up, we'll need to delay the publication. Are you able to provide a guesstimate when you think you could close the FPWD blockers so we could plan the publication accordingly. Would e.g. 27 June be too early?
from remote-playback.
Let's target June 27 for now and move it to later if needed.
from remote-playback.
@avayvod Are we still on track to close the FPWD blockers by June 27 (next Monday), or should we plan with a later date in mind?
from remote-playback.
Hi Anssi, probably not. I'm only getting back to work on Remote Playback API next Monday. Let's move by two more weeks, please.
from remote-playback.
Let's plan for 11 July to have the FPWD blockers cleared.
The upcoming vacation period might impact our publishing plans, since we'll need W3C team support to publish an FPWD (can only use the automated publication workflow for WDs).
@tidoust any blackout date for the summer months regarding publishing from the team's perspective? Assuming 11 July we have a publication ready FPWD in our hands, when could we possibly publish earliest?
from remote-playback.
@anssiko The only blackout dates before TPAC are next week (Geek Week), so no problem for a later publication.
Once we have a publication ready FPWD in our hands, we first need to record the group's approval to publish the FPWD. Once done, I need to get the approval of the Ubiquitous Web domain lead, and request publication (FPWD still need to be published manually, Echidna cannot be used). The first step is the longest:
- CfC - 10 days which would take us to 22 July. Or is the document ready enough to send a conditional CfC early next week?
- Domain lead approval - <1 day (unless Philipp is not available)
- Publication request - ~2 days but may be less, especially if the document passes "pubrules" (and it will!). Publications happen on Tuesdays and Thursdays.
In short, the internal process should not add much overhead, it all depends on the call for consensus.
Note: as part of the CfC, the group needs to agree on a short name for the spec, which I assume will be "remote-playback" (the shortname appears in the URL of the spec: https://www.w3.org/TR/[shortname]).
from remote-playback.
CfC: Publish First Public Working Draft of Remote Playback, review by 11 July
Note: the FPWD publication is conditional to the F2F resolutions being integrated into the spec.
@tidoust To plan ahead, assuming we have a publication ready FPWD by 11 July, can you try to schedule a Domain lead approval as well as publication request at the earliest next opportunity after that?
from remote-playback.
@anssiko Yes, I will try to arrange things accordingly.
from remote-playback.
First Public Working Draft published:
https://www.w3.org/TR/2016/WD-remote-playback-20160714/
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.