Skip to content

fix/flush and rtp timeline follow ups - #28

Merged
dangusev merged 7 commits into
chore/crate-pathsfrom
fix/flush-and-rtp-timeline-follow-ups
Oct 13, 2026
Merged

dangusev merged 7 commits into
chore/crate-pathsfrom
fix/flush-and-rtp-timeline-follow-ups

Conversation

@dangusev

Copy link
Copy Markdown
Collaborator

Stack created with GitHub Stacks CLI • Give Feedback 💬

@dangusev
dangusev added this pull request to stack #31 October 13, 2026 14:22

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit d3c5964. Configure here.

Comment thread src/rtc/tracks/local.rs
@dangusev
dangusev force-pushed the fix/flush-and-rtp-timeline-follow-ups branch 2 times, most recently from d3c5964 to 72907b8 Compare October 13, 2026 14:54
flush took the resampler lock with a blocking lock, and a write holds that lock for the full resample: about 130 ms for a 30 s write at 24 kHz. Also, a flush that came before a write took the lock did not remove the audio of that write. A flush counter now marks the writes that started before a flush: their audio is not queued, and the write resets the filter. flush no longer waits for the resampler.
Each write path kept its own counters: the packetizer for write_pcm and write_sample, VideoEncoder.seq and VideoClock.rtp_ts for write_i420, and fwd_seq with the source timestamp for write_rtp. continue_rtp_from did not carry the forward state over. When a forwarding track took over a stopped sender, or a track took over the sender of a forwarding track, the sequence numbers jumped or went back on the same SSRC, and the receiver dropped the packets.

TrackCore now holds one RtpTimeline (last sequence number, next timestamp, forward offset) for all write paths. Packetized writes take their sequence numbers and timestamps from it. Forwarded packets keep the spacing of the source timestamps, shifted to continue the timeline. continue_rtp_from carries the timeline over and adds the time since the stop.
take_pcm read pcm_written in the middle of a tick and cleared it at the end. A write that set the flag between the two was lost, and the next tick could flush the resampler while the stream continued. take_pcm now swaps the flag to false at the start of the tick.
The track has pace off, so no pacer starts. The test itself takes the frames.
@dangusev
dangusev force-pushed the fix/flush-and-rtp-timeline-follow-ups branch from 72907b8 to 20a3935 Compare October 13, 2026 15:02
@dangusev
dangusev merged commit 8b7bdee into main Oct 13, 2026
6 of 11 checks passed
@dangusev
dangusev deleted the fix/flush-and-rtp-timeline-follow-ups branch October 13, 2026 15:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants