22432 2013-06-24 02:27:58 +0000 Allow SourceBuffer.appendBuffer to take ownership of the ArrayBuffer 2013-10-11 22:33:27 +0000 1 1 1 Unclassified HTML WG Media Source Extensions unspecified All All RESOLVED INVALID P2 normal LC 1 kinetik acolwell acolwell kbr mike public-html-media public-html-bugzilla oldest_to_newest 89739 0 kinetik 2013-06-24 02:27:58 +0000 Require the "data" ArrayBuffer to be neutered during the append to allow the implementation for avoid copying the data internally and prevent races where script modifies the ArrayBuffer while it's being used internally. Suggestion: add wording similar to that added to Web Audio's decodeAudioBuffer method: https://dvcs.w3.org/hg/audio/rev/ef43ae5230bf 94334 1 acolwell 2013-10-04 21:08:44 +0000 Aside from WebAudio there doesn't appear to be any other precedent for "unneutering" a buffer. I talked to Kenneth Russell, one of the Typed Array spec editors, last week about this request and he did not seem very supportive of adding the "unneutering" concept. I'm happy to add text to the MSE spec explicitly pointing out that modifying the buffer while an appendBuffer() operation is pending will lead to undefined behavior. I don't think we should "neuter" and then "unneuter" during the append though since this would make all ArrayBufferViews unavailable for reading during the append. Here is the link to the brief discussion we had on the MediaTF telecon call two weeks ago. (http://www.w3.org/2013/09/24-html-media-minutes.html#item06) FWIW it doesn't appear like Microsoft is going to modify their implementation and at this point I don't see a large enough benefit to modify the Chromium implementation. Also Chromium doesn't currently have the ability to "unneuter" ArrayBuffers so it is unlikely that there is interop on this point even in the WebAudio case. 94455 2 kinetik 2013-10-08 10:22:03 +0000 My original comment was incorrect: there's no possible race because "data" is copied to the internal input buffer synchronously at step 3 of appendBuffer before appendBuffer reaches the asynchronous step 6, so there's no opportunity for the ArrayBuffer to mutate in parallel. I'm happy for this to be closed as invalid. Sorry for wasting your time!