Slow h264 encoding for large-resolution, large bitrate videos

[mhmacleod]

I've been experimenting with the IPP evaluation kit for some time (6.1 update 2) to test its H264 capabilities for a unique purpose: encoding a series of large images. These images are upwards of 1600x1200 resolution.

However I encountered a unique situation: the higher I set the bitrate, the slower the encoding got. This is a priority for my purposes as I want to preserve the video's quality. Setting the encoding to 1000000bps (the default) made it go at a very slow rate of about 1-2 frames per second. Setting the flags to multiple threads also made difference at all. After examining the results through VLC player, the largest tolerable drop I could accept was to about half that bitrate, which was still too slow for comfort.

I'm suspecting I compiled the project wrongly somehow or set the wrong values in the parameters. Has anyone got any advice on such issues?

Here are the settings I used (I had to clip off some of the long comments to make this fit better):

/* CommentLine: H.264 Sequence.*/

D:/Test/IppH264/yuv2.yuv /* name of source files */

300 /* number of frames to encode */

1 11 0 /* 1(reserved) , N (# of frames in between I frames), IDR interval. */

3 0 /* Number of B frames between I (or P) and next P, treat B as a reference (only 0 is

2 1 0 /* num_ref_frames (2-16), minimum length of list1 for backward prediction (only 1 is

77 0 /* profile_idc (77-main, 100-high); level_idc (set 0 for automatic selection) (check that

1600 /* horizontal_size */

1200 /* vertical_size */

1 /* frame_rate_code [0,8] (0-30 fps,1-15 fps,2-24 fps,3-25 fps,4-30 fps,5-30 fps,6-50 fps,7-60

1 8 8 /* High profile: chroma_format_idc (0 - monochrom, 1 - 420, 2 - 422), bit_depth_luma [8,12],

0 8 0 0 0 /* High profile: aux_format_idc: [0,3], bit_depth_aux: [8,12], alpha_incr_flag: 0, 1;

2 0 0 0 1000000 /* RC method(0 - quant_codes, 1 - CBR MBwise, 2 - CBR framewise, 3 - Debug); start qp

0 1 8 8 /* ME method (1-6), subblock split, search x,search_y */

0 0 0 /* weighted prediction, weighted biprediction implicit weighted biprediction (not supported!)*/

2 0 /* direct type (0 - temporal 1 - spatial 2 - auto); direct_inference_flag */

0 0 0 /* disable_deblocking_idc: 1-- off, 0 - on, 2 -- on(without crossing slice boundaries);

0 0 0 /* High profile: transform_8x8_mode: 0 -- off, 1 - on; 0 -- use standard, 1 -- use default

1600 /* display_horizontal_size */

1200 /* display_vertical_size */

1 2 /* entropy coding mode (0-cavlc,1-cabac); cabac_init_idc (0,1,2) */

