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> |
||
|---|---|---|
| .github | ||
| docs/images | ||
| openvidu-components-angular | ||
| openvidu-dashboard | ||
| openvidu-deployment | ||
| openvidu-livekit@2f779fc1fd | ||
| openvidu-test-browsers | ||
| openvidu-test-e2e | ||
| openvidu-test-integration | ||
| openvidu-testapp | ||
| .gitignore | ||
| .gitmodules | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| NOTICE | ||
| README.md | ||
README.md
openvidu
Visit openvidu.io
What is OpenVidu?
OpenVidu is a self-hosted real-time video and audio stack, built on top of LiveKit and mediasoup, and developed by a team with over a decade of experience building WebRTC systems. It ships as two products:
OpenVidu Meet
OpenVidu Meet is a ready-to-use, self-hosted video conferencing application: an open-source alternative to Zoom, Google Meet and Jitsi Meet.
Using it requires no code. You deploy it and it works — rooms, recordings, chat, screen sharing and moderation included. It is also highly customizable: brand it with your own name, logo and colours, and choose which features each participant gets.
With minimal effort it embeds into your own application, through an <iframe> or the
OpenVidu Meet web component, and is driven from your backend with a REST API and webhooks:
OpenVidu Platform
OpenVidu Platform is the programmable client and server SDKs for building custom WebRTC applications with low-level control over media, on top of LiveKit and mediasoup. It is API-compatible with LiveKit: any LiveKit client/server SDK works unchanged.
Both products
- Self-hosted only: deploy them on your own infrastructure (AWS, GCP, Azure, Oracle, DigitalOcean, on-premises). There is no hosted/SaaS tier: OpenVidu PRO is a paid, self-hosted edition, and the OpenVidu team offers support and consultancy.
- Advanced media features: recording, RTMP/streaming egress, AI agents (transcription, translation), virtual backgrounds, and more.
Getting started
- 📖 Documentation
- 🚀 Try it locally
- 💻 Tutorials
- 🎥 OpenVidu Meet — the ready-to-use video conferencing app (source)
Community Forum
Visit OpenVidu Community Forum
Contributors
This project exists thanks to all the people who contribute.
Backers
Thank you to all our backers! 🙏 [Become a backer]
Acknowledgments
OpenVidu has been supported under project "CPP2021-008720 NewGenVidu: An elastic, user-friendly and privacy-friendly videoconferencing platform", funded by MCIN/AEI/10.13039/501100011033 and by the European Union-NextGenerationEU/PRTR.
Sponsors
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]
