Fix: always use sampling instant (epoch) for RTP timestamp#1491
Merged
DawidWesierski4 merged 7 commits intomainfrom Apr 14, 2026
Merged
Fix: always use sampling instant (epoch) for RTP timestamp#1491DawidWesierski4 merged 7 commits intomainfrom
DawidWesierski4 merged 7 commits intomainfrom
Conversation
DawidWesierski4
force-pushed
the
vrx_issues
branch
2 times, most recently
from
5a9d022 to
2720ba6
Compare
DawidWesierski4
requested review from
awilczyns,
moleksy,
soopel and
staszczuk
as code owners
DawidWesierski4
force-pushed
the
vrx_issues
branch
from
d350464 to
16c4818
Compare
Always derive the RTP timestamp from the frame epoch (N x TFRAME) instead of conditionally using the pacing cursor (ptp_time_cursor). Per ST 2110-20, the RTP timestamp of a frame shall represent a point in time of N x TFRAME and shall not exceed +/- TFRAME from the most recent N x TFRAME. This applies under mediaclk:direct and the regular increment provisions of section 7.6.1. Previously, epoch-based timestamping was opt-in via ST20_TX_FLAG_RTP_TIMESTAMP_EPOCH; now it is unconditional in the common path (tv_update_rtp_time_stamp). Flag will only affect user timestmaping from now on. Remove the LATENCY_COMPENSATION pad-packet mechanism from the rate-limiter warm-up path. The extra packets were added to mask a superficial negative-latency artefact caused by the gap between ptp_time_cursor and the true epoch; with epoch-based timestamps this compensation is no longer needed. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The rate-limiter warm-up phase sends pad packets before the first real data packet, introducing a small delay between the scheduled TX start time and the actual first packet on the wire. When the RTP timestamp is derived from ptp_time_cursor (the TX start time), the receiver sees packets arriving later than the timestamp suggests, appearing as positive latency. Add rl_rtp_offset_ns to struct st_tx_video_pacing: a small constant shift of 3 * TRS (three packet intervals) applied only when RL pacing is active. This is added to the RTP timestamp alongside delta_ns, aligning the timestamp closer to when the first data packet actually hits the wire after warm-up completes. The field is initialized to 0 during pacing init and only set to 3 * TRS when the primary port uses ST21_TX_PACING_WAY_RL, so non-RL pacing modes (TSC, TSN, BE, PTP) are unaffected. Revert the unconditional epoch-based RTP timestamp from the previous commit back to the flag-gated behavior, as the full tr_offset shift introduced too much latency. The RL-only 3-packet adjustment is a minimal targeted fix. Fixes: 1d4779197950075c241ab9fdd8e5b5251a273e65 Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Latency compensation increase to adjust for high fps sessions. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Use uint64_t for rl_rtp_offset_ns to avoid float-to-int casts.
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The RL pacing warm-up compensation was computed in nanoseconds and subtracted from the TAI time before converting to media-clock ticks. This caused rounding errors for fractional frame rates like 1080i59, where the ns-domain subtraction could land on a tick boundary and produce repeated or skipped RTP timestamps. Convert the offset to media-clock ticks directly. Also document the truncation-toward-zero requirement for callers that derive TAI timestamps from rational frame periods (see issue #1321).
DawidWesierski4
force-pushed
the
vrx_issues
branch
from
25499a6 to
f704f5a
Compare
Sakoram
approved these changes
Apr 14, 2026
Collaborator
Author
We can confidently say this improves the one core performance rapidly. Here is an example where there were 20 sessions on ONE core when running compliance
|
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.
Always derive the RTP timestamp from the frame epoch (N x TFRAME) instead of conditionally using the pacing cursor (ptp_time_cursor).
Per ST 2110-20, the RTP timestamp of a frame shall represent a point in time of N x TFRAME and shall not exceed +/- TFRAME from the most recent N x TFRAME. This applies under mediaclk:direct and the regular increment provisions of section 7.6.1.
Previously, epoch-based timestamping was opt-in via ST20_TX_FLAG_RTP_TIMESTAMP_EPOCH; now it is unconditional in the common path (tv_update_rtp_time_stamp). Flag will only affect user timestmaping from now on.
Remove the LATENCY_COMPENSATION pad-packet mechanism from the rate-limiter warm-up path. The extra packets were added to mask a superficial negative-latency artefact caused by the gap between ptp_time_cursor and the true epoch; with epoch-based timestamps this compensation is no longer needed.