-
Notifications
You must be signed in to change notification settings - Fork 861
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
Updated the documentation about latency and transtype #2875
Updated the documentation about latency and transtype #2875
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2875 +/- ##
==========================================
+ Coverage 66.99% 67.07% +0.08%
==========================================
Files 103 103
Lines 20460 20460
==========================================
+ Hits 13707 13724 +17
+ Misses 6753 6736 -17 ☔ View full report in Codecov by Sentry. |
docs/features/latency.md
Outdated
The goal of the latency (TSBPD) mechanism | ||
========================================= | ||
|
||
The strict goal of this mechanism is to have the time distance between two | ||
consecutive packets on the receiver side identical as they were at the | ||
sender side. Obviously this requires some extra delay defined from upside | ||
that should define when exactly the packet can be retrieved by the receiver | ||
application, and if the packet arrived earlier than this time, it will have to | ||
wait in the receiver buffer until this time comes. This time for the packet N | ||
is roughly defined as: | ||
|
||
``` | ||
PTS[N] = ETS[N] + LATENCY(option) | ||
``` | ||
|
||
where `ETS[N]` is the time when the packet would arrive, if all delays | ||
from the network and the processing software on both sides are identical | ||
as they were for the very first received data packet. This means that | ||
for the very first packet `ETS[0]` is equal to this packet's arrival time. | ||
For every next packet the delivery time distance should be equal to the same | ||
packet's declared scheduling time distance. |
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.
The goal of the latency (TSBPD) mechanism | |
========================================= | |
The strict goal of this mechanism is to have the time distance between two | |
consecutive packets on the receiver side identical as they were at the | |
sender side. Obviously this requires some extra delay defined from upside | |
that should define when exactly the packet can be retrieved by the receiver | |
application, and if the packet arrived earlier than this time, it will have to | |
wait in the receiver buffer until this time comes. This time for the packet N | |
is roughly defined as: | |
``` | |
PTS[N] = ETS[N] + LATENCY(option) | |
``` | |
where `ETS[N]` is the time when the packet would arrive, if all delays | |
from the network and the processing software on both sides are identical | |
as they were for the very first received data packet. This means that | |
for the very first packet `ETS[0]` is equal to this packet's arrival time. | |
For every next packet the delivery time distance should be equal to the same | |
packet's declared scheduling time distance. | |
The goal of the latency (TSBPD) mechanism | |
========================================= | |
SRT employs a TimeStamp Based Packet Delivery (TSBPD) mechanism | |
with strict goal of keeping the time interval between two consecutive packets | |
on the receiver side identical to what they were at the sender side. This | |
requires introducing an extra delay that should define when exactly the packet | |
can be retrieved by the receiver application -- if the packet arrives early, it must | |
wait in the receiver buffer until the delivery time. This time for a packet N | |
is roughly defined as: | |
PTS[N] = ETS[N] + LATENCY(option)
where `ETS[N]` is the time when the packet would arrive, if all delays
from the network and the processing software on both sides are identical
to what they were for the very first received data packet. This means that
for the very first packet `ETS[0]` is equal to this packet's arrival time.
For every following packet the delivery time interval should be equal to the that
packet's declared scheduling time interval.
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 made several edits to the text. Please review for technical accuracy.
(first portion) Co-authored-by: stevomatthews <smatthews@haivision.com>
(completed) Co-authored-by: stevomatthews <smatthews@haivision.com>
(doc review, finished) Co-authored-by: stevomatthews <smatthews@haivision.com>
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.
To use a consistent style.
Co-authored-by: Maxim Sharabayko <maxlovic@gmail.com>
SRTO_TRANSTYPE
option (per a complaint that the order of setting options matters).SRTO_RCVLATENCY
option as thefeatures/latency.md
document explains it better and in more details.