mirror of https://github.com/OpenVidu/openvidu.git
36f6996c2d
publisherCongestionVp9Test (pion): the A/V offset was +79..+109 ms before the congestion and +90..+101 ms after it, but Recording.assertRecovered also required every offset after it to be within 100 ms. The level a long recording settles on, once the sync engine places its tracks by their sender reports, changes from one recording to the next: up to +155 ms locally, in a recording that had +7..+15 ms in its first 12 s. On pion, every rebuild of the audio estimate (every 24 s) also moves the audio by up to 70 ms. Each offset after the trouble must now be within HEALED_AV_TOLERANCE_MS of the range it had before, and within HEALED_AV_MAX_MS (250 ms); the median check stays. A recording with no time before the trouble (publisherBadNetworkFromTheStartTest) keeps the 100 ms limit. Over the 336 network-test recordings of the last 20 CI runs, the old rule failed 5 and the new one fails 1: the +241 ms after a long outage with mediasoup on 2026-10-29, a real failure. egressPacketLossAv1Test (mediasoup): "videoLosses 0" was right. The recording had every frame through the 15 s of 30% loss, because NACKs got every packet back: mediasoup resends a packet as often as it is asked, and the AV1 track takes few packets per frame. videoLosses 0 now passes when the video has no hole longer than 0.2 s during the loss. Normal frame gaps in these recordings stay below ~106 ms, and a loss leaves a hole of some 300 ms. The test logs both values. twoCamerasTest (pion): the second camera never reached 640x480. When it was published, the first camera dropped to 240x180 too, and neither came back in the 8 s left. The browser had stopped sending their top layer: LiveKit's SFU never limits the egress, which sends no REMB. The test now waits up to 30 s until getStats() on each camera's sender shows a layer 640 wide at 10 fps or more, then records at least 3 s more. A timeout fails with the browser's layers and quality limitation reason. Locally, right after the second camera, Chrome reported "bandwidth", 577 kbps and the top layer at 3 fps. Verified locally with the published openvidu-server-pro:main and egress-pro:main images (egress-pro 9d12eff, mediasoup-worker v3.32.1-openvidu3), running the three tests together: - mediasoup: 2 rounds, 6 of 6. - pion: twoCamerasTest 7 of 7 and egressPacketLossAv1Test 3 of 3 with the final rule. One more run had +119..+155 ms before the loss and +151..+158 ms after: it is the one that set HEALED_AV_MAX_MS above 150. - A timeout run, waiting for 1280-wide cameras, failed with the browser's report. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| docker | ||
| src | ||
| pom.xml | ||