On Wed, Jul 17, 2013 at 10:33 AM, Greg Billock <gbillock@google.com> wrote: > For access to streaming output of the encoder, ArrayBuffer seems to me > more appropriate. It's compatible with XHR2, File, and direct manipulation. > So are Blobs. Blobs also have the nice property that they're immutable and can therefore be shared easily between pages/across processes without copying. ArrayBuffers don't have that property. The only advantage ArrayBuffers have, in my view, is that individual bytes can be read and mutated very efficiently. Do we have use-cases for that sort of mutation of recorded data --- that would not be adequately served by making a copy of (parts of) Blobs to mutate them? Blobs also offer efficient concatenation (without copying), which ArrayBuffers do not. If you want to make a Blob out of it, you can, of course, but ordinarily > you'd be collecting these slices to manually append them somewhere or > sending them off as media stream slices. > I actually think Blobs (memory-backed) can be more efficient than ArrayBuffers for streaming (via Websockets for example), because we can share the Blob's memory buffer between processes without copying or breaking semantics. I also think that it's simpler to have a single data delivery event that produces a Blob, than to have separate events one of which produces a Blob and the other which produces an ArrayBuffer. 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, 16 July 2013 22:54:32 UTC