- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2019 12:46:48 +0000
- To: public-webrtc-logs@w3.org
The codec isn't a property of a frame, but WebRTC doesn't know the codec until it received RTP packets with encoded frames. WebRTC will give you remote tracks before codecs have been negotiated. Here's how it works: - If a transceiver is created, a receiver is also created, which has a track. This can happen whether or not we ever intend to use this track: a transceiver can be created by calling addTransceiver(), this is even prior to negotiation, or it can be created due to processing an offer, which is half-way through negotiation (whether or not we intend to receive on it). Processing an offer can trigger ontrack, but it's too early to know its codec. Receivers can exist because we are willing to receive something after negotiating, or they can be dummy objects that are never used. - Regardless how the "receiving track" was created, it is always muted by default. - At some point in time we complete negotiation. The track is still muted. At this point we know which codecs are allowed (a list of codecs) and we have to have the necessary decoders available in case incoming data arrives. But we don't know which of the codecs the other endpoint actually decides to use. - RTP packets arrive to the receiver! Hurray! We unmute the track and NOW we know which codec is used, because we can tell by inspecting the RTP packets. - (On the fly the RTP stream could change to a different codec that was negotiated and we have to be prepared for this. In terms of recording, we could either start re-encoding or we could fail recording.) -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/139#issuecomment-535485993 using your GitHub account
Received on Thursday, 26 September 2019 12:46:49 UTC