Should apps force-register HttpFetchPlugin when isSupported() returns false?

Vega Open Beta Q&A
1

Should apps force-register HttpFetchPlugin on Vega/Fire TV when isSupported() returns false?

Environment: Vega SDK 0.23.8358 · @amazon-devices/react-native-w3cmedia 2.1.99 · Shaka Player 4.16.13 · Fire TV Stick

On our Fire TV Stick, shaka.net.HttpFetchPlugin.isSupported() returns false
(it requires a constructible ReadableStream and new Response('').body —
shaka http_fetch_plugin.js L289-L315),
so Shaka would normally fall back to HttpXHRPlugin.

But the Vega Video Sample App’s ShakaPlayer.ts explicitly unregisters the
default http/https handlers and force-registers the fetch plugin at
APPLICATION priority anyway:

shaka.net.NetworkingEngine.unregisterScheme('http');
shaka.net.NetworkingEngine.unregisterScheme('https');

const httpFetchPluginSupported = shaka.net.HttpFetchPlugin.isSupported(); // false on Kepler

shaka.net.NetworkingEngine.registerScheme(
  'http',
  shaka.net.HttpFetchPlugin.parse,
  shaka.net.NetworkingEngine.PluginPriority.APPLICATION,
  true,
);
shaka.net.NetworkingEngine.registerScheme(
  'https',
  shaka.net.HttpFetchPlugin.parse,
  shaka.net.NetworkingEngine.PluginPriority.APPLICATION,
  true,
);

Question: Is force-registering HttpFetchPlugin intentional and the
recommended networking path for Shaka on Vega, even though isSupported()
reports false?

We ask because on the default XHR fallback path, Shaka’s ABR bandwidth estimate
gets corrupted on our device (byte counts come back NaN, which pins ABR to the
startup rendition). So we’re trying to understand whether force-registering the
fetch plugin is the sanctioned workaround, or whether the XHR path is expected
to work. (Happy to share the detailed XHR/NaN root-cause analysis if useful.)

4

Hi @fubo-thughes,

Great question - thank you for providing the specific code references.

Yes, force-registering HttpFetchPlugin is intentional and the recommended networking path for Shaka Player on Vega.

The Vega MSE Porting Guide ( Porting Media Source Extension (MSE) Players to Vega | Design and Develop Vega Apps ) explicitly states as its first guideline:

│ “Replace XMLHttpRequest (XHR) objects with the Fetch API.”

The reason isSupported() returns false is that Vega’s JavaScript runtime supports the Fetch API but does not implement all the browser-specific APIs that Shaka’s support check looks for (constructible ReadableStream and new Response(‘’).body). The Fetch API itself works correctly for network requests - the check is a false negative on this platform.

The Vega Video Sample App’s approach of unregistering the default schemes and force-registering HttpFetchPlugin at APPLICATION priority is the sanctioned pattern. The XHR path is not the recommended networking path on Vega.

One additional note from the porting guide: “Do not use the ReadableStream interface in the Fetch API and use asynchronous full read.” This means fetch works on Vega without streaming support, which is sufficient for segment downloads.

Regarding your XHR/NaN bandwidth observation - this is consistent with XHR not being the supported path. The force-register pattern you found in the sample app is the correct solution.

References:

Thanks for helping us improve the Vega platform.

Warm regards,
Aishwarya