Re: Mediastream Recording implementation

I think the rationale for Blob and on-disk storage for full recordings is
clear and compelling. The recording can be manipulated as a handle, cheaply
copied, URL-ified, assigned as a media src attribute, etc.

For access to streaming output of the encoder, ArrayBuffer seems to me more
appropriate. It's compatible with XHR2, File, and direct manipulation.
Making a URL or similar Blob-relative artifact out of that partial stream
data doesn't make sense -- it can't be meaningfully assigned to a tag src
like a full recording can, for example.

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.



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

> On Wed, Jul 17, 2013 at 8:10 AM, Travis Leithead <
> travis.leithead@microsoft.com> wrote:
>
>>  I don’t know that we ever pinned down the question about what the
>> mimeType will be though.
>>
>
> When the entire recording is delivered in a single Blob, it's clear that
> the MIME type should be the actual type of the resource. That's
> ultra-convenient since anything that uses Blobs and relies on their type
> will just work.
>
> I think it's also clear that for multi-Blob resources, the MIME type of
> the first Blob should be the actual type of the resource. After all, the
> MIME type chosen by the recorder has to be reported somewhere. Also, it's
> often the case that a truncated resource of some container types can be
> played.
>
> For second and subsequent Blobs, it's not clear. We might want to use
> application/octet-stream to indicate that those Blobs are not valid
> resources of any type. But I think it doesn't matter much and if we want to
> give every Blob the MIME type of the resource (which others argued for
> IIRC), I think that'd be OK.
>
> 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  *
> *
>