-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add support for switching codecs #1528
Comments
Yeah, we want to add this eventually. Hopefully by the time that Chrome 70 is out, if possible. |
Added in webkit: https://bugs.webkit.org/show_bug.cgi?id=188626 Added in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1481166 |
Added in Safari Technology Preview release 64: https://developer.apple.com/safari/technology-preview/release-notes/ |
This hasn't been updated in a while, so it's worth pointing out some changes to this plan. As originally proposed, switching codecs was either implemented or not. Now, support depends on the decoding pipeline, and we can only query that with MediaCapabilities. Our MediaCapabilities integration is well underway. |
w3c/media-source#155 seamless codec switching should be possible too, since this is merged |
I began to look at this functionality and I have doubts, you have to call SourceBuffer.changeType to change the MSE codec/container, but what would happen as EME, would you have to restart EME? @joeyparrish, you have much more control of this part, you can help me. |
@avelad, sorry I didn't see your comment sooner. I don't believe EME necessarily needs to be reset, but EME may add a layer of restriction to what transitions are possible with changeType. In context of decodingInfo() results that include EME, we would then ask MCap which transitions are supported among the supported codecs. That may be the entire set of supported containers/codecs, or it may be a subset. The logic for how to handle subsets has yet to be designed. And that logic needs to be designed and implemented even for clear content, because the API does not guarantee that you can switch between all supported codecs. (Though I expect that to be the case for evergreen desktop and mobile browsers.) |
This has become a big topic recently at paramount. We are ready to help implementing this based on the designs and approaches discussed. Supporting both sides of Chrome 70 is interesting. Has there been anymore discussion around this as of recent? Is there a bigger ticket around this topic? |
No more recent discussion than what you see here, as far as I recall. |
Closes: #1528 Closes: #1567 Closes: #4379 Closes: #5306 --------- Co-authored-by: Álvaro Velad Galván <[email protected]>
Closes: shaka-project#1528 Closes: shaka-project#1567 Closes: shaka-project#4379 Closes: shaka-project#5306 --------- Co-authored-by: Álvaro Velad Galván <[email protected]>
Switching codecs are to begin experimentation via origin trials in Chrome 70.
https://www.chromestatus.com/features/5719220952236032
https://bugs.chromium.org/p/chromium/issues/detail?id=605134
Is it possible add support for it in a future release?
Caniuse: https://caniuse.com/mdn-api_sourcebuffer_changetype
The text was updated successfully, but these errors were encountered: