-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📦 Hand RTP packets directly to JanusStream #106
Conversation
7143ed9
to
caed328
Compare
Tested locally on edge and ingest nodes. I see about 0.6% dropped frames and I'm not sure why. Will test if I see the same an older commit but I suspect I will. (webrtc-internals says 0 nacks, but 30+ picture loss indicators so it might even be an issue on the decoding side) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple little nits, and a little locking concern, other than that (and your outstanding investigation on lost packets), looks good to me
Possible you're running into #101? If you're only seeing freezes and not actual packet loss. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One outstanding comment, but if it is a non-concern then we're all good!
src/JanusStream.cpp
Outdated
|
||
void JanusStream::StopRelays() | ||
{ | ||
std::lock_guard lock(mutex); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my only remaining concern, and you said something over voip about this being reasonable, so it could be that my concern is not warranted. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(concern being holding a lock while stopping every individual relay)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my justification was if this is only called when we're killing the stream, so we don't care about delaying packets. But might as well clean it up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cleaned it up with some swaps
Resolves infinite loop introduced by #106
Going back and doing ebefe00 the right way this time.
This shortens the path for RTP packets to only require a single lock at the stream level.