[Bug 27982] New: Clarify asynchronicity in duration change algorithm when reducing duration

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

            Bug ID: 27982
           Summary: Clarify asynchronicity in duration change algorithm
                    when reducing duration
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: bugs+w3@karlt.net
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

The last steps of the duration change algorithm are as follows:

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.

5. If a user agent is unable to partially render audio frames or text cues
   that start before and end after the duration, then run the following steps:

  1. Update new duration to the highest end time reported by the buffered
     attribute across all SourceBuffer objects in sourceBuffers.

  2. Update duration to new duration.

6. Update the media controller duration to new duration and run the
   HTMLMediaElement duration change algorithm.

How does this work with step 5 of the range removal algorithm?

5. Return control to the caller and run the rest of the steps asynchronously.

If "return control to the caller" means return to the duration change
algorithm, then the buffered attribute would not yet have been updated and so
step 5 of the duration change algorithm would reset duration to
/old duration/.

Is the intention that steps 5 and 6 of the duration change algorithm should
run asynchronously after the asynchronous steps of the range removal algorithm?

Prior to "Added remove() calls to duration change algorithm" in
https://dvcs.w3.org/hg/html-media/rev/0c638da9a67a , the duration change
algorithm was always synchronous.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Sunday, 8 February 2015 21:16:06 UTC