Done when creating a transceiver from remote description to respect
codec order preference of remote peer.
There was a recent change to include partial matches which overwrote
same codecs and also rtx was getting magled.
Change it by removing codecs from search space as matches are found so
that a codec match is applied only once.
Also, move RTX matching to separate block to ensure proper RTXes ar
matched.
#### 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
Firefox would send updated header extension
in renegotiation, e.g. publish a track without
simucalst then renegotiate second track with
simucalst, the two media secontions will have
different rtp header extensions in offer. Need
to match remote header extentions for each
media sections to avoid second track publish
failed.
Always handle header extensions from packet read
from interceptor, let interceptor has consistent
chance to process headers
Fix rtx is not negotiated when there is multiple
codecs has same mime but different profile (H264)
Fix rtx stream info missed when SSRC group attr
shows after base track's ssrc attr.
This PR addresses an issue whereby under a specific (but not unusual)
circumstance. Pion fails in two different ways to generate the correct
SDP extmap IDs for a track. Some browsers are more picky about this
than others, but Firefox is known to be picky and this issue may be
responsible for some reported incompatibilities.
Sequence to trigger the issue:
* Pion side registers audio & video codecs and audio & video header
extensions.
* Pion side gets an audio-only offer from the remote, and responds
with an answer.
* At some later point in time, Pion side wants to add a video track
and prepares a new offer.
* Extmap IDs in the new offer SDP are usually incorrect
conflicting/misassigned
Co-authored-by: Hugo Tunius <hugo@lookback.io>
Relates to: webrtc-rs/webrtc#154
The result of strconv.Atoi uses an architecture dependent bit size. It
is not safe to use when converted to an integer type of a smaller size,
without performing bounds checking.
Instead, use Parse(U)int with the desired base and size. Though this
returns a (u)int64, it can then be safely converted into a (u)int8 etc.
This change adds constants for H265 and AV1. Neither are fully
supported in pion, however these constants are still useful and we will
likely send a change to add H265 and AV1 packetizer/depacketizers in
the future.
This avoids a bug where negotiating Opus with PT 96 in an audio-only
session results in the VP8 codec being picked for a track (because
96 is the built-in type for VP8).
Two separate potential deadlocks
1. typically the locking order is SRTP first, then DataChannel.
However, when data channel is opened, it's locking srtp when
generating an ID.
It also would return without unlocking when an error is encountered
2. recursive RLock could be potentially problematic. MediaEngine
contained a section doing so.
codec has apt fmtp can't negotiation because it's
apt payloadtype can't be found in negotiation codecs.
rtx codec must be partial match if apt codec is partial.
Was reverted in eeb67e1Fixes#1785
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.
If an API is shared between PeerConnections they would use the same
MediaEngine. A MediaEngine contains negotiated PayloadTypes so if the
PeerConnections were answering you would end up in invalid states.
Add DisableMediaEngineCopy to SettingEngine in case user needs old
behavior.
Resolves#1662
