With Read and ReadExtended waiting (they are two different goroutines),
use Broadcast always. In theory, they both should not be waiting at the
same time, but just being safe.
* Do not use LastTS for dummy offset.
LastTS could be random when using dummy start. That should not be used
in calculating offsets.
Also, do not push padding into sequence before init. Could have heppened
with dummy start.
* apply dummy offset before comparing to last
* refresh ref TS
* initialize codec munger on catch up forwarding
* Simplify time stamp calculation on switches.
Trying to simplify time stamp calculation on restarts.
The additional checks take effect rarely and it not worth the extra
complication.
Also, doing the reference time stamp in extended range.
The challenge with that is when publisher migrates the extended
timestamp could change post migration (i. e. post migration would not
know about rollovers). To address that, maintain an offset that is
updated on resync.
* WIP
* Revert to resume threshold
* typo
* clean up
## Changelog
This release changes the default behavior when creating or updating WHIP
ingress. WHIP ingress will now default to disabling transcoding and
forwarding media unchanged to the LiveKit subscribers. This behavior can
be changed by using the new `enable_transcoding` available in updated
SDKs. The behavior of existing ingresses is unchanged.
### Added
- Add support for "abs-capture-time" extension. (#2640)
- Add PropagationDelay API to sender report data (#2646)
- Add support for EnableTranscoding ingress option (#2681)
- Pass new SIP metadata. Update protocol. (#2683)
- Handle UpdateLocalAudioTrack and UpdateLocalVideoTrack. (#2684)
- Forward transcription data packets to the room (#2687)
### Fixed
- backwards compatability for IsRecorder (#2647)
- Reduce RED weight in half. (#2648)
- add disconnected chan to participant (#2650)
- add typed ops queue (#2655)
- ICE config cache module. (#2654)
- use typed ops queue in pctransport (#2656)
- Use the ingress state updated_at field to ensure that out of order RPC do not overwrite state (#2657)
- Log ICE candidates to debug TCP connection issues. (#2658)
- Debug logging addition of ICE candidate (#2659)
- fix participant, ensure room name matches (#2660)
- replace keyframe ticker with timer (#2661)
- fix key frame timer (#2662)
- Disable dynamic playout delay for screenshare track (#2663)
- Don't log dd invalid template index (#2664)
- Do codec munging when munging RTP header. (#2665)
- Connection quality LOST only if RTCP is also not available. (#2670)
- Handle large jumps in RTCP sender report timestamp. (#2674)
- Bump golang.org/x/net from 0.22.0 to 0.23.0 (#2673)
- do not capture pointers in ops queue closures (#2675)
- Fix SubParticipant twice when paticipant left (#2672)
- use ttlcache (#2677)
- Detach subscriber datachannel to save memory (#2680)
- Clean up UpdateVideoLayers (#2685)
- Make datachannel optional for publisher (#2686)
* Handle UpdateLocalAudioTrack and UpdateLocalVideoTrack.
- Update the TrackInfo
- NOTE: populating Stereo and DisableDtx fields although there are
features now.
- The audio features in UpdateLocalAudioTrack is applied as is,
i. e. the update has the latest set of features.
- Emits a track update which will broadcast a participant update.
TODO:
-----
- Telemetry event with track update?
* update deps
* Handle large jumps in RTCP sender report timestamp.
Seeing cases of RTCP Sender Report spaced apart by more than half the
RTP Timestamp range. Maybe a case of laptop going to sleep and waking
up. Handle it using time diff from last report and calculating expected
timestamp.
* try go 1.22
* Connection quality LOST only if RTCP is also not available.
It is possible that sender stops all layers of video due to some
constraint (CPU or bandwidth). Packet reception going dry due to
that should not trigger `LOST` quality.
Add last received RTCP time also to distinguish the case
of real `LOST` and sender stopping traffic.
Some bits to watch for
- With audio, RTCP reports could be more than 5 seconds apart (5 seconds
is the default interval for connection quality scorer), but audio
senders usually send silence packets even when there is no input.
So audio completely stopping can be considered `LOST`.
- With video, have to observe if all clients continue to send RTCP even
if all layers are stopped.
- RTCP bandwidth is not supposed to exceed the primary stream bandwidth.
libwebrtc calculates that and spaces out RTCP reports accordingly.
That is the reason why audio reports are that far apart. If a video
stream is encoded at a very low bit rate, it could also be sending
RTCP rarely. So, there is the case of LOST being indistinguishable
from sender stopping all layers. But, this should be a rare case.
* typo
* Do codec munging when munging RTP header.
It was possible for probe packets to get in between RTP munging and
codec munging and throw off sequence number while dropping packets.
Affected only VP8 as it does codec munging.
* do not pass in buffer as it is created anyway
* flip fields
* flip order
* fix test
* call translate for all tracks
* simplify
If the first packet of keyframe has template structure is lost then
subsequent packets rely on it will report invalid tempalte error which
is expected.
