[askvictor]

Generally speaking, video compression algorithms are 'lossy' (cause a reduction in quality) and need to be able to 'see' the video in order to compress it. The compression typically removes details that are not perceivable by humans (this is also the case for image and audio compression), and by sending just the changes from frame to frame, rather than each entire frame. For both of these, the compression algorithm needs knowledge of the video stream, which would be impossible if it's compressed.

You could try to use a lossless compression algorithm (such as used by zip), but those are effectively useless on video in general, and even more so on encrypted data, which appears to be random.

[sandov]

Thanks for your answer.

> the compression algorithm needs knowledge of the video stream, which would be impossible if it's compressed.

That makes perfect sense and I guess my theory of secure encryption + post-re-compression fails because of this. But what if we didn't need perfectly secure encryption, but just per-block encryption. So the server knows that you've sent 60 frames, but doesn't know what is in those frames.

What if the codec was made in such a way that the server knew that certain blocks in the stream could be discarded to reduce size while the stream without those blocks still makes sense to the recipient.

For example: the stream is composed of 64 byte blocks, but the codec says that every 2 blocks there's a discardable block that adds image quality but is not essential. So, with this knowledge, the server discards every 2 blocks when sending that data to people with low bandwidth and sends the original stream with all its blocks to those with high bandwidth.

It's an extremely naive scheme, but maybe this principle could be applied to more complicated codecs, so the server only needs to know metadata about the stream (where each block is and whether it's essential), but not the content of the block itself (framebuffer and audio sample values).

I'm sorry if this idea is too dumb (and my English skills are not the best).

[askvictor]

Interesting; some time ago the Ogg audio transport was working on bitrate peeling https://en.wikipedia.org/wiki/Bitrate_peeling with the basic idea that a stream can be encoded at one bitrate but can be served at that or any lower bitrate. A simpler example is FM stereo radio - the main frequency provides a mono audio signal, which works just fine, but if the receiver can also pick up the stereo sub-frequency (containing just the diff of left and right channels), it gets stereo.

Anyways, the wikipedia page linked above links to this about the same concept, for video: https://en.wikipedia.org/wiki/Scalable_Video_Coding so it might be feasible. Not sure how feasible/secure encrypting this would be.