RE: revised recording proposal

> The Blob case, I should point out, is actually the "normal DOM object" case. I.e., it's actually ArrayBuffer which is special, but not in any way that I can see is significant.

Let's take this discussion out of the weeds.  I posed the question as to why Blobs instead of ArrayBuffers were being returned for timesliced data (not whole file data).  So far you are the only one who has provided what I think is an acceptable answer.

> If we want to discuss esoteric implementation details: In Gecko ArrayBuffers have a 4 GB limit (and any 32-bit UA will have a much smaller one). This is a limit that in practice it is quite common to hit while doing whole-file-at-once recording.

This is useful and thanks for providing.  You won't avoid this limit by using a Blob (I assume) because the blob encompasses an ArrayBuffer.  Moreover, the spec as written does not call for a File to be returned - all it says is that a blob would be returned to the ondatavailable event handler.

In a previous email exchange I posed the question of whether the UA could return data at regular intervals without a timeSlice being specified to account for buffer limitations.  The spec author responded that this would be an error event and that recording shouldn't continue in this case (if I understood correctly).  I think this should be a warning event and that the recording should be allowed to continue, but I agree that such an approach doesn't make for elegant API design.

-----Original Message-----
From: Timothy B. Terriberry [mailto:tterriberry@mozilla.com] 
Sent: Thursday, November 29, 2012 12:55 PM
To: public-media-capture@w3.org
Subject: Re: revised recording proposal

Mandyam, Giridhar wrote:
> Thanks - this is along the lines of what I would have liked to point 
> out regarding implementations of typed arrays versus blobs (but not 
> quite everything).  I don't believe this distinction is irrelevant at 
> all.  But I

Can you explain why you believe it is relevant? The Blob case, I should point out, is actually the "normal DOM object" case. I.e., it's actually ArrayBuffer which is special, but not in any way that I can see is significant.

> can also understand why going into the topic of specific 
> implementations can be problematic in this group.

I can't. We're talking plumbing here. This is not rocket science. If we can't even discuss this stuff, we might as well forget talking about anything that's actually valuable.

> I think one goal should be to avoid replication of multimedia buffers 
> in
 > virtual space due to multiple references.

I agree, which is why, as Jim points out elsewhere, the immutability of Blobs is important. Without that, the UA has to copy the data every time it hands it to any listener, to prevent them from tromping on the underlying data that someone else might be using.

> Blobs could (and should) be implemented in a similar fashion I 
> suppose, but  [snip] conceivable that the new blob created from a 
> slice could result in a new copy in a poorly designed UA - there is no 
> normative text preventing it.

Normative text is for ensuring interoperability, not mandating minor performance optimizations (UAs have plenty of incentive to enable those regardless of any normative text). But I think this has gone pretty far into the weeds. If you have an implementation and associated benchmarks that demonstrate one approach performs much better than the other, than that is interesting. Otherwise, not so much.

If we want to discuss esoteric implementation details: In Gecko ArrayBuffers have a 4 GB limit (and any 32-bit UA will have a much smaller one). This is a limit that in practice it is quite common to hit while doing whole-file-at-once recording.

Received on Thursday, 29 November 2012 23:47:55 UTC