@3dsource/angular-unreal-module 0.0.184 → 0.0.186
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -941,13 +941,26 @@ type SignalingRetryKind = 'ws-retry' | 'connect' | 'orchestration' | 'region-cyc
|
|
|
941
941
|
* rtt) over one aggregation window (5 s, ~20 samples at 250 ms).
|
|
942
942
|
*
|
|
943
943
|
* - `p50` — the typical tick; robust to outliers, primary dashboard signal.
|
|
944
|
-
* - `p95` — the bad tail
|
|
944
|
+
* - `p95` — the bad tail where HIGH is bad (rtt, jitter, qp).
|
|
945
|
+
* - `p05` — the bad tail where HIGH is good (fps, bitrate). Consumers need a
|
|
946
|
+
* robust low end, and `min` cannot serve: it is a single tick, so one
|
|
947
|
+
* dropped frame defines the window. Sent for every metric so the shape
|
|
948
|
+
* stays uniform; only fps and bitrate have a reason to read it.
|
|
949
|
+
*
|
|
950
|
+
* All three percentiles use linear interpolation between order statistics
|
|
951
|
+
* (type 7), matching the consumer's `percentile()` so the word means one
|
|
952
|
+
* thing across both repos.
|
|
945
953
|
* - `min` — worst single tick (freeze detection).
|
|
946
954
|
* - `max` — best single tick (did we ever reach the target?).
|
|
955
|
+
*
|
|
956
|
+
* Every field is a percentile of the SAME window, so a consumer may compare
|
|
957
|
+
* them to each other — but must never average them across windows to obtain
|
|
958
|
+
* a population percentile.
|
|
947
959
|
*/
|
|
948
960
|
interface WindowAggregate {
|
|
949
961
|
readonly p50: number;
|
|
950
962
|
readonly p95: number;
|
|
963
|
+
readonly p05: number;
|
|
951
964
|
readonly min: number;
|
|
952
965
|
readonly max: number;
|
|
953
966
|
}
|
|
@@ -1116,6 +1129,27 @@ interface SampleData extends TelemetryEventEnvelope {
|
|
|
1116
1129
|
readonly jitter: WindowAggregate;
|
|
1117
1130
|
readonly rtt: WindowAggregate;
|
|
1118
1131
|
readonly packetsLost?: number;
|
|
1132
|
+
/**
|
|
1133
|
+
* Bytes the video stream delivered DURING this window — how far
|
|
1134
|
+
* `inbound-rtp.bytesReceived` moved since the previous window closed, not a
|
|
1135
|
+
* running total.
|
|
1136
|
+
*
|
|
1137
|
+
* What turns a bandwidth figure on the receiving end into a measurement.
|
|
1138
|
+
* Volume needs the window's MEAN bitrate; {@link bitrate} carries
|
|
1139
|
+
* p50/p95/min/max and no mean, so without this a consumer has to work the
|
|
1140
|
+
* volume out from the median — which runs low on a stream that spikes at
|
|
1141
|
+
* every keyframe.
|
|
1142
|
+
*
|
|
1143
|
+
* A delta rather than the cumulative counter on purpose: a cumulative value
|
|
1144
|
+
* is only usable if the previous sample survived the trip, so one dropped
|
|
1145
|
+
* POST would move bytes silently into the next window.
|
|
1146
|
+
*
|
|
1147
|
+
* Omitted when the counter is missing or went backwards (a renegotiation
|
|
1148
|
+
* restarts it) — see `CounterWindow`. A consumer reads the gap as "estimate
|
|
1149
|
+
* this window from the bitrate", which is the honest reading; it must never
|
|
1150
|
+
* treat a missing value as zero bytes.
|
|
1151
|
+
*/
|
|
1152
|
+
readonly bytes?: number;
|
|
1119
1153
|
readonly viewPort: {
|
|
1120
1154
|
readonly width?: number;
|
|
1121
1155
|
readonly height?: number;
|