```In a Jitsi conference, the client and JVB work in tandem to ensure efficient video streaming. This involves an ongoing exchange of sender and receiver video constraints.
Receiver Constraints:
Each participant sends constraints (e.g., desired resolution and priority) to the JVB for the video streams they want to receive. These constraints are influenced by the participant’s current layout (e.g., larger tiles for active speakers).
Sender Constraints:
JVB aggregates these constraints and communicates the required video resolutions to the senders. This ensures a participant only sends higher-resolution streams (e.g., 720p) if at least one other participant views them in a sufficiently large tile.
```
"evtentually" there are competing requests from different client-server tasks that differ in `resolution`<->`videoQuality`
//Todo{low prio}: Maybe we should kick out h.264 ??
2.`config.js` in `/usr/share/jitsi-meet` -> Todo: Result?
3. Should default setting 720p `resolution`&`videoQuality` do the job ?? described as default value, eventually that's well tested on jitsi development side.
// P2P test mode disables automatic switching to P2P when there are 2
// participants in the conference.
// p2pTestMode: false,
## Test-server circumstances:
All circumstances measured by 3rd person on "neutral" extern client within grafana
In general, every circumstance should be done like ff:
* 2 participants under normal workload {like weekly presentation}
* 2 participants under normal workload {like weekly presentation} using and "Testserver needed"/4. T.Parameters configured true, see above ```p2pTestMode: true,```
* 3 participants under normal workload {like weekly presentation}
* automated N participants under normal workload {like weekly presentation}
1. Run at default values `720p`, no entries to any video settings in `web-config-envs-cm.yaml`, branch video_performance_issue commit a94563ff96 from zam 28.02.2025
