The video illustrates it best.
Interesting, I was speculating how to defeat this as a pilot/spy and it seems like the issue is needing to hide your encoder’s delta frequency. There are 2 basic ways to do this: full data and normalized data. Full data does exactly what it sounds like, transmits each full frame captured by the camera. This results in a flat signal. High, but flat, thus deltas cannot be detected since they no longer exist. Normalized would be a specialized encoder that uses a technique to smooth out the peaks and valleys of data bursting. The signal may need to be delayed by several frames to give smooth ramp-up rates to hide the exact spike in the true delta line. Both of these techniques cause unnecessary data to be transmitted, reducing the efficiency of compression / encoding. But if you want to be sure your target cannot use this technique to see you spying, they might be worth the efficiency loss.
If you didn’t want lag you could just use a shared seed to randomize the order of say 4,000 different keys for encrypting each frame with a rule to skip a key if it was used in the last 2,000 frames. That’d give you over a minute of strong randomness at 30fps and be pretty decent ongoing.
If I understand the counter survalence technique, that would not obsfucate the data sufficiently. The researchers were only counting Bytes per second on the wire. The encryption method or randomness does not change this rate. That’s how the secondary article about determining what a Netflix user was watching did not need to break TLS to determine the content being streamed.
< Helps when I read the article all the way through lol
Instead of encoding video as a series of raw images, it’s compressed into a series of changes from the previous image in the video. That means when a streaming video shows a still object, it transmits fewer bytes of data than when it shows one that moves or changes color.
I was thinking of similarities in a total frame much like how one can assume certain things about web traffic.