[MPlayer-users] h.264 and cpu consumption
Nick Rout
nick at rout.co.nz
Fri Jun 23 04:07:10 CEST 2006
On Thu, 22 Jun 2006 09:59:38 -0500
Ivan Kowalenko wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jun 22, 2006, at 04.55, ?? wrote:
>
> > Hi,
> >
> > On Thursday 22 June 2006 14:28, RC wrote:
> >> On Thu, 22 Jun 2006 14:12:48 +0800
> >> Yes. It's very CPU-intensive.
> >>
> >> It's funny seeing this question asked over and over again.
> >
> > 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"
>
> A better test might be encoding Team Orange's Elephant's Dream. It
> will give you a more representative snapshot of what kind of CPU
> usage you should come to expect out of H.264.
>
> > Isn't a 30% cpu time
> > too intensive.
> >
> > --
> > Best Regards,
> > LR
More information about the MPlayer-users
mailing list