- 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