Repository navigation
1.3.0 - #8
Open
balazskreith wants to merge 9 commits into
Open
1.3.0#8balazskreith wants to merge 9 commits into
balazskreith wants to merge 9 commits into
Conversation
- Introduced SinkRegistry to manage per-client sinks, allowing for better lifecycle management and unique identification of sinks across observers. - Replaced createClientSink with createClientJsonlSink for writing client samples to JSONL files, enhancing file management and simplifying the API. - Updated Observer to utilize the new sink management system, ensuring sinks are created and managed under the appropriate client IDs. - Refactored existing sinks (ClientSampleSink, JsonlFileSink, InMemorySink) to implement a unified Sink interface, improving consistency and extensibility. - Added tests for the new sink management features, ensuring proper functionality and integration within the Observer.
…bservedMediasoupRouter
…oning and changelog management
- Replaced `createClientJsonlSink` with `createClientSink` in ObserverConfig to allow returning either a JSONL file path or a custom sink. - Updated ObservedCall to create client sinks based on the new configuration, ensuring unique sink IDs and proper handling of existing sinks. - Modified event emissions to reflect the new sink creation logic. - Adjusted tests to validate the new sink creation behavior and ensure proper functionality with existing and new clients.
…r-client sample handling
…diaStreamTrack When a producer is recreated with the same MediaStreamTrack (e.g. after a reconnection, or after toggling audio processing), the new RTCRtpSender reports a new media-source stat and new outbound-rtp stats with the same trackIdentifier. The client keeps reporting the old ones too, with frozen counters. ObservedOutboundTrack is keyed by track id and captured its media source and outbound RTPs once, at creation. After a republication it therefore stayed linked to the old, frozen stats for the rest of the call: - bitrate, deltaPacketsSent, remoteFractionLost, remoteRttInMs and the degradation reasons were computed from the frozen RTPs (typically reporting no-packets-sent), and rmsAudioLevel from the frozen source; - UnconsumedTrackDetector and the P2P remote track resolver read getOutboundRtps(), i.e. the old SSRCs; - the remote track resolver kept the track indexed under its original producerId, so consumers of the new producer never linked to it. Re-linking the media source and RTPs on every update would fix the stats but silently change what an ObservedOutboundTrack stands for: its producerId / SSRC key would change under an existing pairing, and its detectors would span two publications. Pairing is bound to the producer, not to time, so a republication is treated as a new track object instead. Changes: - ObservedPeerConnection: on each outbound track update, take the newest media source with the track's trackIdentifier (the last one added; Maps keep insertion order). If it differs from the track's media source, the existing object is removed (outbound-track-removed) and a new ObservedOutboundTrack with the same id, bound to the new media source, is added (outbound-track-added). Removal goes through one helper shared with the sweep of tracks the client stopped reporting. - ObservedOutboundTrack: the media source is fixed for the object's life; getOutboundRtps() looks up the RTPs of that media source on every call, so RTPs that appear after the track (e.g. a simulcast layer starting later) are included too. - RemoteTrackResolver: store the publisher id each outbound track was indexed under and remove by it, instead of re-resolving at removal. A track whose producerId changed in place no longer leaves its old entry behind. Behaviour change: after a republication, a reference held to the old ObservedOutboundTrack points at a removed object. Look tracks up by id. The stale media source and RTPs stay in the peer connection's maps while the client reports them, but no track links to them any more. Tests (tests/outboundTrackRepublish.spec.ts): - republication yields a new object with the new media source and SSRC, computes deltaPacketsSent from the live RTP, and emits one removed and one added event; - no replacement while the media source stays the same, and a later RTP of the same source is included; - a first media source appearing after the track replaces the object; - consumers re-pair by producerId: P1 is released, P2 links to the new object; - removal releases the indexed publisher id even after the producerId changed in place (fails without the resolver change). Reported-by: Alessio Bazzica
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.