0 /* picture coding type (0 - only FRM, 1 - only FLD , 2 - only AFRM, 3 - pure PicAFF(no MBAFF) 4

3 0 /* speed/quality grade [0,3] (0-maximum speed, 3-maximum quality); OptimalQuantization (0,

[shyaki]

The H.264 has very high complexity than MPEG2 to achieve the hight compression efficiency.
You need a fast multi-core system and set the number of slices per frame accordingly.
You can disable deblocking and use cavlc instead of cabac.
You can try 0-maximum speed which will adjust the encoding parameters automatically.

[Tamer_Assad]

Hi mhmacleod, and welcome to Intel Software Network, IPP forum.

Please be aware that IPP video library does not utilize any GPU or video acceleration, it is performing completely on the CPU, with a highly optimized performance on Intel processors.

This means that the performance of your H.264 encoding operation is totally based upon your processor (latest Intel processor = Highest performance).

Also, you may try to reduce the processing amount in number of ways; for example, you are setting "Number of B frames between I (or P) " = 3

Well, reducing B frames usage will increase the result video stream size, but also it will reduce the processing load.

Best regards,

Tamer Assad

[Chao_Y_Intel]

Hello,

Also, the H.264 encoder is threaded with OpenMP*. You need to use the Compiler that can support OpenMP* to compile to threaded code. (Intel C++ Compiler, Microsoft* Visual C++*.NET* 2008, etc).

Thanks,

Chao

[andrewk88]

>>for a unique purpose: encoding a series of large images

Perhaps, your images are not highly correlated and difficult for efficient video compression by H.264 as you specify 15fps output framerate. Do you know what was a capture framerate? or perhaps you should try to specify a larger search_x + _y ranges to achieve a reasonable Motion Estimation convergence if your capture rate was <=15 fps. Fora higher speed of encoder I'd definitely reccomend todisable the subblock split at expense of higher bitrate/lower quality. Fianlly, if your content is really difficult to compress you may want to try INTRA/IDR encoding only and increase your bitrate (if you can afford). As said before using CAVLC is good if you care more about speed than bitrate/quality, but I'd probably keep deblocking ON for a better video quality unless your bitrate is really high like +10Mbps.

Hope it helps.

AndrewK

[mhmacleod]

Thank you! Lots of helpful comments here.

For clarification, my video was captured at a rate of about 14 fps but the final product will be even faster and bigger in resolution. Also, my CPU usage (3GHz Quad) was an average of 25% regardless of number of cores inputted...I suspect the encoding doesn't take number of cores into consideration and will see what I can do with OpenMP.

Unfortunately, I cannot sacrifice quality as my customers deem it paramount. The best I can do is increase bitrate (and thus size of the vid) but I don't understand why it takes longer to encode a (by my impression) less-compressed video.

So far the settings do boost speed but at a noticeable quality drop. As for the 'slices' setting, may I know what is deemed the 'appropriate' value? I can't seem to find references to it on the web.

[Tamer_Assad]

Hi mhmacleod,

OpenMP performs the multi threading.

So you need to consider:

1) Encoder threading; check the number of threads used and watch out for limitation.

2) Processor capabilities; Intel new processors powered by Hyper threading (more physical threads per core) and Turbo boost (Load-balancing among processor cores) such as Intel Core i7;

It makes sense, because the encoder is threaded, and it runs within your process (application), the CPU must not be too busy even if the encoders thread is, unless the encoders thread runs with a high priority.

More pixels = more processing. Note that, UMC are just examples, for a complete Intel implementation of video processing, you may consider Intel Media SDK, it is a higher level API, and allows these settings for H.264 encoder (among other components).

Regards.

Tamer Assad

[shyaki]

You need to set the number of slices per frame to be at least the number of the cores in your system, so that the encoder can encode them in parallel.

[mhmacleod]

I just spent some more time tweaking the codes, to no avail. Strange thing was, when I updated to the 6.1.5 update eval, the whole h264 functionality seemed to have been removed or stored away somewhere I couldn't find.

I also tried the Media SDK - the thing just blew me away! Full CPU utilization and speeds I've been looking for...with minimal settings too. Still, not sure if the lack of full settings is really a good thing. It seems to do what I'm looking for, but I searched a bit and can see it's still very new - little documentation or licensing details. If I were just to look at H264, would this be a viable solution over IPP? And where is IPP headed in this?

[Tamer_Assad]

Hi mhmacleod,

The IPP audio-video-codecs samples are contained within a separate IPP samples package ipp-samples_p_6.1.5.060.zip, you may try to locate it within the ISN; also, you may consult an expert from Intel in order to locate the appropriate download link location.

Intel Media SDK forum would be the right place for the media SDK issues and discussions. http://software.intel.com/en-us/forums/intel-media-sdk/

Regards,

Tamer Assad

[shyaki]

I don't think the Media SDK uses hardware-accelerated h.264 encoder now. It in fact just provide a user friendly API on top of the IPP.

The Media SDK may uses hardware-acceleration for h.264 decoding if your graphics card supports it, otherwise it calls the IPP too.