This ties in with the topic of direct assignment of a mediastream as a media source. The reuse of the word "blob" can mislead people into thinking that the minted URL can be used for anything except assigning to a mediaelement's src attribute. It can't - in particular "the data exposed" doesn't make senses.

Calling it a "Stream URL" doesn't help as long as that isn't defined eitehr.

Suggest removing the word "blob" and just saying "an URL", and stating that its only required valid use is for assigning to an HTMLMediaElement.src attribute, removing the sentence about "data exposed on that stream".

A URL has observable bits so you cannot just say "a URL".

What is the concern with re-using blob URLs? You can key off the identifier part of the URL.

createObjectURL(MediaStream) does not return a URL representing a blob. The URL it returns can only be used as a media element source and does not correspond to a fixed array of bytes as blobs do. Thus the URL should use a different scheme.

In Firefox we return a URL of the form "mediastream:<uuid>".

Likewise, our WIP MediaSource implementation has createObjectURL(MediaSource) returning a URL of the form "mediasource:<uuid>".

Note that we still have not resolved how createObjectURL() should actually work for blob URLs: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/thread.html#msg240

It might be a good idea to wait a bit before expanding the usage of this method if that's still feasible.

We're kinda stuck with it already. It's in the wild and spreading fast.

I also think that we're stuck with the default behavior being NOT to auto-revoke, since that's what browsers currently implement.

I think this is basically OK as long as we spec the default to be not to auto-revoke, when we finally define how auto-revocation works.

Are we stuck with default being NOT autoRevoke because of shipping applications that will break since they rely on default being NOT autoRevoke, or any other reason?

I'm worried about shipping applications that would break it, but I don't know of any concrete examples.

I'm not enthusiastic enough about this change to volunteer Firefox to be the first browser to try to change. If another browser vendor wants to try the compatibility experiment, that's fine.

(In reply to comment #7)
> I'm worried about shipping applications that would break it, but I don't
> know of any concrete examples.
> 
> I'm not enthusiastic enough about this change to volunteer Firefox to be the
> first browser to try to change. If another browser vendor wants to try the
> compatibility experiment, that's fine.

Well, the spec shouldn't coerce implementations to do things they are reluctant to do :(  One of the reasons we put in autoRevoke=true by default was to minimize leaked strings (Blob URLs that persisted past their use), and to minimize forcing developers to couple a create* call with a revoke* call.  Do you think that's needlessly cautious?

I don't think it's needlessly cautious --- I think leaked Blobs could be a real problem. Auto-revoke by default would have been the right thing to do if we'd done it that way from the start (which would have required have a good spec for auto-revoke from the start, which we still don't have!).

> I don't think it's needlessly cautious --- I think leaked Blobs could be a
> real problem. Auto-revoke by default would have been the right thing to do
> if we'd done it that way from the start (which would have required have a
> good spec for auto-revoke from the start, which we still don't have!).

