[Bug 27980] [MSE] Ambiguous behaviour when running sourcebuffer.abort()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27980

--- Comment #4 from Jean-Yves Avenard <jyavenard@mozilla.com> ---
In Firefox, we've understood asynchronous to mean just that, with no
assumptions that all operations would run on a single thread.

We have undertaken a full rewrite of our MSE stack over the past few months,
highly parallelizing the implementation.

Making any MSE calls synchronous now would be extremely difficult if not
impossible without adding blocking calls which are inherently bad.

Making Remove synchronous would be a very unfortunate decision I believe.
Currently, all operations on the track buffers are asynchronous, that include
the buffer append algorithm or the range removal algorithm. If one is to be
async, its seems logical to have the other async too.
Certainly makes it easier in regards to a multi-threaded implementation.

I would much rather change the design of abort() instead. Including
consideration for its removal.

In an asynchronous/multi-threaded world, you can't guarantee what state a call
to abort() would leave the track buffers in. Some or all media segments may
have already been processed. An init segment may have been processed which the
JS would have no way of knowing.

The Reset Parser State algorithm, makes no consideration for the case where an
init segment from the earlier call to appendBufer got processed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 1 July 2015 23:52:16 UTC