- Replace shaka-player#4775 link (closed) with TeamPiped/Piped#4238 as the
ongoing tracker.
- Add measured rough per-call cost: Chromium ~0.1 ms vs Firefox ~20 ms.
- Call out explicitly that this is a hack: forcing smooth/powerEfficient to
true throws away signals Shaka would otherwise see. If anything in the
player chain reads those fields (preferredDecodingAttributes is set, a
downstream consumer ranks variants on power efficiency, or a Shaka
upgrade changes filtering), Shaka will pick streams the device cannot
decode in real time — frame drops, software-decode CPU spikes, battery
drain. Today (Shaka 5.1, Piped default config) the fields are not read
and the shim is harmless; revisit on every Shaka upgrade.
Refs: https://github.com/TeamPiped/Piped/issues/4238
Firefox's navigator.mediaCapabilities.decodingInfo costs ~14 ms per call
(out-of-process RDD decoder probe). Shaka Player calls it once per Variant
in the DASH manifest while filtering supported variants, and YouTube
manifests routinely have 1000+ variants, so player initialization stalls
15-20 s on Gecko-based browsers before the first SourceBuffer is added.
Wrap decodingInfo to delegate "supported" checks to
MediaSource.isTypeSupported (sub-ms on Firefox) with a per-MIME cache.
DRM probes and non-media-source queries fall through to native.
Wrapper is gated to Gecko UAs so Chromium and Safari are unaffected.
Refs: https://github.com/shaka-project/shaka-player/issues/4775
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
