-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make MediaStreamTrack serializable #58
Comments
I understand what it means to serialize a VideoFrame, write it to disk, read it later. A frame seems to me equally useful on the machine where it was first produced, as on a machine where it is recreated. What, though, is the meaning of deserializing a track on another machine, that has different peripherals attached and different permissions set? |
Note that you don't necessarily have to support storage (that's what the forStorage argument is for). And at least thus far storage is coupled to the same device, though I suppose a user agent could offer to synchronize it. |
I think we discussed this during a past WG meeting. |
Right, so since we can shim structuredClone(track, {transfer: [track.clone()]}); ...my question is why not support it outright? |
|
I think we should look at the meeting minutes, my recollection is that tracks are expensive objects, they have a potential impact on privacy indicators, temporary permissions...
My question is why supporting it outright? |
@youennf Privacy indicators and temporary permissions are tied to the context that created it. The track objects themselves are not expensive, as the cloning steps reveal. They are mere (ref-counted) handles to the singular underlying source.
If the concern is accidental clones, then event handlers aren't an issue. JS adding event handlers registers an interest. The JS is on the hook to call
How so? Why is I agree it can be a hassle for apps to keep track of clones, but I don't see this moving the needle one way or the other.
Simpler spec and model. Developers can already do |
Since I argued earlier for defining serialize and defining transfer in terms of serialize + stop, I can't say that I see much bad happening because of this :-) I do think we should have only one algorithm spelled out in the spec and define the other in terms of the spelled-out one. |
@annevk says most objects that are transferable are also serializable.
MediaStreamTrack has a custom
clone()
method today, like VideoFrame has. But VideoFrame is serializable while MediaStreamTrack is not.After looking over our custom clone algorithm in w3c/mediacapture-main#821, it seems semantically compatible to me, and since tracks are already transferable, I think it would make sense to make them serializable as well. This should simplify our algorithms, and make the following work:
Today this produces
DataCloneError: The object could not be cloned.
in Firefox Nightly.The text was updated successfully, but these errors were encountered: