Bidirectional video streaming issues #2

New Issue

kirsle · 2023-02-06T22:41:20Z

kirsle commented

2023-02-06 22:41:20 +00:00

There is currently a bug getting video streams to work both ways:

User A starts their camera.
User B opens A's camera - this much works OK.
User A opens B's camera:
- For user B, they see A's camera freeze - the connection was cut off.
- User A can see user B's camera in motion
User B tries to re-open A's camera:
- It happens vice versa: user A sees B's camera freeze, while B can see A's camera normally.

The root cause seems to be in overwriting the WebRTC connection in the front-end code: we keep a map of usernames to WebRTC sockets and the socket is overwritten when one user (who was already streaming video to the other) opens a new connection to receive video from the other.

The frontend should either handle loading the "read" and "write" sockets separately or re-negotiate the one socket to send video both directions.

There is currently a bug getting video streams to work both ways: 1. User A starts their camera. 2. User B opens A's camera - this much works OK. 3. User A opens B's camera: * For user B, they see A's camera freeze - the connection was cut off. * User A can see user B's camera in motion 4. User B tries to re-open A's camera: * It happens vice versa: user A sees B's camera freeze, while B can see A's camera normally. The root cause seems to be in overwriting the WebRTC connection in the front-end code: we keep a map of usernames to WebRTC sockets and the socket is overwritten when one user (who was already streaming video _to_ the other) opens a new connection to receive video _from_ the other. The frontend should either handle loading the "read" and "write" sockets separately or re-negotiate the one socket to send video both directions.

kirsle added the

bug

label 2023-02-06 22:41:31 +00:00

kirsle commented

2023-02-09 21:14:14 +00:00

Poster

Resolved in 5456c88e70

Resolved in 5456c88e703959189d35468cc304adf6eafa07b3

kirsle closed this issue

2023-02-09 21:14:14 +00:00

Sign in to join this conversation.