Skip to content

Conversation

@boks1971
Copy link
Contributor

@boks1971 boks1971 commented Dec 5, 2025

No description provided.

rtpreceiver.go Outdated
r.mu.Lock()
defer r.mu.Unlock()

select {
Copy link
Member

Choose a reason for hiding this comment

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

Can you use haveClosed instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will change.

rtcpReadStream *srtp.ReadStreamSRTCP,
rtcpInterceptor interceptor.RTCPReader,
) error {
r.mu.Lock()
Copy link
Member

Choose a reason for hiding this comment

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

Can you use haveClosed instead?

}

if rsid != "" {
receiver.mu.Lock()
Copy link
Member

Choose a reason for hiding this comment

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

If you use the atomic do you still need locking changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I just moved the lock inside. Yeah, there are more internal state like tracks in RTPReceiver which needs locking. Not sure why the lock was not internal and called from peerconnection.go. Seemed like a good thing to move it inside.

@Sean-Der
Copy link
Member

Sean-Der commented Dec 5, 2025

@boks1971 is it possible to get a test/reproduce for this behavior?

@boks1971 boks1971 force-pushed the raja_closed_receiver branch 2 times, most recently from a5ebe77 to 74e9cb7 Compare December 5, 2025 15:44
@boks1971
Copy link
Contributor Author

boks1971 commented Dec 5, 2025

@boks1971 is it possible to get a test/reproduce for this behavior?

Unfortunately, I do not have a specific repro. Happens in production in a larg(ish) call (40 - 50 participants) and they are subscribing to 60 - 80 tracks each and they are connecting from possibly poorer networks.

I have been trying to get a definitive proof, but also looking all around for possible places. This one seemed like one possible option as a lot of objects created by buffer factory are leaking.

@boks1971 boks1971 force-pushed the raja_closed_receiver branch from 74e9cb7 to 33bc145 Compare December 5, 2025 17:38
@boks1971 boks1971 force-pushed the raja_closed_receiver branch from 33bc145 to 29bf0af Compare December 5, 2025 17:39
@codecov
Copy link

codecov bot commented Dec 5, 2025

Codecov Report

❌ Patch coverage is 76.47059% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.18%. Comparing base (62f6101) to head (d524fcf).
⚠️ Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
rtpreceiver.go 76.47% 2 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3290      +/-   ##
==========================================
- Coverage   84.31%   84.18%   -0.13%     
==========================================
  Files          80       80              
  Lines        9141     9155      +14     
==========================================
  Hits         7707     7707              
- Misses       1017     1025       +8     
- Partials      417      423       +6     
Flag Coverage Δ
go 84.18% <76.47%> (-0.13%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants