#7 x264 only using 33% CPU

[Anonymous]

Hi there
I raised a support ticket a while ago because I was trying to use x264 vfw in Premiere Pro CS5 and was getting corruption - long story short I am now using CS6 and the problem is gone.

The weird thing is though that x264 vfw only uses around 33-36% CPU. It's like this in Premiere CS6 and also in Virtualdub. I have an i7 840QM CPU (4 cores/2 threads per core).

Is this normal? I tried adding --threads 8 into the command line but it did nothing. The x264 command line uses 100% CPU for me most of the time, but I'm just wondering about the VFW. Is it something to do with the one in, one out VFW limitation which means it can only run a certain amount of threads due to it needing the frames to be complete in a certain order?

If so, would there be any plans to add an option to output raw video compatible with the MP4 standard that can use all the cores?

[BugMaster]

If you have bad CPU utilization with x264vfw and good CPU utilization with x264 cli for same input video and same encoding params (i.e. presets and tunings like zerolatency and others). Than it probably mean some bottleneck before libx264 (which is used by x264vfw). Possible bottleneck is either input source decoding (x264 cli use integrated ffmpeg decoders) or other source filtering (I would say that is most probable reason) or colorspace conversion in x264vfw (but I doubt it can be bottleneck and at least with VirtualDub x264vfw most of the time gets already YUV input so colorspace conversion is minimal or skipped at all). As for raw output than there is "Output mode"="File" for the same output (h264/flv/mp4/mkv/avi) as x264 cli but I doubt it will help with CPU utilization (at least if CS6 doesn't make anything weird with VFW output).

[Anonymous]

Thanks for the quick reply. I believe you are right saying that it is the colour space conversion, because as I was encoding I suddenly remembered that video editing programs operate in the RGB colour space, which means the codec will have to do the conversion.

I managed to set up AVISynth to work with Premiere. So it was H.264 in MP4 being served with no processing to Premiere via AVISynth (been doing a lot of testing and it works out a bit faster than loading the MP4 directly into Premiere and using Premiere's decoders).

So I dropped the AVS file into Vdub 64bit and I was getting encode times of around 3 minutes for a 7 minute file, it wasn't using 100% CPU (something like between 60 and 80), but I was fine with it since it was faster than real time. I dropped the same AVS file into Premiere and used the same encode settings and it took almost 8 minutes. It was at this point that I remembered about the colour space conversion, so I set the mode in Virtualdub to full processing (as fast recompress avoids any colour space conversion), and sure enough, I got an encode that took around 8 minutes which is in line with how long Premiere was taking.

So it seems that I've pretty much hit the limit to what I can do now. Maybe playing around with decoder preferences to find the one that uses the lowest CPU might shave off a minute if I'm lucky, but I've already come really far thanks to your work and the work of the others (AVISynth team, Avery Lee etc). Here are some stats you might find interesting.

7m05s 720p 59.94 fps encode

CS5 (MP4 loaded directly, using Premiere H.264 codec @ 30mbps) = 16m07s
CS6 (MP4 loaded directly, using Premiere H.264 codec @ 30mbps) = 9m36s
CS6 (MP4 loaded directly, using x264 VFW (q16, ultra fast)) = 8m48s
CS6 (MP4 loaded with AVISynth, x264 VFW (q16, ultra fast)) = 7m47s

This is an amazing saving. The videos I output are tournament gameplay videos and they are around 6-7 minutes length on average, and for an event I can have usually between 20-35 such videos, so what took 9 hours to export would now only take around 4.5!

I can't thank you enough. Take care.