- From: pqnet <notifications@github.com>
- Date: Tue, 17 Jun 2025 05:17:44 -0700
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/issues/480/2980150898@github.com>
pqnet left a comment (whatwg/streams#480)
> here is another potential solution to all of this: [w3c/FileAPI#209](https://github.com/w3c/FileAPI/issues/209)
>
> The idea being that you create a virtual blob and still use the good old `video.src = URL.creataeObjectURL(blob)`
>
> const virtualBlob = Blob.from({
> size: 1024,
> async stream(start, end) {
> return customStreamOrAsyncIterable(start, end) // could potential return response.body
> }
> })
>
> document.querySelector('video').src = URL.creataeObjectURL(virtualBlob)
This doesn't solve any of the issues that have been presented above:
- In case where the URL is downloaded multiple times (which may happen for implementation details of the browser) the `stream` function would be executed multiple times. This is well defined, but will surprise developers when they switch browser.
- I seem to understand that adding functionality to `createObjectURL` is problematic because of explicit reference management. Since there is no way to reliably track whether the URL is in use or not (it is a string) you are forced to manually `revokeObjectURL` to ensure the resources required by the object are not leaked.
(Note that the `<video>` case, as well as other `HTMLMediaElement` elements, can already use `srcObject` to be bound to an object without requiring to make an URL for it)
--
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/480#issuecomment-2980150898
You are receiving this because you are subscribed to this thread.
Message ID: <whatwg/streams/issues/480/2980150898@github.com>
Received on Tuesday, 17 June 2025 12:17:48 UTC