Conclusion: Cloning and sharing of MediaStreamTracks - worth it?

This discussion branched and wound a bit, with not that many cycles 
spent on the actual question.

I drew the following conclusions from it after review:

A track has:
   - a source reference (if connected)
   - zero or more sink references (as connected)
   - an enabled state
   - a constraint set

If cloned, all of these are copied (by value) to the new track. This 
increases reference counts (if the implementation uses those) to the 
source and sink(s).

[not part of the original question]
A source has properties, these cannot be directly modified through the 
API, but some can be observed.
A change in the constraints for the tracks connected to it so that the 
sum of constraints isn't satisfied any more will (if possible) result in 
a change to the properties that attempts to satisfy all of the constraints.
It's OK for a source to produce multiple media streams (such as a 
downscaled or cropped version of a video), but it needs to not invent 
data (no upscaling).

The discussion seems to more-or-less converge on the conclusion that 
Adam's approach is clean enough and simple enough that we should move to 
that model. So the text stays as it is.

One still open question is whether a track can be a member of multiple 
streams; there are ease-of-implementation issues that argue for saying 
"no"; there are orthogonality arguments that argue "yes".
(If the answer is "no", I would argue that we should have a nullable 
"stream" property on the track, and that AddTrack throws an exception if 
the "stream" property of a track that's added is not null. That makes it 
predictable for the API what happens if  you try to add a track to a 
stream.)

New day, new discussion....

Received on Wednesday, 22 May 2013 13:25:26 UTC