Comments (8)
Right, so since we can shim structuredClone(track)
as:
structuredClone(track, {transfer: [track.clone()]});
...my question is why not support it outright?
from mediacapture-extensions.
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?
from mediacapture-extensions.
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.
from mediacapture-extensions.
I think we discussed this during a past WG meeting.
IIRC, the room consensus was that transferable was good enough for now.
As of structuredClone, I would guess structuredClone(track, [track]);
would work just fine.
from mediacapture-extensions.
I understand what it means to serialize a VideoFrame, write it to disk, read it later.
VideoFrame
does not support forStorage
. It's a ref-counted handle to (potentially GPU backed) buffers owned by the UA.
from mediacapture-extensions.
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...
Also, contrary to VideoFrame, a live track with event listeners might not be easy to GC.
Having an explicit cloning step allows keeping the number of live tracks low.
...my question is why not support it outright?
My question is why supporting it outright?
from mediacapture-extensions.
@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.
Also, contrary to VideoFrame, a live track with event listeners might not be easy to GC.
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 track.stop()
when it is finished with a track. That's already the contract.
Having an explicit cloning step allows keeping the number of live tracks low.
How so? Why is structuredClone(track)
any different from track.clone()
in this regard?
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.
My question is why supporting it outright?
Simpler spec and model. Developers can already do stream.clone()
and get a cloned stream containing clones of all tracks. This should fall out naturally with structuredClone, which would support other collections as well.
from mediacapture-extensions.
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.
from mediacapture-extensions.
Related Issues (20)
- [Track Stats API] Rename deliveredFrames to deliverableFrames HOT 2
- [Track Stats API] SameObject is a confusing API shape HOT 23
- [Track Stats API] When to initialize frame counting HOT 3
- Should web applications be aware of reaction effects added by OS to camera feeds? HOT 17
- [Audio Stats] Add current latency HOT 2
- Background Blur: Unprocessed video should be mandatory to support HOT 8
- [Track Stats API] Make stats attribute nullable instead of throwing when unsupported HOT 2
- [Stats] Example uses ratio, not percentage
- [Audio Stats] Add average, min and max latency HOT 5
- [Audio Stats] Disagreement about audio dropped counters HOT 19
- volume is not working HOT 1
- Move MediaStreamTrack stats in its own spec? HOT 10
- Clarify how `track.stats.resetLatency()` relates to run-to-completion semantics HOT 1
- https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack should talk about the MediaStreamTrack's application-set content hint
- Moving the source of a track
- Should we add reasons to MediaStreamTrack.onended HOT 4
- Add a blackFrames counter to MediaStreamTrackVideoStats HOT 7
- Consider adding onVoiceActivity event on MediaStreamTrack for audio HOT 3
- How to select camera presets that have better power efficiency at the expense of quality? HOT 2
- Clarifying Transferable MediaStreamTrack Types HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mediacapture-extensions.