You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Last week, we've seen an issue on some Samsung and LG TVs when relying
on the RxPlayer new experimental `MULTI_THREAD` feature due to specific
opcodes found in our WebAssembly files which were not compatible with
some of those TVs' browser.
Though we isolated and fixed the issue in #1372, it might be better to
also find a longer term solution to rollback the `MULTI_THREAD` feature
when an issue is detected with it preventing us from playing.
This could be done in several ways, from throwing errors, to new events,
to just return a rejecting Promise in the `attachWorker` method.
I chose to go with the latter of those solutions now because it appears
logical API-wise and implementation-wise to have that method return a
Promise which resolves only if we're able to communicate with a
WebWorker (and reject either if the browser does not support it, if a
security policy prevent from running the worker, if the request for the
worker's code fail or if the code evualation itself fails).
I've also added a specialized error just for that API to give more
context about what failed (missing feature? etc.).
I was afraid that relying on this new Promise to indicate an issue at
WebAssembly-compilation-time for our MPD parser would bother us in the
future if we ever add other WebAssembly modules (e.g. a smooth parser),
which could also independently fail (should we reject the Promise when
either compilation fails? Even if we could theoretically still play DASH
contents? How would we mix this way with a potentially lazy-loading of
features where we wouldn't be compiling right away? and so on...), but
after exposing all the potential future paths I could see this
`MULTI_THREAD` feature taking, I was able to find an adapted solution
still compatible with returning a Promise on the `attachWorker` API.
I also tried to automatically fallback from a "multithread mode" to the
regular monothread one inside the RxPlayer but doing this was complex.
So for now, if `attachWorker` fails, the RxPlayer will remove the worker
from its state (new `loadVideo` calls won't depend on it) but it is the
responsibility of the application to reload if a content was loaded in
"multithread mode" was loaded in the meantime.
If an application doesn't want to handle that supplementary complexity,
it can just await the Promise returned by `attachWorker` before loading
the first content (and catching eventual errors). As the RxPlayer
automatically removes the worker if its initialization fails, this
will lead to automatically fallback on main thread. At the cost of some
time compared to load and initialize the worker parallely.
0 commit comments