Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged.
No sacrificing video quality or freshness required.
No sacrificing video quality or freshness required.
Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?
Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage, especially if the radio channel is congested.
Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless.
If it's actually random, wouldn't the average bitrate of "still scene + occasional random data" still be lower than "active scene + occasional random data"? Given enough samples, of course.
The random noise becomes the background and unless it is a constant addition of noise (which wouldn't save any bandwidth, might as well use uncompressed stream) you could still time changes in the signal.
2. In order to make the real spikes fit into your random pattern you'd need to be able to predict when they will happen.
Given that you have a channel between A and B and an eavesdropper C:
Transmission between A and B can be done by any of several obfuscatory protocols, where (for example) a certain flag sent by A tells B to ignore some component of the transmission, to do no error correction on that part, etc. That flag is sent when updates are sparse, and filler (which is to be ignored) is added by B. Without determining how to identify between filler and data, C sees no variations in traffic volume.
Overcoming real-time spikes is easy with this protocol. Just keep a buffer of a few seconds before you begin transmitting.
This approach is a common answer to any sort of traffic analysis. There's actually a Tor alternative that operates on this principle of constant traffic between nodes (traffic analysis is an effective attack versus Tor), but the name escapes me at the moment.
> Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage
> Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data
You cannot simultaneously reduce network bandwidth and also increase it. Of course padding with noise increases bandwidth, but it's silly to do that when you could instead be padding it with more bits relevant to the video stream.
The vulnerability here isn't inherent to video compression; it's that the compression rate (and therefore network packet rate) is variable (so as to minimize global size of a video stream). It would not be that difficult to modify an encoder to guarantee fixed bit rate over whatever time chunk you want (depending on how many frames is tolerable to buffer before sending out), then send out those chunks at regular intervals.
It all looks the same post-encryption.
Just drone battery life