Making H.264 playback eat less CPU

[TrigunXBox]

After 4 month of reading guides, this forum, and medding with GK, I think I got it down. It takes a long time to encode, but I get a great resualts encoding as an H.264 (near 100% original size, 4:3), OGG audio, vobsub, into an MKV. With the noise filter on, I think the quality of the encoded video is better then the crappy version on the DVD.
But my issue is this. Playing back the video using WMPC or VCL takes 60% of the CPU of my 1.6G Athlon. What is worse, is that my XBox can't play it without dropping frames. And I use my XBox as my main media center.

So what can I do to cut down how much CPU it takes for playback.

a) Can I do some tweaks to the H264 to make it easier to playback without killing the quality or filesize? A bit larger file is fine.

b) Should I just stick to Xvid?

Thanks for any input

[DarkZell666]

Well, changing the resolution would help a lot (this is the heaviest part I believe), along with decreasing the number of b-frames and reference frames. Those features are there to increase quality, but cost more CPU.

Maybe giving your complete settings would help us get to the point faster.
but really, if you encoded your DVD to H.264 @ 720*576 of course the decoding will be really painful (and you should try something like 640*480 or 640*352).

[virus]

... along with decreasing the number of b-frames and reference frames. Those features are there to increase quality, but cost more CPU.
Not at all.
Decoding B-frames and multiple refs eat more memory, not CPU. In the case of B-frames, there may be some slight variations in CPU usage, but nothing exceptional - in fact, depending on the QP they get compressed, decoding B-frames may actually be slightly faster that P-frames, which are usually larger in size.

[TrigunXBox]

The current one I am working on is 640x464. It's as larger as I can get without going over 100% size on H/V.

[DryFire]

Are you using base, main or high profile?

If you're using high profile (which i don't recall VCL supporting) you may want to try main profile. I believe the macro block options have a large effect as to how much power is needed to decode the video. I could be wrong though.

[DarkZell666]

@virus : ok I'll assume you are right, but I remember reading the opposite somewhere in the doom9 forums. I don't understand something though :
Where there is prediction, there is calculation. Where there isn't prediction, there's no calculation, just stream reading and "straight-forward" picture reconstruction (thus using less CPU). I may be the one wrong since I'm far from being an expert ^^ (and I haven't done any tests concerning this either).

@TrigunXbox:
Wow, dropping frames with such resolution ? (Hmm well the xbox cpu
is only 733mhz after all ^^)
DryFire may be right about the HighProfile features, that does ring a bell too.

[virus]

Where there is prediction, there is calculation. Where there isn't prediction, there's no calculation, just stream reading and "straight-forward" picture reconstruction (thus using less CPU).
Sorry, but this sentence doesn't make too much sense to me.

When decoding, you start by decoding the bitstream, basically bit by bit, with an entropy decoder. From this data you reconstruct a differential macroblock, using dequantization and an inverse transform (frequency domain -> spatial domain). And then you add that difference to the MB in your reference frame, pointed by the MV, and store the result. You repeat that for all blocks until you get all your picture decoded.

This is done both for P- and B-frames. The only differences come from the temporal placement (past/future) and the number of the references (1/2) allowed in such a reconstruction process. That impacts the way the MV is computed in some cases. There are some small variations in speed, but really minor.

[Manao]

Bframes are harder to decode. Bitrate matters a lot ( high bitrates --> cabac decoding eats up to 60 % of the decoding time ). 8x8 slightly slows it down. CQM doesn't.

Basically, the decoding time can be writtent as Width * Height * mb_time + bitrate * cabac_time. mb_time_b >> mb_time_p ( which means b frames are harder to reconstruct than p frames ), while bitrate_b < bitrate_p ( but not enough to compensate for mb_time_b vs mb_time_p ).

[DarkZell666]

Hmm ok then. But what's all this b-_predicted_ stuff all about ?
I have obviously missed something somewhere then, mea culpa.

[virus]

mb_time_b >> mb_time_p ( which means b frames are harder to reconstruct than p frames ), while bitrate_b < bitrate_p ( but not enough to compensate for mb_time_b vs mb_time_p ).
there's also the fact that skip_b >> skip_p that should be taken into account. that means much less blocks requiring dequant/transform in a B-frame. All in all, for decent bitrates, I guess what mainly makes the difference is the difference in QP (and thus rate) between B and P, since CABAC really is an important factor in decoding (and you cannot turn it off without sacrificing a lot of quality).

All things considered (and without making any tests), I doubt the overall difference is really relevant, since TrigunXBox here was looking for a good boost to his decoding speeds, not just a few percent.

[bond]

my decoder comparison (http://forum.doom9.org/showthread.php?t=99402) has an own part which only shows how much different encoding features affect the decoding speed for basically all available avc decoders (on my pc)...

the ones with the biggest impacts are (~ in this order)
- resolution
- loop
- b-frames
- cabac

the rest (eg mref or wp) dont influence decoding that much

[Manao]

Actually, resolution's influence on speed depends on your memory speed too. Cabac depends only on the cpu. Doubling the bitrate will make cabac twice as slow. Loop is totally dependant on the resolution ( partially of the bitrate if it is really high, because it gets desactivated ).

BFrames skip are complicated ( those temporal skips are nice to the eye, but a bitch for the decoder ). Moreover, bframes requires twice the bandwidth of the pframes ( two main reference frames ), though it is less true with multiple reference frames ( because of the processor's automatic prefetching logic ). Skip -> you don't have to do the dequant / idct, but those are relatively easy anyway ( in comparison to deblocking / interpolation ), so it's not that easier.

[TrigunXBox]

Excuse me as my eyes gloss over. :)

I was not aware about the h264 profiles. I looked through the settings but I only saw a bunch of numbers to change things I don't understand. I left everything the default in GK, so whatever the default is, that is want I am encodeing in.
I would check, but my WD drive in that system just died. It's still under warranty (expires next month), but I am out of the encoding for a bit.

I know the XBox has a slow CPU at 733. I have only had problems with it dropping frames playing one other video. That was a full 720P video encoded with H264. I have not had any other issues with the other H264 encoded videos I have downloaded. Just the ones I try to make. I was just wondering if I was doing something wrong in trying to press too much data into too small a file size.

When I get me replacment drive, I will try to shrink the video by 25% and see what that does. That should still look quite good when blown up to full screen.

Thanks for the help.

[MeteorRain]

@TrigunXBox:

try reduce or disable b-frame feature and see the result.

and reduce the resolution maybe another choice.

[LordRPI]

Disable CABAC

:ducks:

You may not be as happy with the reduction of filesize/quality, but that is something you can do...

[virus]

Actually, resolution's influence on speed depends on your memory speed too.
Also the size of the L2 cache counts when dealing with multiple refs and B-frames, since in both cases they require additional frames to be retrieved from the memory. If their number and/or size makes the decoder fall off of the L2 cache, a speed penalty occurs. So it really ain't easy to guesstimate decoding performance via a simple discussion :)

By the way: I took a quick decoding test using x264's High Profile, comparing "no B-frames" against "max 2 B-frames" (the rest was at default values). It was 720x576 @ 2 mbit/s, avg QP for P-frames ~20, decoded by mplayer CVS-051029 under Linux (using -benchmark -vo null).
On my P4 2.4GHz, the difference was within 2% of decoding time at that bitrate (slightly faster without B-frames). I reckon that at different rates things may somewhat vary, but in the end I'd say that at sane bitrates it really doesn't make such a significant difference. Certainly not enough to make disabling B-frames a viable solution for really faster decoding on low-end machines.

[Randall]

Try not using AVC's high profile, try the base profile. If you're gonna use less CPU, then you're gonna get less quality. That is the way the world works.

[Revgen]

...If you're gonna use less CPU, then you're gonna get less quality. That is the way the world works.

Not if we can help it. ;)

If every member that came to these forums accepted conventional thought, then what would be the point of coming here?

[akupenguin]

Try not using AVC's high profile, try the base profile.
Don't pick features based on profile. 8x8dct costs some time to encode, but nothing in the decoder.

[sbeyer20]

Hi,

1) chanche the resolution
2) turn off the deblocking filter in your encoder
3) if this is not enough: than don´t use cabac

b-frames and ref-frames doesn´t realy chanche the decoding speed

[DryFire]

Don't pick features based on profile. 8x8dct costs some time to encode, but nothing in the decoder.

So if we were to encode releases for the psp using all the macroblock options it should play?

[akupenguin]

No, but it would fail because the PSP doesn't support high profile, not because it would be slow.

[redfordxx]

Also the size of the L2 cache counts when dealing with multiple refs and B-frames, since in both cases they require additional frames to be retrieved from the memory. If their number and/or size makes the decoder fall off of the L2 cache, a speed penalty occurs
I am not home now, so I can't check, but IIRC there is some buffer or level setting in x264. Does it mean, that when I set it equal to my L2 cache, I can prevent it from falling off? (My Barton has I believe L2 512kB)

[Manao]

No, it is completely unrelated.

[redfordxx]

Don't pick features based on profile. 8x8dct costs some time to encode, but nothing in the decoder.As eg. XviD uses normally 8x8DCT to "store the picture", AVC uses normally 4x4DCT and 8x8DCT is an additional feature? Some features not described in detail enough, I get something only slowly... and wanna check.

[redfordxx]

I suppose for the frame dropping issue (which is in fact CPU speed issue) could be important a bitrate variance parameter, what do you think?
Example (don't catch me for exact numbers, just whether it is related)

When i make 2000kbps CBR it can take 50% CPUtime
2000kbps VBR with variance 0.5 can reach sometimes 3000kbps --> 75%
2000kbps VBR var>1 --> CPU time sometimes > 100% => dropping frames?

[Manao]

That's what the vbv buffer is made for.

[redfordxx]

I looked at renderer properties of the players and it makes HUGE difference.
I don't know what all these renderers mean but the fact is that on my comp AthlonXPBarton2600+ and nVidia Geforce an 1:26 1280x544 @ cca4300kbps test clip:

MPC VMR7 windowed ----- 0:43 (cannot display subtitles)
MPC VMR7 renderless ----- can't remember, but much slower (more than 1 minute), sometimes dropping frames (can display subtitles)
MPC VMR9 renderless ----- can't remember, but much slower (more than 1 minute), dropping frames (can display subtitles)
BSPlayer internal overlay ----- 0:55 (can display subtitles)
BSPlayer overlay mixer ----- 0:43 (can display subtitles)(that's why for me and AVC best choice)
BSPlayer VMR7 ----- 0:43 (can display subtitles, but sometimes was black screen)



So you can hunt for 1% CPU time discussing b-frames, when running the wrong renderer costs you 20x (yes, twentytimes) more

[redfordxx]

That's what the vbv buffer is made for. Is somewhere (or can you give) a more detailed explanation, so the users can benefit from it?

[Manao]

All users can benefit from the forum's search feature, too.

[redfordxx]

All users can benefit from the forum's search feature, too.Well thanks for the answer I already expected "use search" billboard. Mistaken...

(do not understand me being narky, just could not resist making joke --- I do use search, but probably not being skilled enough)

[Manao]

http://forum.doom9.org/showthread.php?t=98386&page=1&pp=20&highlight=vbv+buffer

Read the whole thread, there's a lot of information on rate control in it