сб, 23 мая 2020 г. в 05:36, Maxim Solodovnik <[email protected]>:
> > Thanks, > this is great starting point :)) > Glad that you like it ^_^ > it looks very similar to interview room > Yeah, In some aspects. But without removing board functionality. And with focus on strictly automatic cam management. > Notes: > 1. the controls might not fit onto small screen > 2. same note for video area and video-on-user-list > Everything should be bootstrapped. Controls should dynamically react to available area. So If there are not enough room for controls they should hide themselves under dropdown list with single icon. If user resized window or rotated device and there are enough room now they should unhide back to normal. Kinda like main menu currently does (though too aggresive). Maybe we should group all these setup/request/placement controls together on one bar. Same goes for user-list it should hide/resize unnecessary elements like avatars and rearrange elements so they populate as less space as possible. Like if we are constricted by width but not by height username goes above video or even on top of it and so on. If something becomes too small for reliably interacted by finger it should be also replaced by single button with drop-down list. Also majority of these small-screens if not all of them are portable devices nowadays. And the common way to deal with them is to go with native apps for these platforms. That way you will have better control, performance, battery drain and doesn't have to be dealing with plethora of different browsers and their quirks/constraints. Correct me if I'm wrong but that way is currently infeasible for us. Because web-interface is too tightly intertwined with server-side due to wicket and we don't have a clean and abstract api of communication to decouple frontend web-UI from backend java application. So writing standalone apps or alternative web-interfaces on modern frameworks like react will be huge pain in the ass. >> Algorithm of rectangle packing is debatable. I think it will be better to >> dynamically calculate webcam sizes based on total number of cameras and >> available area size so they are all the same size. And deny any user custom >> movement/resizes. Maybe with exception that user can increase/decrease size >> of specific webcams by factor of 2. >> > > in this case camera resolution dialog is very much useless > WDYT? > If we get rid of it we should also somehow tackle the problem of controlling bandwidth consumtion and quality of streams. We doesn't want that couple of desktop users with shiny full-hd webcams tank to ground weak mobile connections and slow devices. And at the same time we don't want to have blurry pixalated mess on fullscreen if remote user has great webcam. WebRTC have concepts of BWE (Bandwidth Estimation) and REMB (Received Estimated Maximum Bitrate) but I'm not sure how they play in non-p2p mode in relation with KMS if play at all. We also have bitrate constraints so we can influence used bandwidth. But bitrate is directly tighted to video resolution and video/audio quality. You don't need much bitrate to stream a thumbnail but you need it for high resolution streams. Also, the more resolution the more there be CPU (or dedicated hardware units on SoC, GPU,...) usage for encoding on sender and decoding on receivers. Aforementioned jitsi doesn't have resolution selector either. It has server-side global variables for setting minimum and maximum resolutions. When there are 2 cams in the room they use p2p mode with maximum possible resolution (limited by maximum supported resolution by webcam hardware, global server setting and available bandwidth between clients). When third client enters the room they seemlessly switch to routing through videobridge (in our case thats kms). When in videobridge mode they also have feature called simulcast. Which roughly works like that: every participant encodes simultaneously multiple copies of video streams with different resolutions, bitrates and even framerates and push them all to videobridge. When remote client see his stream in small thumbnail only smallest stream is send to him, when he switch that webcam to fullscreen it seemlessly switch to stream with maximum resolution if there are available bandwidth. In other cases like tile-view medium streams are typically transmitted. In other words they seemlessly adapt transmitted content to presentation size and bandwidth constraints between client and videobridge. So at the expense of mostly static and predictable increase of cpu usage and upload bandwidth on every client you at the same time see great quality streams and could participate in very large video conferences without issues related to download bandwidth constraints or hardware overload due to receiving and decoding of many high-definition streams simultaneously.
