Add dedicated-thread method for video sending rate control to improve video latency#4332
Merged
Add dedicated-thread method for video sending rate control to improve video latency#4332
Conversation
sauwming
approved these changes
Mar 4, 2025
nanangizz
added a commit
that referenced
this pull request
Mar 6, 2025
To fix & minor enhance #4332: - Fix sending time calculation, the total sent should be updated in each queuing packet. - Protect stream pool usage using group lock. - Minor optimization: faster buffer reuse to avoid too many buffers, skip printing trace log for sending RTP when there is no packet to send.
nanangizz
added a commit
that referenced
this pull request
Mar 6, 2025
To fix & minor enhance #4332: - Fix sending time calculation, the total sent should be updated in each queuing packet. - Protect stream pool usage using group lock. - Minor optimization: faster buffer reuse to avoid too many buffers, skip printing trace log for sending RTP when there is no packet to send.
BarryYin
pushed a commit
to BarryYin/pjproject
that referenced
this pull request
Feb 3, 2026
BarryYin
pushed a commit
to BarryYin/pjproject
that referenced
this pull request
Feb 3, 2026
To fix & minor enhance pjsip#4332: - Fix sending time calculation, the total sent should be updated in each queuing packet. - Protect stream pool usage using group lock. - Minor optimization: faster buffer reuse to avoid too many buffers, skip printing trace log for sending RTP when there is no packet to send.
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
2 participants
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.
Currently, by default, video RTP sending rate control is using simple blocking method or
PJMEDIA_VID_STREAM_RC_SIMPLE_BLOCKING. This method seems to introduce significant latency compared toPJMEDIA_VID_STREAM_RC_NONE. So this PR implements an alternative method to avoid the latency impact while still applying the sending rate control by using a dedicated-thread for sending video RTP packets. Moreover, this alternative method will not block the stream'sput_frame()invoker. Currently, each video stream will have a dedicated thread.In #4325, we try to measure the delay between audio & video playbacks (audio is usually played first). When making video call to self using pjsua app, the delay with
PJMEDIA_VID_STREAM_RC_NONEmethod is about 200-400ms while withPJMEDIA_VID_STREAM_RC_SIMPLE_BLOCKINGmethod is 500-1000ms. WithPJMEDIA_VID_STREAM_RC_SEND_THREADthe delay seems to be similar toPJMEDIA_VID_STREAM_RC_NONE. So I think it is a good idea to make this the default rate control method.Also in this PR, move the copying stream info to before media transport attach, as when testing this patch, I saw occasional crash in
on_rx_rtp()due to accessing uninitialized stream info.