Good Quality to CPU Decoding Power Ratio

[iwod]

I think i have given up trying to a decent codec that doesn't require high CPU decoding resource while giving nice quality.

Rmvb was the closest thing i got. I suddenly wonder if there are anything that i could do to make x264 files uses much less CPU resources. ( Taking i am already using Divx Decoder or CoreAVC )

Or any codec i could look at? Last time i try WMV didn't do well at all.

[Guest]

DXVA in conjunction with an appropriate graphics card and software player.

[iwod]

DXVA in conjunction with an appropriate graphics card and software player.

Well i have edited the title. Since i am aiming at low power PC without Hardware Decode.

[nm]

MPEG-4 ASP or H.264 with CAVLC instead of CABAC and inloop deblocking turned off in the encoder.

It would be easier to recommend things if you told more about the target CPU(s) and properties of the videos you intend to play (resolution, framerate, average and maximum bitrates). For example, H.264 is a good choice for multi-core CPUs because there are fast multi-threaded decoders. (Dual-core Atoms definitely fit the "low power" description in both processing performance and energy consumption.) If you target older single-core CPUs, MPEG-4 ASP might work better.

[benwaggoner]

Keeping the VBV/peak bitrate small will help keep the momentary complexity from spiking up too high.


And do you care about performance just for playback, or also for startup and scrubbing?

Keeping reference frames down can help in that case. I'm not quite sure the impact of Pyramid Bs; it probably varies quite a bit with content.

Keeping the VBV/peak bitrate small will help keep the momentary complexity from spiking up too high.

[akupenguin]

Keeping reference frames down can help in that case.
Reference frames have no more impact on seeking than they do on decoding: some effect on cache coherency, but absolutely no extra computation. There won't be any frames in the ref list that you wouldn't have to decode anyway just due to recursive dependencies on the first ref per frame.

I'm not quite sure the impact of Pyramid Bs; it probably varies quite a bit with content.
At best, pyramid could improve seeking speed, since it increases the optimal number of B-frames. At worst, your player might not skip B-frames anyway, so pyramid would have no effect. In between, x264's pyramid doesn't allow the decoder to skip B-refs, so seeking could be slower than non-pyramid.

[benwaggoner]

Reference frames have no more impact on seeking than they do on decoding: some effect on cache coherency, but absolutely no extra computation. There won't be any frames in the ref list that you wouldn't have to decode anyway just due to recursive dependencies on the first ref per frame.
I agree in theory, but in practice some decoders seem to have trouble doing random access with a lot of ref frames. Perhaps because they assume the first frame of each GOP is playable?

[akupenguin]

Perhaps because they assume the first frame of each GOP is playable?
If it isn't, then you have a weird definition of GOP. No matter whether you use IDR or open-GOP, and no matter whether you use multiref or not, you have to clear the ref list at the beginning of each GOP (after the first set of B-frames, in the case of open-GOP), otherwise seeking is impossible. If there's an I-frame that doesn't clear the ref list, then that's not a GOP boundary.
I can however believe in a buggy decoder that tries to seek to unseekable I-frames, and thus displays garbage until it gets to a real seekpoint. Or some other perverse behavior unrelated to the spec.