[MPlayer-users] h.264 and cpu consumption

[Loren Merritt]

On Fri, 23 Jun 2006, Nick Rout wrote:
> On Thu, 22 Jun 2006 09:59:38 -0500
>> On Jun 22, 2006, at 04.55, ?? wrote:
>>>
>>> I know h.264 is CPU-intensive, and I assume that's because it
>>> encoded more
>>> details and the data is much more compressed. But in this special
>>> case, It
>>> just five static picture lasted 20 min encoded in h.264.
>>
>> Yeah, but is that five pictures over twenty minutes at 29.97 FPS, or
>> at 0.0042 FPS? Unless you encoded it at 0.0042 FPS (that is, a grand
>> total of five frames in twenty minutes), MPlayer will have to decode
>> all the frames, even if they're identical, or even if they have
>> little to no motion. And at 1024x768 resolution, that's a fair chunk
>> of data to decode too.
>
> I thought that the idea of a codec was that it (in simplisitc terms)
> only encoded into the file the delta between each successive frame. In
> this case there will be a larger first frame, then sweet damn all
> "delta" for the next 4 minutes (=4*60*29.975 frames), then a massive
> change to the next still, then no change again and so on.
>
> Surely it cannot be too cpu intensive to interpret "this frame is the
> same as the last one"

Partly it's that ffh264 is just inefficient. And partly that h264 isn't 
so simple.
h264 says: "this 16x16 block is the same as that piece of the previous 
frame. the next one is too. so is the next one. ..." and there's a whole 
bunch of information it needs to keep track of in case one of the blocks 
isn't just a copy.

--Loren Merritt