Skip to content

[FR] Add the scheduled sending mode for live mode sending - #3198

Draft
ethouris wants to merge 77 commits into
Haivision:devfrom
ethouris:dev-sender-schedule
Draft

ethouris wants to merge 77 commits into
Haivision:devfrom
ethouris:dev-sender-schedule

Conversation

@ethouris

@ethouris ethouris commented Aug 12, 2025 •

Copy link
Copy Markdown
Collaborator

The new scheduled sending mode should work the following way:

  1. As packets are being added to the sender buffer, the sending time will be assigned to them. The first in the schedule will get the last sending time plus interval, next ones will get sending times as calculated for the current situation, mainly basing on the current bandwidth limit, but possibly also with the current maximum availble bandwidth, if it's lower than the limit.
  2. Packet loss will be scheduled for the whole range of packets and they will be scheduled for sending with regard to maximum bandwidth and overhead.
  3. If the current schedule time for the next element is in the past, the base time is cut after exceeding 1 second ("forfeited time").

To use this mode, add the SRTO_SENDMODE option with value 1. sendmode can be used in the applications in the URI.

Development phases:

  1. Implement the scheduling mechanism. Use the m_tdSendInterval as the sending interval base and then just forfeit time exceeding 1 second. The m_tdSendInterval in case of live mode is using the "virtually unlimited" value or MAXBW can control the limit, as well as INPUTBW/OHEADBW. The "forfeit" mechanism means simply that you may potentially send packets that fast, but you don't because the packets scheduled for sending at the input (the srt_sendmsg2 calls) are sent slower than that. This means simply that packets are sent immediately, like before.
  2. Add the groupwise packet sending for the speed measurement mechanism. This should allow the application to schedule all packets "at once", just their delivery time declared in the time still holds.
  3. Add the speed measurement mechanism used for the measurement group and use it to distribute packets within the measurement group. This will dictate the times when packets should be physically sent, although their play time will be modified according to the required bandwidth.

@github-advanced-security github-advanced-security AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

Comment thread srtcore/common.h
namespace srt
{

// export import .api default;

Check notice

Code scanning / CodeQL

Commented-out code Note

This comment appears to contain commented-out code.
Comment thread srtcore/core.cpp Fixed
Comment thread srtcore/buffer_tools.h
typedef sync::steady_clock::time_point time_point;
typedef sync::steady_clock::duration duration;
CShaper (double min_tokens_capacity):
m_BurstPeriod(sync::milliseconds_from(BURSTPERIOD_DEFAULT())),

Check warning

Code scanning / CodeQL

Lossy function result cast Warning

Return value of type double is implicitly converted to signed long.
Comment thread srtcore/core.h
uint64_t basesize = m_uNumberBytes * 1000 * 1000;
uint64_t basetime = count_microseconds(diff);
if (basetime) // prevent division by 0
m_uBytesPerSecond = (forespan * m_uBytesPerSecond + (basesize / basetime))/(forespan + 1);

Check failure

Code scanning / CodeQL

Multiplication result converted to larger type High

Multiplication result may overflow 'unsigned int' before it is converted to 'unsigned long'.
Comment thread srtcore/buffer_snd.cpp
return READ_NONE;
}

// XXX unused? time_point entertime = steady_clock::now();

Check notice

Code scanning / CodeQL

Commented-out code Note

This comment appears to contain commented-out code.
Comment thread srtcore/core.cpp Fixed
ethouris-hv and others added 24 commits October 14, 2026 17:08
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Keep regular packets pending until crypto readiness and flight capacity allow timing. Let checkSndTimers drive forced refresh and retries, and wake scheduled sending on a valid crypto gate transition after releasing the connection lock.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
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.

3 participants