How to generate with x264 bitstreams to stress decoder.

[pandy]

So i'm searching for information's about syntax that can be used with x264 to produce bitstreams to stress h.264 decoder (power consumption/processing power). I'm aware that various decoders can behave in a different way thus i see this question more like open discussion which part/s of h.264 seem to be most demanding from decoder perspective and how to recreate this kind situation with x264.
Thank You in Advance.

[LoRd_MuldeR]

For example, use CABAC and crank up the bitrate.

[Dark Shikari]

There's some stress tests in the official conformance suite, e.g. ones that force the worst-possible hpel position with the maximum number of partitions per macroblock in bidir mode and so forth.

You'd have to hack x264's code to get it to generate something that horrific.

[nhakobian]

There's some stress tests in the official conformance suite, e.g. ones that force the worst-possible hpel position with the maximum number of partitions per macroblock in bidir mode and so forth.


Out of curiousity, are these cases that x264 actively attempts to avoid, or are these just very, very, unlikely to occur under average/common conditions?

[Dark Shikari]

They're not unlikely to occur (the worst possible hpel position is 1 in 16 MVs, roughly, for example), they're just not usually forced to occur 100% of the time.

[pandy]

Thx guys,
CABAC and high bitrate of course at first place, but i have hope that there is magic trick to set in x264 to stress particular areas more even if overall quality suffer (some settings can be not logical from bit allocation but more demanding from a system).
I just want to compare power consumption and utilization for few different decoders.

And for sure i will not modify x264 code.

[SeeMoreDigital]

I've recently been trying to find out what settings 'stress-out' Quicktime player when it's 'Video preferences' is set to 'Safe Mode (GDI Only).

I can't work out why some x264 generated encodes play okay, while others cause the player to stutter...

[pandy]

I've recently been trying to find out what settings 'stress-out' Quicktime player when it's 'Video preferences' is set to 'Safe Mode (GDI Only).

I can't work out why some x264 generated encodes play okay, while others cause the player to stutter...

Hmm i've noticed recently strong stutter in one case - "Tallship_720x576i_1500kbps_25fps_High_at_L3.1_DifficultEdge.mp4" - part of Windows HCK for DXVA - http://msdn.microsoft.com/en-us/library/windows/hardware/dn383615

but i have no time to analyze why this happen (perhaps PAFF?)

[LoRd_MuldeR]

I've recently been trying to find out what settings 'stress-out' Quicktime player when it's 'Video preferences' is set to 'Safe Mode (GDI Only).

I can't work out why some x264 generated encodes play okay, while others cause the player to stutter...

Sounds to me like this option is more concerned with how the decoded frames are displayed to the screen, rather than how the source is decoded :confused:

...unless, of course, QuickTime uses "hardware accelerated" video decoding by default and falls back to pure software decoding when "Safe Mode (GDI Only)" is selected.

But if that's not the case, I think it's quite possible that the problem is simply that the "GDI" video renderer cannot output the decoded video frames "smoothly".

(Honestly, QuickTime player is the most "sluggish" video playback I've ever used on a PC. Don't know how it feels on a Mac, but on a PC you pretty much can't use it)

[SeeMoreDigital]

After several hours of generating x264 encodes using different encoding options I think I've finally discovered the x264 encoding option that Quicktime player (in 'Safe Mode (GDI Only)') does not like.... And it's 'Weighted Prediction for P-frames' (ie: weightp=1).

So, how many people knew that then (but could not tell me)?

[benwaggoner]

I've recently been trying to find out what settings 'stress-out' Quicktime player when it's 'Video preferences' is set to 'Safe Mode (GDI Only).

I can't work out why some x264 generated encodes play okay, while others cause the player to stutter...
Going to GDI only mainly forces software scaling and color conversion. It'll add overall CPU stress, to playback, but that would be orthogonal to codec decode complexity.

If you're using QuickTime for Windows, lots of stuff can break its software H.264 decoder. High profile with lots of reference and B-frames can mess up horribly, even though the file is still well within spec and will play fine in WMP, VLC, or other players on the same system.

Basically, just don't use QuickTime to decode H.264 content whenever avoidable, particularly on Windows. QuickTime on Mac is much more up to date, and has supported HW decode in hardware shipped in the last 4-5 years.

[SeeMoreDigital]

Basically, just don't use QuickTime to decode H.264 content whenever avoidable, particularly on Windows. QuickTime on Mac is much more up to date, and has supported HW decode in hardware shipped in the last 4-5 years.The decision to use Quicktime was my clients at the time (several years ago). Primarily because it offered better video playback compatibility within web browsers.

I guess I must have been lucky because I stumbled upon AutoMKV (with x264 core 66 r1092 60f4cd8) and discovered that it's basic encoding options were able to generate encodes that were perfectly compatible with Quicktime player (in 'Safe Mode (GDI Only)'). Once the .MP4 contained files were re-muxed into the .MOV container.

A couple of years ago I tried using TX264 (with x264 core 135 r2345 f0c1c53) to generate, what I'd hoped, would be Quicktime compatible encodes too. But they would not play correctly at all. So, every now and again I've tried to work out why!

But given I'm not an h.264 video programmer (like many of you guys) it's been a case of selecting encoding options 'one option at a time' in an effort to see which one (or ones) make Quicktime player unstable.

Of-course, things have moved on now, as you don't need Quicktime or the .mov container to play h.264 video within web browsers. So all of the above is pretty pointless.

For me, it was just a case of discovering why some h.264 files would play in Quicktime player and some would not.

By-the-way, I'd still like to know what the optimum x264 settings for Quicktime player (in 'Safe Mode (GDI Only)') are?


Cheers

[benwaggoner]

By-the-way, I'd still like to know what the optimum x264 settings for Quicktime player (in 'Safe Mode (GDI Only)') are?

It's really what the best performance is. The GDI will make things worse, but orthogonally to the decoder. Unless these are ancient machines, that setting shouldn't be required on anything anyone could buy for at least a half-decade unless you're using remote desktop or something.

For QuickTime, I'd suggest using Main Profile and don't use reference B-frames. That seems to fix most issues. Also, maybe max 4 ref and 4 B-frames.

[SeeMoreDigital]

Thanks Ben,

If you or anyone else is interested. Here's an example of an (video only) AVC.mp4 encode that Works fine with QT7 - Generated using AutoMKV (http://www.sendspace.com/file/qcp48t).

Cheers

[pandy]

And it's 'Weighted Prediction for P-frames' (ie: weightp=1).

So, how many people knew that then (but could not tell me)?

Isn't this widely recommended as to be avoided for hardware decoders (older generation like those STM based - i mean old Delta Mu ST231)?

[benwaggoner]

Isn't this widely recommended as to be avoided for hardware decoders (older generation like those STM based - i mean old Delta Mu ST231)?
Sure, which is why I avoid devices with those limitations like the plague. But QuickTime for Windows is software only.

[SeeMoreDigital]

Out of interest...

How much information can be revealed about the encoding options that were used to generate an h.264 stream?


Cheers