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
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
Instead of having logic in pion/webrtc and pion/sdp move all logic to
pion/ice. Users of pion/ice don't want to import these packages to use
basic pion/ice functionality.
Formatting parameters are not only allowed on video
codecs but also on most audio codecs. Without this change,
custom parameters of audio codecs would be dropped when
parsing SDPs (e.g. opus parameters)
This causes users who use PopulateFromSDP to declare
they support transport-cc. Since they don't send receiver
reports. They will get a degraded experience unexpectedly.
Partially revert ce8de088e7.
Resolves#1026