(In reply to comment #9)

I'm honestly not sure it's too late to fix this to be right, especially since we're not sure what's broken, but we are sure that leaked Blob strings can be a "real problem."  

What can we do to fix the autoRevoke behavior to be better, or address the nits you may have (per Comment 9)?  Right now autoRevoke=true is tied in with HTML's global script cleanup steps.  Advice appreciated, maybe on the public listserv (public-webapps@w3.org) if you think this bug isn't right. Spec at http://dev.w3.org/2006/webapi/FileAPI/

The thread starting at http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0240.html about the behavior of auto-revoke has still not reached a consensus.

Let's first reach a consensus on how auto-revoke should be work before we try to make it the default. Nothing would be worse than making it the default and then realizing that whatever compatibility data we collected was invalid because we had to change the behavior.

Suggested resolution:

CreateObjectURL returns an URL that can be used for setting as the .src URL of a <video> or <audio> element. The platform guarantees that it can be used for this purpose, and it guarantees that it can be used for this purpose once.

The effect of video.src = CreateObjectURL(stream) should be exactly the same
as video.srcObject = stream.

This specification should not need to make any more statements than this.

> CreateObjectURL returns an URL that can be used for setting as the .src URL of
> a <video> or <audio> element.

You mean specifically createObjectURL called with a MediaStream parameter, right?

> The platform guarantees that it can be used for
> this purpose, and it guarantees that it can be used for this purpose once.

Why only once? Gecko doesn't have that limitation.

> The effect of video.src = CreateObjectURL(stream) should be exactly the same
> as video.srcObject = stream.

It should be the same as far as the behavior of the media element goes, I agree. But you have to be careful with the wording because using srcObject has different implications for the lifetime of the stream than using createObjectURL.

(In reply to comment #13)
> > The platform guarantees that it can be used for
> > this purpose, and it guarantees that it can be used for this purpose once.
> 
> Why only once? Gecko doesn't have that limitation.

Yeah, I thought that odd too.  I can see why you might say "at least once", but I would have thought it straightforward enough to use the same URL as many times as the platform can handle, as long as the stream remains valid.
 
> But you have to be careful with the wording because using srcObject
> has different implications for the lifetime of the stream than using
> createObjectURL.

I lost you.  The two ways of doing essentially the same thing have different properties?  In what way?

You need to garbage collect the string-variant manually, because usage cannot be reference counted.

createObjectURL() should definitely not return an auto-revoking URL though for MediaStream as it doesn't do that for Blob. We will introduce a new API for that.

(In reply to comment #15)
> You need to garbage collect the string-variant manually, because usage
> cannot be reference counted.

Geez, that sounds like a great answer.  But I'm not buying it.  The URL is just a weak reference that allows for the creation of a strong reference.  If the referenced object happens to be garbage collected while there are only weak references, that's just too bad.

That would expose the garbage collector. Anyway, you don't have to take my word for it, just read http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL

(In reply to comment #17)
> That would expose the garbage collector. Anyway, you don't have to take my
> word for it, just read
> http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL

So, if you ascribe similar properties to MediaStream URLs as you do to blob URLs, then you get these properties.  Because this uses the same URL.createObjectURL() function, then I guess you have to keep those properties.  That's a shame, because I think that those properties aren't desirable.

The fundamental problem with createObjectURL is that there is no way for the browser to automatically know when the Web application is no longer using the string. That's why manual (or auto) revocation is needed. This problem is common to Blobs, MediaStreams and every other user of createObjectURL.

Anyway we're only quibbling about wording here. It's already pretty clear what Harald meant, and I just would like to see it stated a little more precisely.

Suggested resolution, take 2:

CreateObjectURL returns an URL that can be used for setting as the .src URL of a <video> or <audio> element.
It has exactly the same effect on the underlying MediaStream as CreateObjectURL has on a Blob: Creating a reference that has to be revoked before the MediaStream is garbage collected.

The effect of <tag>.src = CreateObjectURL(stream) on a HTML media tag is exactly the same as <tag>.srcObject = stream.

Good enough, but say "element" rather than "tag".

roc, how was it clear? He suggested it could be used just once which is not the behavior for Blob. I'm not sure we want to do that. In any event, this needs to be defined to the same level of detail as createObjectURL for Blob is defined. A paragraph doesn't seem good enough.

(In reply to comment #22)
> roc, how was it clear? He suggested it could be used just once which is not
> the behavior for Blob.

Comment #20 doesn't suggest that.

I'm not sure we want to do that. In any event, this
> needs to be defined to the same level of detail as createObjectURL for Blob
> is defined. A paragraph doesn't seem good enough.

OK.

I think this bug should be closed and the conversation moved to the list until we can figure out what direction the WG wants to go it. The editors discussed it for awhile and it was clear we did not know what we needed to to.

I am changing the subject of this bug to be more appropriate to the discussion.
What we seem to be converging on:

- The behaviour of CreateObjectURL(Mediastream) needs to be documented. In particular, that it behaves exactly the same as CreateObjectURL(Blob) with regards to creating references that prevent garbage-collecting the Mediastream.

- The URL that is returned from this CreateObjectURL operation should not start with the letters "blob:", because it can't be used or dereferenced in the ways that a "blob:" URL can. This is in line with what implementations do today.

- It would be great if the File API specification had a term we could point to just say "MediaStream is a FOO", and get the properties we want.

Adding a dependency on 23091. If CreateObjectURL is removed, we don't have to document it.

We have removed createObjectURL from the spec, so this is no longer relevant.