This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
I believe this issue relates to one also raised in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27980, where duration changes that remove buffered data cause issues with asynchronous processing. That bug proposed disallowing duration changes that remove buffered data, and instead required that be done using remove() only. If done, that solution should resolve this issue as well.
This bug has been migrated to the GitHub issue tracker. Please follow/update progress using the GitHub issue: https://github.com/w3c/media-source/issues/20