You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it seems that we're not exposing rid as metadata on the outgoing stream (on incoming rid should be undefined; mid might be marginally useful): https://w3c.github.io/webrtc-encoded-transform/#scriptTransform
Given the general thinking (that I don't agree with but that is a different story) that mid/rid is cooler than synchronizationSource should we expose it? Does the same apply to mid?
Is there a use case for a mid that is different from RTCRtpTransceiver.mid? Wondering if that part could just work automatically and the person dealing with encoded chunk does not have to care, but I could be wrong here
You don't have the transceiver, but you have a writable stream that is wired up to the transceiver, so the lower layers already know what MID to use. So is there any benefit to exposing it here as well? In theory maybe you wanted to overwrite it, but I don't know if that even makes sense
it seems that we're not exposing
rid
as metadata on the outgoing stream (on incoming rid should be undefined; mid might be marginally useful):https://w3c.github.io/webrtc-encoded-transform/#scriptTransform
Given the general thinking (that I don't agree with but that is a different story) that mid/rid is cooler than synchronizationSource should we expose it? Does the same apply to mid?
Use case: https://w3c.github.io/webrtc-nv-use-cases/#auction
The text was updated successfully, but these errors were encountered: