nobilis/src/backend/matrix/calls.rs opens by calling itself "voice and video calls",
and there is no video in it - no camera capture, no screen capture, and no negotiation
of a video stream in either direction. README.md:26 says as much.
Element does both, in one-to-one calls and in the Element Call sessions moho already
joins (#132). Someone who turns their camera on in a call moho is in is simply not seen,
and nothing says why.
`nobilis/src/backend/matrix/calls.rs` opens by calling itself "voice and video calls",
and there is no video in it - no camera capture, no screen capture, and no negotiation
of a video stream in either direction. `README.md:26` says as much.
Element does both, in one-to-one calls and in the Element Call sessions moho already
joins (#132). Someone who turns their camera on in a call moho is in is simply not seen,
and nothing says why.
Partly done, and the ticket overstates the gap for one of the two call types — worth correcting here since it changes what is left.
Group calls (Element Call / LiveKit) already do video. Remote camera tracks are collected and drawn, screen share has a working toggle, and the room bar offers "Join with video". What was actually missing was a mid-call camera control: the camera could only be chosen at the door, which is the one moment nobody has decided yet whether they want to be seen.
That is now fixed in c4ba320 — a camera toggle beside the microphone and the screen, drawn only on a call held on a media server, since that is where it can act.
One-to-one calls (calls.rs) are still voice only, and that is the real substance of this ticket: no camera capture, no screen capture, no video negotiation in either direction. It stays open for that.
Per this tracker's own note, that half shares its plumbing with #14 (Discord screen share) and #180 (Discord camera), and is worth planning with them rather than doing Matrix's in isolation. I have not started it.
Neither half can be verified live from here: a call takes a second participant, and every room on the working account (@salastil:poa.st) has other people in it. What is verified is the state — a call joined with video reports its camera on, one joined without reports it off, and the control is only drawn where it can do something.
Partly done, and the ticket overstates the gap for one of the two call types — worth correcting here since it changes what is left.
**Group calls (Element Call / LiveKit) already do video.** Remote camera tracks are collected and drawn, screen share has a working toggle, and the room bar offers "Join with video". What was actually missing was a *mid-call* camera control: the camera could only be chosen at the door, which is the one moment nobody has decided yet whether they want to be seen.
That is now fixed in [`c4ba320`](https://git.salastil.com/Salastil/moho/commit/c4ba320) — a camera toggle beside the microphone and the screen, drawn only on a call held on a media server, since that is where it can act.
**One-to-one calls (`calls.rs`) are still voice only**, and that is the real substance of this ticket: no camera capture, no screen capture, no video negotiation in either direction. It stays open for that.
Per this tracker's own note, that half shares its plumbing with #14 (Discord screen share) and #180 (Discord camera), and is worth planning with them rather than doing Matrix's in isolation. I have not started it.
Neither half can be verified live from here: a call takes a second participant, and every room on the working account (`@salastil:poa.st`) has other people in it. What is verified is the state — a call joined with video reports its camera on, one joined without reports it off, and the control is only drawn where it can do something.
The screen share and the video-call-from-the-start half had landed already; the missing piece was a camera in a call already running, and the button was hidden unless the call was on a media server — so on the two shapes of Matrix call that do not use one, there was no camera at all.
Added and removed, not enabled and disabled. A disabled track keeps sending: a black rectangle at whatever frame rate the encoder feels like, which the far end cannot tell from a camera that has frozen. Removing the track ends it properly, and every other client then draws the person's name.
That difference is measured rather than asserted. scripts/callcheck/run.sh wires two real RTCPeerConnections together in one page, with a canvas for the camera and an oscillator for the microphone, so it needs no hardware and no second person:
connected: a sees 0 live video, b sees 0
a turns its camera on mid-call
a.cameraOn=true; b now sees 1 live video track(s)
a turns it off again
a.cameraOn=false; b now sees 0
b turns its camera on, the other direction
a now sees 1 live video track(s)
VERDICT PASS
Run against the old enabled = false behaviour the same harness reports b now sees 1 after the camera is switched off — the frozen square — and FAILs. The renderer has no test runner of its own (#212), so this is the closest thing to one for the part that cannot be checked by reading.
One gesture for all three shapes of call — a media server, a mesh, a single connection — because the button is one button and the person pressing it is asking one thing. On a mesh the camera is still opened once and lent to every leg: five connections asking the machine for the same camera get one capture and four refusals.
Two things fixed on the way: renegotiations are now serialised, since turning a camera on and sharing a screen a second later left a peer connection neither end could recover from; and a remote track that is taken away is dropped from the stream it arrived on, so a tile stops drawing the last frame it received.
The call UI is unchanged in shape and deliberately not Matrix-shaped — #180 and #14 get the same row of buttons when they arrive.
nobilis f0e1d9e, moho f965642. README and ARCHITECTURE no longer say there is no video.
Finished.
The screen share and the video-call-from-the-start half had landed already; the missing piece was a camera in a call **already running**, and the button was hidden unless the call was on a media server — so on the two shapes of Matrix call that do not use one, there was no camera at all.
**Added and removed, not enabled and disabled.** A disabled track keeps sending: a black rectangle at whatever frame rate the encoder feels like, which the far end cannot tell from a camera that has frozen. Removing the track ends it properly, and every other client then draws the person's name.
That difference is measured rather than asserted. `scripts/callcheck/run.sh` wires two real `RTCPeerConnection`s together in one page, with a canvas for the camera and an oscillator for the microphone, so it needs no hardware and no second person:
```
connected: a sees 0 live video, b sees 0
a turns its camera on mid-call
a.cameraOn=true; b now sees 1 live video track(s)
a turns it off again
a.cameraOn=false; b now sees 0
b turns its camera on, the other direction
a now sees 1 live video track(s)
VERDICT PASS
```
Run against the old `enabled = false` behaviour the same harness reports **`b now sees 1`** after the camera is switched off — the frozen square — and FAILs. The renderer has no test runner of its own (#212), so this is the closest thing to one for the part that cannot be checked by reading.
**One gesture for all three shapes of call** — a media server, a mesh, a single connection — because the button is one button and the person pressing it is asking one thing. On a mesh the camera is still opened once and lent to every leg: five connections asking the machine for the same camera get one capture and four refusals.
Two things fixed on the way: renegotiations are now serialised, since turning a camera on and sharing a screen a second later left a peer connection neither end could recover from; and a remote track that is taken away is dropped from the stream it arrived on, so a tile stops drawing the last frame it received.
The call UI is unchanged in shape and deliberately not Matrix-shaped — #180 and #14 get the same row of buttons when they arrive.
nobilis [f0e1d9e](https://git.salastil.com/Salastil/nobilis/commits/branch/development), moho [f965642](https://git.salastil.com/Salastil/moho/commit/f965642). README and ARCHITECTURE no longer say there is no video.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
nobilis/src/backend/matrix/calls.rsopens by calling itself "voice and video calls",and there is no video in it - no camera capture, no screen capture, and no negotiation
of a video stream in either direction.
README.md:26says as much.Element does both, in one-to-one calls and in the Element Call sessions moho already
joins (#132). Someone who turns their camera on in a call moho is in is simply not seen,
and nothing says why.
Partly done, and the ticket overstates the gap for one of the two call types — worth correcting here since it changes what is left.
Group calls (Element Call / LiveKit) already do video. Remote camera tracks are collected and drawn, screen share has a working toggle, and the room bar offers "Join with video". What was actually missing was a mid-call camera control: the camera could only be chosen at the door, which is the one moment nobody has decided yet whether they want to be seen.
That is now fixed in
c4ba320— a camera toggle beside the microphone and the screen, drawn only on a call held on a media server, since that is where it can act.One-to-one calls (
calls.rs) are still voice only, and that is the real substance of this ticket: no camera capture, no screen capture, no video negotiation in either direction. It stays open for that.Per this tracker's own note, that half shares its plumbing with #14 (Discord screen share) and #180 (Discord camera), and is worth planning with them rather than doing Matrix's in isolation. I have not started it.
Neither half can be verified live from here: a call takes a second participant, and every room on the working account (
@salastil:poa.st) has other people in it. What is verified is the state — a call joined with video reports its camera on, one joined without reports it off, and the control is only drawn where it can do something.Finished.
The screen share and the video-call-from-the-start half had landed already; the missing piece was a camera in a call already running, and the button was hidden unless the call was on a media server — so on the two shapes of Matrix call that do not use one, there was no camera at all.
Added and removed, not enabled and disabled. A disabled track keeps sending: a black rectangle at whatever frame rate the encoder feels like, which the far end cannot tell from a camera that has frozen. Removing the track ends it properly, and every other client then draws the person's name.
That difference is measured rather than asserted.
scripts/callcheck/run.shwires two realRTCPeerConnections together in one page, with a canvas for the camera and an oscillator for the microphone, so it needs no hardware and no second person:Run against the old
enabled = falsebehaviour the same harness reportsb now sees 1after the camera is switched off — the frozen square — and FAILs. The renderer has no test runner of its own (#212), so this is the closest thing to one for the part that cannot be checked by reading.One gesture for all three shapes of call — a media server, a mesh, a single connection — because the button is one button and the person pressing it is asking one thing. On a mesh the camera is still opened once and lent to every leg: five connections asking the machine for the same camera get one capture and four refusals.
Two things fixed on the way: renegotiations are now serialised, since turning a camera on and sharing a screen a second later left a peer connection neither end could recover from; and a remote track that is taken away is dropped from the stream it arrived on, so a tile stops drawing the last frame it received.
The call UI is unchanged in shape and deliberately not Matrix-shaped — #180 and #14 get the same row of buttons when they arrive.
nobilis f0e1d9e, moho f965642. README and ARCHITECTURE no longer say there is no video.