[est31]

Generally it's not possible to compress well encrypted data with any meaningful scheme, but if your encryption is stream cipher based, you can subsample a stream of PCM audio on the server quite easily, by just removing, say every second byte (or every second pair of bytes). Then decrypting entities can insert dummy data at every second byte position, xor with the encryption stream and discard the data again, replacing it with interpolated data instead. Probably the same can be done for uncompressed image data, but any kind of serious compression wouldn't be possible and this simple compression can already be done on the clients without much overhead. So I guess it's mostly of theoretical use.

You would rather have each client send streams in multiple resolutions, say one in 1080p and one in 480p, and then make the central server decide which stream to send to which client. Taking one step further, the clients can be asked to adjust the quality of the stream they are sending depending on which streams they need. There are obvious latency concerns, but there are also bandwidth savings in having less data being uploaded by clients. Actually the bandwidth use is highest if the client uploads an uncompressed or barely compressed unencrypted stream for the server to compress. It's much better if the client's hardware did the compressing part.