- From: <bugzilla@jessica.w3.org>
- Date: Fri, 21 Sep 2012 21:02:10 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18920 --- Comment #3 from Aaron Colwell <acolwell@chromium.org> 2012-09-21 21:02:10 UTC --- (In reply to comment #2) > (In reply to comment #1) > > > Yes this was done intentionally. The media engine needs to know what the format > > of the bytestream is to properly parse it. The assumption here is that the > > application knows what type of content it is trying to append because it needs > > this information to properly identify where init/media segments are anyways. > > It seems to me that one can away with ignoring the given type completely by > just inspecting the first segment that is appended. With the two bytestreams formats that are defined, that is probably true. For WebM you essentially know within the first 32 bytes or so. If more formats get added later this may become more tricky. I'd hate to get into a case like MP3 again where you have to parse a decent amount of data before you can be confident that you are actually dealing with an MP3 stream. The type in addSourceBuffer() was also indended to provide a way for the UA to get a hint about what the SourceBuffer will be used for so that it can determine whether it has enough resources to support the format. Throwing an exception at addSourceBuffer() allows the MediaSource to signal that it doesn't have enough resources to support the specified format and this error is signalled in a context that doesn't trigger playback to error out. One could argue that this same exception could be signalled from append(), but it seemed less clean to me. I was thinking of addSourceBuffer() as filling a resource reservation & canPlay() role as well creating endpoints to append media data. I'm up for rethinking this if people really object to the type parameter. I just thought it would make bytestream validation easier if the UA was told exactly what type of bytestream the application intends to append. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 21 September 2012 21:02:11 UTC