mirror of https://github.com/OpenVidu/openvidu.git
50c4778c12
When a subscriber connection was left with audio only, the mediasoup worker kept probing its bandwidth every 5 s. This happens when the camera is muted, when the subscriber disables the video, or when the camera is unpublished. With v3.32.1-openvidu2 each probe dropped the estimate to its 30 kbps minimum, so the video came back on its lowest layer. With v3.32.1-openvidu3 the probes had no cap: on a LAN, bursts of up to 1 MB every 5 s and an estimate near 1 Gbps. openvidu-pro-mediasoup now sends no probe while no video Consumer is active. OpenViduTestAppE2eTest gets one test for each way a connection can end up with audio only, holding it there for 20 s: - cameraMuteKeepsSubscriberBweTest: the publisher mutes the camera. - subscriberDisabledVideoKeepsSubscriberBweTest: the subscriber disables the video, which is what adaptive stream does with a hidden video. - cameraUnpublishKeepsSubscriberBweTest: the camera is unpublished and published again. It is @OnlyMediasoup because LiveKit's pion engine starts a new track on its lowest layer by design. The first two check that only the audio reaches the subscriber, under 250 KB. All three check that the first frames after the video comes back are already the top layer. The testapp's video info dialog now reports transportBytesReceived and transportPacketsReceived, read from the peer connection's 'transport' stats. The probes are RTX padding, and the video's inbound-rtp counters do not count them. publishCamera() and unpublishCamera() move to AbstractOpenViduTestappE2eTest, and Publisher.addVideo() and unpublishVideo() in OpenViduTestAppE2eEgressProTest now call them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| docker | ||
| src | ||
| pom.xml | ||