W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 18510] decodeAudioData should accept a mime-type

From: <bugzilla@jessica.w3.org>
Date: Fri, 05 Oct 2012 21:21:13 +0000
Message-Id: <E1TKFKb-0003Mx-1z@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18510

--- Comment #12 from Chris Rogers <crogers@google.com> 2012-10-05 21:21:12 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (In reply to comment #8)
> > > > I would also prefer decodeAudioData to accept a non-optional mimeType argument,
> > > > and I think we raise an error if the mimeType argument is not supported by the
> > > > engine.  The reason that I would advocate for this change is that the audio
> > > > codecs supported by each engine (potentially on each platform) is different,
> > > > and that makes sniffing even worse than it already is.
> > > 
> > > Can you clarify how varying codec support between browsers and platforms make
> > > sniffing any harder? AFAIK, none of the formats supported by any browser are
> > > hard to sniff or possible to mistake for another supported format.
> > 
> > They won't make sniffing harder -- it just makes people rely on sniffing
> > potentially multiple audio streams, which means that the browser engine needs
> > to download the first few kilobytes of all of them until it finds one which it
> > can decode.
> > 
> > The idea that I'm going after is very similar to the HTML5 source element.  The
> > source element allows the browser engine to select the encoding that it
> > supports *without* needing to download all of the available resources and sniff
> > them.  If decodeAudioData takes a mimetype argument, then the browser engine
> > can also avoid having to download the resource just to find out that it cannot
> > decode it.
> 
> decodeAudioData takes an ArrayBuffer, so by the time you can call it you have
> already downloaded the data. I think that using HTMLMediaElement.canPlayType()
> to determine which format is supported and only downloading that data ought to
> be sufficient.

I agree with Philip, and also believe that requiring a MIME-type is much
heavier for the developer since they would have to keep track of more
information than they do today.  I can see that we might want to consider an
optional MIME-type, but would like to see practical use cases drive that.

-- 
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, 5 October 2012 21:21:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC