This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#mediasource-detach "Remove all the SourceBuffer objects from sourceBuffers and fire a removesourcebuffer event for each one." 1. What is the point of firing one removesourcebuffer event per removed SourceBuffer at the SourceBufferList? 2. When is activeSourceBuffers updated, if at all? Depending on when it is updated the order of events would be different, which is script-visible and should therefore be part of a test suite for the API. If there is a good answer for point 1, then point 2 could be addressed by specifying it to the equivalent of "while (sourceBuffers.length > 0) removeSourceBuffer(sourceBuffers[0])" or some such. In any event, it should be specified if the SourceBuffers are removed in increasing or decreasing order, since the difference in event order is script-visible.
(In reply to comment #0) > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#mediasource-detach > > "Remove all the SourceBuffer objects from sourceBuffers and fire a > removesourcebuffer event for each one." > > 1. What is the point of firing one removesourcebuffer event per removed > SourceBuffer at the SourceBufferList? I don't have a good reason especially since this event doesn't even indicate which SourceBuffer is removed. I'll remove this since I can't think of any good reason to have it fire multiple times. > > 2. When is activeSourceBuffers updated, if at all? Depending on when it is > updated the order of events would be different, which is script-visible and > should therefore be part of a test suite for the API. It gets updated when tracks from different SourceBuffers get enabled/selected. I attempt to cover this in section 3.3.5, but I can see right now that I've been a little sloppy here and don't mention when the events fire. > > If there is a good answer for point 1, then point 2 could be addressed by > specifying it to the equivalent of "while (sourceBuffers.length > 0) > removeSourceBuffer(sourceBuffers[0])" or some such. In any event, it should be > specified if the SourceBuffers are removed in increasing or decreasing order, > since the difference in event order is script-visible. Good point. Since I didn't have a good answer for 1 I get to avoid this. :)
(In reply to comment #1) > (In reply to comment #0) > > > > 2. When is activeSourceBuffers updated, if at all? Depending on when it is > > updated the order of events would be different, which is script-visible and > > should therefore be part of a test suite for the API. > > It gets updated when tracks from different SourceBuffers get enabled/selected. > I attempt to cover this in section 3.3.5, but I can see right now that I've > been a little sloppy here and don't mention when the events fire. > I just realized that you were talking about what happens on the detach algorithm specifically. Here are the new steps for the detach algorithm which I believe cover your concerns. 1. Set the readyState attribute to "closed". 2. Set the duration attribute to NaN. 3. Remove all the SourceBuffer objects from activeSourceBuffers. 4. queue a task to fire a simple event named removesourcebuffer at activeSourceBuffers. 5. Remove all the SourceBuffer objects from sourceBuffers. 6. queue a task to fire a simple event named removesourcebuffer at sourceBuffers. 7. queue a task to fire a simple event named sourceclose at the MediaSource.
Changes committed. http://dvcs.w3.org/hg/html-media/rev/7bab66368f2c