Recently added filtering out unattached RTX in SetCodecPrefrences.
Turns out it is needed in `getCodecs()` also in the following
scenario
- AddTrack from answer side adds a tracks and has media engine codecs
- An offer is received and negotiated codecs get updated in
media engine. And this does not have one of the codecs added
AddTrack above (default media engine codecs)
- Generate answer will do `getCodecs` which will filter out
the codec missing from the `offer`, but would have let the
corresponding RTX pass through and get added to the answer.
While adding transceivers from SetRemoteDescription,
the filtered codecs could filter out the primart codec
and leave the RTX codec in. Generating an answer with
that fails `SetRemoteDescription` on remote peer due
to an unrecognisable codec. Fix it by filtering out
RTX is primary is not there.
#### Description
Before this, any interceptor that tries to read FEC payload type from
`info *interceptor.StreamInfo`, always gets 0. This PR implements the
logic to find FEC payload type.
Also, MimeType consts are moved from mediaengine.go to mimetype.go,
since mediaengine.go is not included in the WASM build.
Currently codecs are matched regardless of the clock
rate and the channel count, and this makes impossible to fully support
codecs that might have a clock rate or channel count different than the
default one, in particular LPCM, PCMU, PCMA and multiopus (the last one
is a custom Opus variant present in the Chrome source code to support
multichannel Opus).
For instance, let's suppose a peer (receiver) wants to receive an audio
track encoded with LPCM, 48khz sample rate and 2 channels. This receiver
doesn't know the audio codec yet, therefore it advertises all supported
sample rates in the SDP:
```
LPCM/44100
LPCM/48000
LPCM/44100/2
LPCM/48000/2
```
The other peer (sender) receives the SDP, but since the clock rate and
channel count are not taken into consideration when matching codecs, the
sender codec `LPCM/48000/2` is wrongly associated with the receiver
codec `LPCM/44100`. The result is that the audio track cannot be decoded
correctly from the receiver side.
This patch fixes the issue and has been running smoothly in MediaMTX for
almost a year.
Unfortunately, in lots of examples and tests, clock rate and/or channels
are not present (and in fact they are producing horrible SDPs that
contain `VP8/0` instead of `VP8/90000` and are incompatible with lots of
servers) therefore this new check causes troubles in existing code. In
order to maintain compatibility, default clock rates and channels are
provided for most codecs.
In the future, it might be better to update examples (i can do it in a
future patch) and remove the exception.
Update MediaEngine codec creation to take into account remote
and local rtcp-fb. Before we would incorrectly always take
the remote rtcp-fb and ignore local.
Resolves#2943Resolves#2944Resolves#1968
If the MediaEngine contains support for them a SSRC will be generated
appropriately
Co-authored-by: aggresss <aggresss@163.com>
Co-authored-by: Kevin Wang <kevmo314@gmail.com>
Resolves#1989Resolves#1675
Exact match if fmtp parameters are not inconsistent.
e.g. default OPUS fmtp of the browsers are:
Chrome: minptime=10;useinbandfec=1
Firefox: maxplaybackrate=48000;stereo=1;useinbandfec=1
They should be treated as matched.
RegisterHeaderExtension now allows users to enable headers depending on
the type of transceiver that was created.
Also expose GetParameters on RTPSender and RTPReceiver
Co-authored-by: OrlandoCo <luisorlando.co@gmail.com>
Resolves#1554
