Google Patents a Video Compression Method That Blends Two Past Frames Into One Prediction
Every time you stream a video, your device is essentially predicting what the next frame looks like rather than downloading it whole. Google's latest patent tries to make those predictions more accurate by consulting two past frames instead of one.
What Google's two-frame video prediction actually does
Video files are huge, so modern codecs (compression tools) cheat: instead of storing every frame in full, they store only the differences from a previous frame. That works well when objects move predictably, but a single reference frame often isn't enough to describe complex motion accurately.
Google's idea is to chain two reference frames together automatically. When the encoder is trying to predict what a block of pixels looks like in the current frame, it finds the best match in one older frame, then follows that block's own motion data to a second, even older frame. It then averages the two matches to build a better prediction for the current frame.
The result is a more accurate prediction built from two snapshots of the same moving region, which means less correction data needs to be stored or transmitted. For you, that could translate to sharper video at the same file size, or the same quality at a lower data rate.
… identifying, using motion information associated with the first reference block that refers to a second reference frame, a second reference block in the second reference frame; and combining the first reference block and the second reference block to obtain a prediction block for the current block.
Translation: The system finds a matching block in a second past frame and blends it with the first one to predict the current image.
How the encoder chains motion vectors across frames
Standard video compression relies on motion vectors (arrows that point from a block of pixels in the current frame back to where that block came from in a previous frame). The encoder uses that pointed-to region as a prediction, then only stores the error between the prediction and reality.
This patent extends that idea by one step. After finding the first reference block in frame N-1, the system reads that block's own stored motion vector, which points to a second reference block in frame N-2. It now has two candidate regions:
- The direct reference block in frame N-1
- A second reference block in frame N-2, reached by chaining the first block's motion data
The two blocks are then combined, typically by averaging their pixel values at each matching position. This averaged block becomes the prediction for the current frame. Because both reference blocks captured the same moving object at different points in time, their average often sits closer to where the object actually is in the current frame than either block alone.
The key claim is that the system derives the second reference frame's location automatically from motion information already stored in the bitstream, so no additional side data needs to be transmitted to the decoder.
Combining the first reference block and the second reference block may include obtaining pixel values of the prediction block by averaging respective co-located pixel values of the first reference block and the second reference block.
Translation: The software merges the two past image blocks by taking the average of their matching pixels.
What this means for streaming quality and bandwidth costs
Better motion prediction means the encoder has less error to correct, which means smaller files or higher quality at the same bit rate. That math matters for Google, which runs YouTube (one of the largest video distribution operations on the planet) and develops the open-source AV1 and AV2 codecs used across the industry.
Google's long investment in open video codec research means even a modest efficiency gain at this level, applied to billions of video streams, translates into real infrastructure savings. For viewers, incremental codec improvements like this are why streaming quality has kept improving even as average bit rates have stayed flat.
This is the 690th Google filing in our Google coverage since May, adding to work on fixing compression blur and predicting object motion.
This is a codec-engineering patent, and codec patents are the opposite of showy. The method is incremental: it adds one extra lookup and an averaging step to an existing motion-compensation pipeline. No new hardware is required, and the core idea could slot into a software encoder update.
The path to shipping is actually short by patent standards. The approach works entirely within the existing codec architecture (no new signal formats, no decoder hardware changes beyond a software update), which means Google could integrate it into a future AV1 or AV2 encoder profile without waiting for device manufacturers. The real question is how much compression gain it produces in large-scale testing, because a small gain multiplied across YouTube's volume becomes meaningful, while the same gain in a niche use case is just another line in a codec spec.
If you were hoping this signals some dramatic shift in how video works, it doesn't. But the people running global video infrastructure care a lot about these small wins, and Google has the traffic volume to make even a fraction-of-a-percent efficiency improvement worth the engineering effort.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
11 drawing sheets from US 2026/0270401 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →