Earlier quoted context omitted.
1. Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. 2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second, with unencrypted markers showing where they can be sliced and joined. If you can upload a 1080p stream, chances are you've got the bandwidth to send a 360p stream too! 3. Each client tells the s…
a few problems: >Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? How do you plan on doing that without any substantial lag? >2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second you have man…
By doing whatever Signal and Whatsapp do to support 50-person encrypted group chats.
> you have managed to double your egress
Not at all.
Firstly, the whole point of having two streams is to accommodate viewers with different bandwidth requirements, so the second stream will be a fraction the size of the first. If I'm already uploading HD video at 5 Mbps, and I start also sending an SD stream at 1 Mbps, my egress has risen by only 20%.
Secondly, the h264 spec provides for 'Scalable Video Coding' [1] where a high quality stream can have a lower quality 'subset bitstream' allowing a high-quality video to be converted to low quality by selectively dropping packets. So your egress might not rise by even 20%! Although this h264 feature is less widely used, potentially raising engineering costs.