Agree. OP's approach is actually terrible for video compression, because it actively throws away the locality of pixel changes present in typical video. A nic

Agree. OP's approach is actually terrible for video compression, because it actively throws away the locality of pixel changes present in typical video. A nicer way of putting it would be that nothing about OP's technique is specific to video frames -- the same idea could be used to compress the diff between any two equal-length bit sequences. Might this nevertheless turn out to be better than existing forms of compression for this problem, like gzipping the concatenated pair of blocks? No, because the only way you get compression at all is if the distribution of inputs (here, sets of different bit positions) is highly predictable, i.e., nonrandom -- and pushing data through a hash function actively destroys that (especially if it's a cryptographically strong hash, the whole point of which is to produce output that is indistinguishable from random).