[x264-devel] Re: Another CPU related question

[Jelle]

Loren Merritt wrote:
> On Fri, 5 May 2006, Jelle wrote:
>> Loren Merritt wrote:
>>>
>>> No, I don't know whether my videocard supports xvmc, but I certainly 
>>> haven't enabled it in ffmpeg. This is cpu-time as measured by
>>> `time mplayer -benchmark -vo null -nosound -vc ffmpeg2`.
>>
>> Ok, I'll run that too then.
>>
>> Two different machines. I know for sure that neither machines have 
>> videocards that support Xvmc.
>>
>> Athlon64 3200+ (2GHz/512kb cache)
>> MPEG2 video 480x576 at 25fps, 2.5Mbit/s (much less than DVD), 4688 
>> seconds long.
>> 100 * 12*60+20/4688 =~ 16% CPU.
>>
>> P4/3GHz/1M cache
>> MPEG2 video 720x480 at 29.97fps, 4.5Mbit/s, 1886 seconds long
>> 100 * 4*60+12/1886 =~ 13% CPU.
>>
>> I don't know where you got 2%, but I can't reproduce anything even 
>> close to it.
>>
>> 2% of a 2.2GHz CPU, or 44MHz, for DVD video? How can I get that?
> 
> Ok, so it wasn't quite 2%.

Still a lot better than what I get... If it's not Xvmc, I'd like to know 
what it is. Am I doing something wrong?

The server for the mplayer CVS is down, so I tried the latest release 
mplayer (1.07pre7try2, compile with plain './configure').

I reran the 480x576 2.5Mbit video, and it got to 11.6% on the 3200+. I 
also ran it on a Turion (2.2GHz/1MB cache), and it needed 5.4% there 
(4.9% in x86_64 mode (pure64)), a 2.8GHz/512KB cache Xeon needed 5.6%.

At 480x576, that is quite a lot less macroblocks than a full DVD, but 
still it needs significantly more CPU than your benchmark. The 
difference is much more than you would expect from the CPU speed difference.

Am I doing something wrong? Or is the CVS version of mplayer that much 
faster than the latest release?

(A 4.5Mbit/s 720x480 stream on the P4/3Ghz/1M cache still needed 11.3% 
with mplayer 1.07pre7try2).


Jelle.

> 
> Athlon64 3400+ (2.2GHz/1024kb cache)
> MPlayer dev-CVS-060508-14:21-4.0.4
> 
> MPEG2 video 720x480x23.976fps, 4.1 Mbit/s, 5598 seconds
> BENCHMARKs: VC: 184.573s VO:  0.124s A:  0.000s Sys:  5.560s = 190.297s
> BENCHMARK%: VC: 96.9921% VO: 0.0652% A: 0.0000% Sys: 2.9227% = 100.0000%
> real    191.395s
> user    185.882s
> sys     3.446s
> 
> 100% * 191.395 / 5598 = 3.4% CPU
> 
> MPEG2 video 720x480x23.976fps, 8.4 Mbit/s, 3750 seconds
> BENCHMARKs: VC: 232.713s VO:  0.086s A:  0.000s Sys: 10.425s = 243.224s
> BENCHMARK%: VC: 95.6782% VO: 0.0354% A: 0.0000% Sys: 4.2863% = 100.0000%
> real    244.856s
> user    233.706s
> sys     5.401s
> 
> 100% * 244.856 / 3750 = 6.5% CPU
> 
>> mpeg2 decoding takes about the same amount of operations per frame as 
>> JPEG (mjpeg) encoding. If your 2% number is really valid, you should 
>> be able to transcode mpeg2 to mjpeg 25 times faster than real-time 
>> (ramdisk to ramdisk if necessary).
> 
> Transcoding mpeg2->mjpeg is only 6x realtime here (using the 3.4% dvd).
> mjpeg takes more time for bitstream packing because it's higher bitrate, 
> and more time for dct/quant because when encoding you need to process 
> all pixels/coefs, whereas when decoding you skip the null coefs and null 
> blocks. And yes, those factors combined cost more than a little motion 
> compensation does.
> 
> --Loren Merritt
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html