[media-source] abort() shouldn't attempt to interrupt the current buffer append

jyavenard has just created a new issue for 
https://github.com/w3c/media-source:

== abort() shouldn't attempt to interrupt the current buffer append ==
Overview:
I believe abort() shouldn't interrupt the Coded Frame Processing 
Algorithm; as abort() as it's currently described results in non 
deterministic behavior in regards to which frames may have actually 
been added to the source buffer.

Rather than interrupt something that is really non-interruptible, it 
should only guarantee that the next call to appendBuffer or 
modification to timestampOffset or appendWindow will succeed.

Detailed explanation:

Per spec:
"Aborts the current segment and resets the segment parser."

Which then calls the Reset Parser State which defines:

"If the append state equals PARSING_MEDIA_SEGMENT and the input buffer
 contains some complete coded frames, then run the coded frame 
processing algorithm until all of these complete coded frames have 
been processed."

Now, let's look at the behavior on the append state value, which is 
defined in "Segment Parser Loop".
In a typical MSE transaction, it would go from WAITING_FOR_SEGMENT to 
PARSING_INIT_SEGMENT to (WAITING_FOR_SEGMENT to 
PARSING_MEDIA_SEGMENT):repeat

Now let's assume an appendBuffer is done with data containing 
"media_segment1 | media_segment2 | media_segment3"
The Segment Parser Loop runs asynchronously and during the time of its
 execution will update the append state then run the coded frame 
processing algorithm for a single media segment, then set the append 
state to WAITING_FOR_SEGMENT and rinse and repeat.

Now we have an abort() and the Reset Parser State step.

Let's assume that at the exact time the Reset Parser State is run, the
 Segment Parser Loop had been interrupted after just having finished 
processing media_segment1. As such the append state is 
WAITING_FOR_SEGMENT.

As the append state is not equal to PARSING_MEDIA_SEGMENT, none of the
 remaining frames of the input buffer will be processed (as the 
conditional is AND)

As in step 7 of the Reset Parser State we have "Remove all bytes from 
the input buffer.", the source buffer following this abort contains 
only media_segment1.

If however, the abort of the append buffer occurred when the middle of
 the media_segment1 was being processed, the append state now being 
PARSING_MEDIA_SEGMENT all remaining complete frames in the input 
buffer will be processed and the source buffer will now contain all 
frames of media_segment1, media_segment2 and media_segment3.

The behavior of abort() is as such racy and non deterministic (and 
that's ignoring the fact that interrupting an asynchronous step is 
inherently impossible to achieve)

I believe abort() should be made clearer to remove all ambiguities.

abort should now be:
3: If the buffer append or stream append loop algorithms are running 
then run the following steps:
  1. Set the aborting flag to true
  2. Wait for the buffer append and stream append loop algorithms to 
complete.
4: If the updating attribute equals true, then run the following 
steps:
    1.Set the updating attribute to false.
    2.Queue a task to fire a simple event named abort at this 
SourceBuffer object.
    3.Queue a task to fire a simple event named updateend at this 
SourceBuffer object.
5: Run the reset parser state algorithm."

Step 1 of the Reset Parser State should be removed and add a last step
 (now 8)
"8. if the aborting flag equals true then set the aborting flag to 
false"

Buffer Append Algorithm now becomes:
2. If the segment parser loop algorithm in the previous step was 
aborted or if the aborting flag is set to true, then abort this 
algorithm.

Stream Append Loop now becomes:
14. If the segment parser loop algorithm in the previous step was 
aborted or if the aborting flag is set to true, then abort this 
algorithm.

Ultimately, the only reason for abort is to guarantee that the next 
operation relying on the updating attribute value will complete, and 
that any operations depending on the append state will also succeed 
(that is changing the mode attribute, and the timeStampOffset 
attribute)

At least this is how I've seen all DASH players using it (including 
YouTube)

Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/71 using your GitHub 
account

Received on Friday, 29 April 2016 04:00:06 UTC