W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: MediaElementAudioSourceNode and cross-origin media resources

From: Chris Wilson <cwilso@google.com>
Date: Tue, 23 Jul 2013 14:33:03 -0700
Message-ID: <CAJK2wqW6ANTdEzwsqHHvXKJPUz6ovCdZReq8xnb201nZ26Owog@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Joseph Berkovitz <joe@noteflight.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
I think Joe meant "I note that decoding network files into AudioBuffers
would naturally already adhere to CORS, since you'd use XHR to download

On Tue, Jul 23, 2013 at 2:28 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, Jul 24, 2013 at 8:09 AM, Joseph Berkovitz <joe@noteflight.com>wrote:
>> Not only should we subject this to CORS rules, I think we *must* subject
>> it to CORS rules. Audio assets are commonly delivered from CDNs and these
>> are typically located at an origin foreign to the containing page.
> Sure. However, authors will have to use the crossorigin attribute on the
> media element to generate a CORS-enabled request.
>> I note that AudioBuffer.decodeAudioData obeys CORS as a fact on the
>> ground in both the FF implementation and Webkit/Blink.
> I don't see how CORS is relevant to decodeAudioData. decodeAudioData takes
> an ArrayBuffer, which can never be cross-origin.
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
Received on Tuesday, 23 July 2013 21:33:30 UTC

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