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

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

Matt Wolenetz <wolenetz@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |wolenetz@google.com
           Assignee|adrianba@microsoft.com      |wolenetz@google.com

--- Comment #1 from Matt Wolenetz <wolenetz@google.com> ---
It seems the intent of abort() is to abort range removal algorithm as well as
buffer and stream append algorithms, and is corroborated by the 'abort' event
description. However, the exact behavior of the duration change algorithm in
the context of an abort() aborting the range removal algorithm (on a change to
a lower duration) needs clarification as well.

Ideally, the clarification would prevent the possibility of the abort()'ed
duration change's range removal implementation retaining complete coded frames
that start at or beyond MediaSource.duration or HTMLMediaElement.duration.

How does the following two part change sound?

1) In abort(), change step 3.1 from "Abort the buffer append and stream append
loop algorithms if they are running." to "Abort the buffer append, stream
append loop, and range removal algorithms if they are running."

2) In Duration Change, change from:
...
3. Update duration to new duration.
4. If the new duration is less than old duration, then run the range removal
algorithm with new duration and old duration as the start and end of the
removal range.
...

to

...
3. If the new duration is less than old duration, then do the following steps:
3.1. Run the range removal algorithm with new duration and old duration as the
start and end of the removal range.
3.2. If the range removal algorithm in the previous step was aborted, then
abort this algorithm.
4. Update duration to new duration.
...

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

Received on Thursday, 9 April 2015 22:46:44 UTC