-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Caching and other efficiency improvements for mcap polyfill #4574
Comments
@sky-hugolima are you interested on send a PR for it (we can discuss the implementation in your PR)? Thanks! It makes a lot of sense to have a cache in some cases. |
@sky-hugolima Does this answer all your questions? If so, would you please close the issue? |
@sky-hugolima Does this answer all your questions? If so, would you please close the issue? |
Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including |
It sounds like you're proposing to make the mcap polyfill more efficient with caching and/or device-specific details hard-coded. I think that's a fantastic idea. I'll convert this to a feature request and assign it to @sky-hugolima for a PR. Thanks! |
Hey ! |
Thanks @sky-hugolima ! |
) This PR caches the result of `requestMediaKeySystemAccess` saving time on subsequent calls. It also makes the calls to `decodingInfo` synchronous. The reason for this, is the result of testing on multiple devices that the behaviour of `requestMediaKeySystemAccess` appears to be synchronous, making this synchronous can save over a second on older TVs. Closes #4574
Hey !
We've recently changed from Shaka 3.0.5 to 3.3.10, and I noticed that with the new decoding capabilities detection logic, that uses MediaCapabilities API on devices where a shim/polyfill is needed (e.g. WebOS, PS5), there's a non residual time spent doing repetitive calls to
requestMediaKeySystemAccess
(on lower end LG I saw ~300ms), where previously (3.0.5) we only had to make one call for each key system (Playready, Widevine).I considered implementing a cache strategy that would store, during the app life cycle, the MediaKeySystemAccess results for each "key system" / codecs, which does improve the performance on subsequent playback sessions but not for the 1st ones.
That got me thinking about alternative ways to do decoding capabilities detection for devices/models where the capabilities are known at compile time and are never expected to change (typically on consoles and SmartTVs)
For example on PS5 (MediaSDK) we know it supports Playready with ec-3, aac, h264 and h265, so instead of doing capability detection for that device we could get a MediaKeySystemAccess instance for Playready with a common media key system config (e.g. ec3 & h265), at the MediaCapabilities polyfill install stage, and then on the
decodingInfo
call we would return the decoding info without any additional calls to eitherrequestMediaKeySystemAccess
orvideo.canPlayType
.What do you think ? Do you have any concerns with this approach ?
The text was updated successfully, but these errors were encountered: