Should media delivery during transfer be specified?

[dogben]

Regarding Transferable MediaStreamTrack, I think there is only one reasonable approach for handling delivery of media (video frames or audio data) during transfer: media stops flowing before postMessage returns on the sending side and does not start flowing until the time the transferred MediaStreamTrack is connected to a sink on the receiving side. All intermediate frames/data are dropped.

A consequence is that media won't be delivered while a transfer is in progress, which may be surprising to some developers.

There are a few unreasonable (IMO) approaches too:

• Media begins to be queued when postMessage is called and all frames are delivered once a sink is connected. (This is problematic because (1) the duration of queuing is unbounded, and (2) there is an expectation with MediaStreamTrack that frames are delivered in real time.)
• If originalTrack is connected to a sink before postMessage, media may continue to be delivered to that sink for some period after postMessage. (Since originalTrack's ReadyState is "ended," this seems unreasonable.)
• If originalTrack is connected to a sink before postMessage, there may be some overlap where the same frames/data are delivered to both the sink on the sending side and the sink on the receiving side. (This would conflict with the concept that there is a single MediaStreamTrack that is transferred between contexts, since a MediaStreamTrack can't "rewind.")

If I'm correct and there's only one reasonable approach here based on this and other specs, then perhaps nothing needs to be added to the specification for Transferable MediaStreamTrack. However, if it's likely that different UAs would choose different approaches to media delivery, we should consider nailing this down so that developers don't start relying on behavior that's not specified, e.g. if a UA provides (best-effort) continuous media delivery during a transfer.

[eladalon1983]

How would an application notice a difference between UAs employing queueing/dropping? Unless I am mistaken, frames can already be dropped during normal operation, or be spaced out less/more than usual, e.g. if there's CPU congestion or if the hardware acts up. If so, neither approach yields new JS-observable behavior. But it might change the frequency different scenarios manifest, which is probably not an issue spec-wise. Or wdyt?