Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed control #9

Open
tomByrer opened this issue Feb 24, 2023 · 4 comments
Open

Speed control #9

tomByrer opened this issue Feb 24, 2023 · 4 comments

Comments

@tomByrer
Copy link

While many video & podcast players have a playback speed control. Also I & 1 million+ other people installed @igrigorik's VideoSpeed.
Good idea for a standard HTML video/audio player UI?

Some video speed UI have +/- 10 seconds or move frame-by-frame. Might be out of scope for this proposal, but maybe cross-mentioned?

Bonus: array input to hand config:

<video controls speed="0.5, 0.75, 0.9, 1, 1.1, 1.25, 1.5, 2" "width="250">
    <source src="/media/cc0-videos/flower.webm" type="video/webm">
    <source src="/media/cc0-videos/flower.mp4" type="video/mp4">
</video>
@tomByrer tomByrer changed the title Speed controll Speed control Feb 25, 2023
@igrigorik
Copy link

I like the idea! The native <video> element has built-in speed controls, but it does not expose an API to control or define the increments. I think it would be a nice idea to explore making that a first-class feature. WICG is the right place to initiate the discussion and gauge interest: https://discourse.wicg.io/

@tomByrer
Copy link
Author

tomByrer commented Feb 28, 2023

I can discuss in that forum but I understood from the readme this repo was the brainstorm hub to be later discussed over there?

proposals to be something that we can eventually propose to the Media WG or WhatWG

@heff Do you want me to hone the idea here first, or the WICG discourse?

@cjpillsbury
Copy link
Collaborator

@tomByrer per @igrigorik's callout, that request feels better suited for WICG, since it requires an actual UI change as well, though happy to discuss here as well. We've tended to keep media-ui-extension proposals focused on exposing data/information in a predictable and well defined way that can then be used by custom UIs.

You may be interested in Media Chrome (for this case, our <media-playback-rate-button>), which is where we've been trying to build "player agnostic UI components/architectures". We've actually just added support for 3 of the media-ui-extension proposals to Media Chrome:

  • Stream Type (needs to be converted to an official proposal per our new process)
  • DVR State (needs to be converted to an official proposal per our new process)
  • Live Edge Window (our first official proposal using our new process)

Feel free to reach out with any followup discussions, and it's definitely fine to continue the conversation around this particular proposal.

@heff
Copy link
Member

heff commented Feb 28, 2023

@cjpillsbury and I talked about this IRL and from that, revising what he said before a little, we're happy to have the conversation happen here if it can result in a refined proposal or more concentrated engagement. We do generally focus on the media element APIs that could unlock custom UI features, rather than browser-built-in UIs which are inherently all different to begin with. But there's also enough overlap that it's at least loosely relevant. So discuss away! At the same time I'd encourage everyone to post on wicg in parallel, to not delay awareness and gather interest on that side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants