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.
Currently, AV1 or VP9 formats are matched regardless of the profile
parameter. This was not noticeable until browsers started advertising
multiple VP9 formats at the same time, each with a different profile
ID, in order to allow the counterpart to send different streams on the
basis of supported profiles.
This causes two issues: first, the library includes in the SDP all
formats passed by the browser, regardless of the fact that the profile
ID is registered in the API or not. Then, the library is unable to
choose the correct format for streaming, causing an intermittent
failure.
This patch fixes the matching algorithm and also covers the case in
which the profile ID is missing, by using values dictated by
specifications.
Tests were refactored since previous ones covered the same lines
multiple times.
This change adapts pion/ice to use a new interface for most network
related operations. The interface was formerly a simple struct vnet.Net
which was originally intended to facilicate testing. By replacing it
with an interface we have greater flexibility and allow users to hook
into the networking stack by providing their own implementation of
the interface.
* fix gathering for quic transport test
* quic e2e test: make sure data is received
* fix loggingFactory setup
* CI: add '-tags quic' in 'go test'
* CI: add --build-tags to golangci-lint.
* use latest pion/quic@v0.1.2
Users are unable to use the callbacks inside `internal/ice`.
Even though we alias things like OnSelectedCandidatePairChange
are unusable since in the package they use `ice.Candidate` instead of
`ICECandidate`
Fix inconsistency with error handling when we have no candidate pairs.
Before we had custom code in RTP handling that would discard errors
if it was because we had no candidate pairs. Move this logic into the
mux so we have consistent behavior with Datachannels
This can be expected and is a soft failure. Every subsystem is expected
to handle lossy communication.
Resolves#706
I made this change because I assumed godoc doesn't support
internal packages, this is not true. Godoc is actually having
issues because it doesn't support modules yet. So reverting
this change because we would prefer this be internal.
This reverts commit 8b09ced24b.
