ambiser
/
openvidu
mirror of https://github.com/OpenVidu/openvidu.git
9
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

openvidu-test-e2e: update TODO comment of OpenViduTestAppE2eEgressProTest.java

chore/update-openvidu-actions-1.0.25
pabloFuente 2026-10-29 01:09:31 +01:00
parent 205335469a
commit dfb7f6aa21
1 changed files with 16 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
openvidu-test-e2e/src/test/java/io/openvidu/test/e2e/OpenViduTestAppE2eEgressProTest.java
View File

@ -182,10 +182,17 @@ public class OpenViduTestAppE2eEgressProTest extends AbstractOpenViduTestappE2eT
// milliseconds, the sync engine keeps rebuilding its audio estimate and the // milliseconds, the sync engine keeps rebuilding its audio estimate and the
// offset wobbles some 15 ms. A track the trouble left misplaced is off by far // offset wobbles some 15 ms. A track the trouble left misplaced is off by far
// more (4.6 s, before the sync engine was set to keep capture times) // more (4.6 s, before the sync engine was set to keep capture times)
// TODO: this will be fixed when upgrading mediasoup to 3.27.0 or later: its // Checked with mediasoup 3.32.0 (sender reports in microseconds since 3.27.0,
// sender reports carry microseconds (PR #1918), so the sync engine should stop // PR #1918): the rebuilds remain, every 10-30 s on the audio track (19
// rebuilding its audio estimate every 10-30 s, and the wobble with it (needs a // rebuilds and 111 rejected reports over the 4 outage/jitter/congestion tests,
// mediasoup-go that speaks the 3.27 worker protocol) // against 24 and 144 with 3.26.0, and 8 and 55 with LiveKit's SFU, which
// rebuilds every 30-40 s). The reports are not quantized any more, but
// the capture instant the worker maps them to is the median of a 7-sample
// window of the publisher's own sender reports (RemoteClockOffsetEstimator),
// which steps by their arrival jitter every ~1 s, and the sync engine rejects
// any report over 3 sigma (0.1 ms floor) off its fit. Not fixable by a
// mediasoup release: it would take a smoother offset in the worker or a more
// tolerant estimator in server-sdk-go. So the median stays.
private static final double HEALED_AV_TOLERANCE_MS = 70; private static final double HEALED_AV_TOLERANCE_MS = 70;
// Packets lost from the SFU to the egress: more than NACKs recover, so frames are // Packets lost from the SFU to the egress: more than NACKs recover, so frames are
// lost for good // lost for good
@ -214,11 +221,11 @@ public class OpenViduTestAppE2eEgressProTest extends AbstractOpenViduTestappE2eT
// track is on its arrival times when the client sends what it queued, which // track is on its arrival times when the client sends what it queued, which
// places that burst late, and the error, up to 0.5 s with mediasoup, is then // places that burst late, and the error, up to 0.5 s with mediasoup, is then
// absorbed at 5 ms/s // absorbed at 5 ms/s
// TODO: this will be fixed when upgrading mediasoup to 3.27.0 or later: its // Checked with mediasoup 3.32.0: the sync engine still rebuilds an estimate
// sender reports carry microseconds (PR #1918), so the sync engine should seldom // every 10-30 s on mediasoup (see HEALED_AV_TOLERANCE_MS), so an outage still
// be rebuilding an estimate as an outage begins, and this can come down to what // has a fair chance of starting during one and the wait stays. Could come down
// LiveKit's SFU needs (a 205 ms correction, absorbed in 41 s; needs a // to what LiveKit's SFU needs (a 205 ms correction, absorbed in 41 s) only once
// mediasoup-go that speaks the 3.27 worker protocol) // the rebuilds are gone.
private static final int OUTAGE_RECOVERY_S = 100; private static final int OUTAGE_RECOVERY_S = 100;
// A poor uplink from the moment the participant joins, as a weak mobile // A poor uplink from the moment the participant joins, as a weak mobile
// connection has: some loss, jitter and little bandwidth at once, for // connection has: some loss, jitter and little bandwidth at once, for