FirebaseRTC
FirebaseRTC copied to clipboard
webrtc
peerconnection ontrack handler is a bad example
as pointed out on stackoverflow the code used here does not work in Safari.
The code is adding remote tracks to a locally created stream which is initially empty. That is non-canon and a bad example.
cc @youennf
Adding a remote track to a locally created stream should work. This seems like a Safari bug.
There's an impedance mismatch between tracks & srcObject so it depends on the app.
The spec example shows a simple case, but it assumes a stable stream association:
pc.ontrack = ({track, streams}) => {
// once media for a remote track arrives, show it in the remote video element
track.onunmute = () => {
// don't set srcObject again if it is already set.
if (remoteView.srcObject) return;
remoteView.srcObject = streams[0];
};
};
But there's lots to watch out for. track events
- fire per track obviously (though on settled state on the same run of the event loop)
- may have zero or more stream associations
- may fire before media arrives
- may fire due to direction changes (
transceiver.direction = "sendrecv") - may fire due to stream association changes (
sender.setStreams([...newstreams])
As @youennf mentions stream.addTrack() should work, but unless you're careful, may leave you with multiple tracks of the same kind on renegotiation, and wondering why a video element is still showing the original track.
Another factor to consider is whether to use your own new MediaStream or rely on the one managed by RTCPeerConnection (surfaced in the streams event property) (the latter will automatically remove/add the track based on direction changes, the former will not).
We keep telling ourselves people want more powerful/lower level APIs, but I wonder how true it is.
We keep telling ourselves people want more powerful/lower level APIs, but I wonder how true it is.
The target audience for the code lab are novice developers (at least regarding WebRTC). Thus it is aok to make assumptions that might not hold true for every real-world situation.
@jan-ivar How about updating the codelab with the example similar to that in the spec as you showed?
The target audience for the code lab are novice developers
which means that you must be extra careful not to teach bad patterns (see also the samples issue). Why was this clearly not reviewed internally by experts on the matter?
@jan-ivar what would this routine (peerConnection) look like if it referenced the RTCPeerConnection instead of adding tracks to the empty local stream? I imagine that the streams value would need to be pulled out earlier and then referenced ...
