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
This PR addresses an issue where calling RTPSender.ReplaceTrack with
a nil parameter on a sender with more than 1 encoding (simulcast) would
only cause the 1st encoding to be unbound, breaking common publisher
reconnection workflows with simulcast enabled.
Introduces AddEncoding method in RTP sender to add simulcast encodings.
Added UTs for AddEncoding.
Also modified the Simulcast send test to use the new API.
If PeerConnection removes track while RTPSender is
created and being negotiated, RTPSender.Send would
access nil pointer. Check If track is nil.
Relates to #2065
If a RTPSender doesn't have a track currently set and GetParameters is
called we would call a method on a nil pointer. Now instead of checking
the Track kind we store the kind in the RTPSender.
Resolves#2065
Read + Discard packets from the Simulcast repair stream. When a
Simulcast stream is enabled the remote will send packets via the repair
stream for probing. We can't ignore these packets anymore because it
will cause gaps in the feedback reports
Resolves#1957
This gives an option to raise the receive MTU as SettingEngine option.
If SettingEngine has not been set the MTU, then default value is used
instead, 1460
Resolves#1925
ReadDeadline is supported by RTPReceiver but not RTPSender. This
commit attempts to provide similar method for RTPSender.
If SetReadDeadine is called with:
- an empty time.Time: it will clear all previous set deadline.
- a non-empty time.Time: it will abort all pending "ReadRTCP" calls if
the specified time is up.
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
* Return error to user when remote doesn't support codecs
* Assert that bindings are properly incremented/decremented
* Assert that a added track doesn't error even when disconnected
Relates to #1526
Only start senders that were negotiated.
Since `startTransports`/`startRenegotiation` start rtp senders in a
goroutine, an user could call AddTrack/Add*Transceiver/RemoveTrack
causing a not negotiated sender track ssrc to be started.
You should use Track instead to send packets. This is
exposed because pion/webrtc currently provides no way
for users to send RTP packets directly. This is makes
users unable to send retransmissions to a single RTPSender.
in /v3 this will go away, only use this API if you really need it.
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
Writing to a Track shouldn't return errors for an individual
RTPSender. This filters ErrNoCandidatePairs from being returned
and instead just returns nil
Resolves#523
Resolves#478. Adds minimal JavaScript/WASM bindings. This makes it
possible to compile core parts of pions/webrtc to WASM and run it in the
browser. Only data channels are supported for now and there is
limited/no support for certificates and credentials.
