If Blob URLs are immutable, how does Media Source Extension API use them to stream videos?

Question

Let's start with an example:

1. You visit youtube.com, which uses Media Source Extension (MSE) with HTML5 for certain devices.
2. MSE injects the <video> tag with a blob URL. It looks something like this: blob:https://www.youtube.com/blahblahblah"
3. Throughout streaming the entire video, your browser makes multiple network calls to download the various chunks of video, and appends them to the MSE's SourceBuffer
4. Therefore, the Meda Source object as a whole is updated throughout the video stream
5. However, the blob URL that was initially attached to the <video> element, which is suppose to represent the Media Source object, remains constant.

To me, this doesn't seem to make much sense. Blob URLs are suppose to represent chunks of immutable data that never changes. But it seems like MSE is able to make them represent a mutable buffer of memory.

How does this work under the hood? And if we also want to make blob URLs represent some mutable buffer of memory, how can we do this ourselves with javascript?

Answer 1

You need to understand that BlobURIs do not represent any data. They are just links, pointing to some resource in memory, just like the string https://stackoverflow.com/questions/54613972 doesn't contain any of what you are reading per se, it just points to a server instruction which will then generate the page.

Their link can be said to be immutable, once you generated it using URL.createObjectURL(target), you can not change its target, just like if you used the const keyword.

Take for instance const foo = {} now foo can't be set to something else than this object. But the object that is pointed by foo address is still mutable. foo.bar = 'baz' can still be done.

const foo = {};
try{
  foo = 'fails';
}
catch(e) {
  console.error(e);
}
foo.mutable = true;

console.log(foo);

Well for blobURIs it's just the same. The blobURI points to a target object, this link can't be changed, but the target is still mutable. This is true for MediaSource objects but also others.

If you remember a few years ago, we were still able to use blobURIs for MediaStreams (was a bad idea), it was the same process, the blobURI was pointing to the MediaStream object, in an un-mutable manner, but the media-data was in constant mutation (a stream).

And even for Files, you can very well have a blobURI that points to a File on your hard-drive, this won't block you from removing it from your HDD, even though the blobURI now points to nowhere anymore.

The one particular case with this regard is the case of a Blob, generated from data in memory (i.e not just a pointer to a file on disk). Here the data held by the Blob is immutable, so in this case, the blobURI indeed points to an object that does hold immutable data.

And for you request to have a blobURI pointing to some data stored in memory, but still be able to modify this data, this can't be done...
That is because this scenario implies that you created your blobURI from a Blob object using data in memory, which once again does hold data in an immutable state.

Answer 2

The Blob URL used for MediaSource is a special case. MediaSource is a special case.

The conception that

Blob URLs are suppose to represent chunks of immutable data that never changes.

is not necessarily true. Consider a Blob URL that contains, for example, HTML and JavaScript. Further data can be generated from that original Blob URL, including additional Blob URLs.