Video moves to the graphics card
A playing video used to be turned from the decoder's colour planes into RGB on the processor, frame by frame, and then drawn into the page's tiles. Now the planes go straight to the graphics card, which converts them into a layer of their own, and the processor only converts a frame when a script reads it. A 720p video's processor use drops from 44% to 28%, H.264 frames take 3.1 MB each instead of 8.3, and the picture is the same: the graphics card's conversion is the processor's own arithmetic, byte for byte.
Each video gets its own layer
The frames a page plays no longer go through the page's tiles. The decoder's planes (brightness at full size, colour at half) are uploaded once a frame, and the graphics card turns them into RGB with the same whole-number sums the decoders use, so a frame on the card is the frame the processor would have made. The page is not repainted for each frame any more.
RGB only when something reads it
A frame now keeps its planes and becomes RGB the first time a canvas, a texture or the software path reads it. A video that is only watched is never converted on the processor. When it is read, the conversion is twice as fast as before (two pixels share one set of colour terms), and it gives the same bytes.
H.264 on the Mac: our conversion, within one step of the system's
The Mac's video decoder now hands back its planes instead of finished RGB. Repeating each colour sample (what our own decoders do) was up to 246 levels away from the system's picture on fine colour detail, so we measured what the system does: it blends colour between samples placed on every other pixel. Our version of that blend, in whole numbers, is within one level of the system's picture on every pixel of every clip we tried, and the graphics card computes the same bytes.