- From: <bugzilla@jessica.w3.org>
- Date: Sun, 08 Feb 2015 21:16:04 +0000
- To: public-html-bugzilla@w3.org
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 the QA Contact for the bug.
Received on Sunday, 8 February 2015 21:16:06 UTC