Low CPU usage about adobewebm HOT 9 CLOSED

If you use VP8, you'll see more CPU usage than VP9 generally. One factor in VP9 multi-threading is the --tile-columns parameter, although I should already be setting it to take advantage of all your cores.

The answer is mainly that Google's VP9 encoder doesn't do a great job at using all your CPU resources.

Tile columns info from vp8cx.h:

In encoding and decoding, VP9 allows an input image frame be partitioned
into separated vertical tile columns, which can be encoded or decoded
independently. This enables easy implementation of parallel encoding and
decoding. This control requests the encoder to use column tiles in
encoding an input frame, with number of tile columns (in Log2 unit) as
the parameter:
            0 = 1 tile column
            1 = 2 tile columns
            2 = 4 tile columns
            .....
            n = 2**n tile columns
The requested tile columns will be capped by encoder based on image size
limitation (The minimum width of a tile column is 256 pixel, the maximum
is 4096).

from adobewebm.

I tried setting --tile-columns=4 and --threads=11 but it still seemed to not have any impact, with CPU usage still below 10% most of the time on VBR. Am I doing something wrong this time around or is Google's encoder simply this bad at multi-threading?

I'm using a rather short clip (2mins 30secs) for these tests. Not sure if it matters, but I thought I should point it out.

from adobewebm.

What's your resolution? One limitation is that each tile-column has a minimum of 256 pixels, so if your video is 1024 pixels wide, the most tile-columns VP9 will use is 4 (which you would indicate using --tile-columns=2). To see how slow VP9 is without any multithreading, try --threads=1 --tile-columns=0. Using high numbers for threads and columns won't get you any more speed if you don't have the cores or your frames aren't big enough.

The length of the clip shouldn't matter much; a 2.5 minute clip should behave similarly to a 2.5 second clip in terms of the multiprocessing.

The encoder simply doesn't do as much multithreading as we'd like. Make sure you're using the latest release of the plug-in as Google has been working to improve in this area, although you still might not find it satisfactory.

from adobewebm.

I have version 1.0.2 of the plug-in and it's a 1080p (1920 pixels wide) clip.

I tried a few more experiments and also tried ffmpeg to see if there would be a difference, but no.
No settings appeared to have any effect. Then I disabled 2-pass encoding. Turns out the final pass uses some CPU (around 30% with threads, 10% without), but the first pass in a 2-pass encode is always below 10%, even with threads on. So I see an improvement, but for some reason the first pass is really inefficient... I don't know what the parameters are for the first pass that could cause this, though.

It's indeed not satisfactory, but I'm glad Google's working on it and that this plug-in makes the encoder so easy to use. I'll be keeping an eye on it, as I'd really like to be able to use a royalty-free codec. Thank you very much for your help.

from adobewebm.

Oh yeah, I'm not surprised the first pass uses less CPU. But then the second pass should take much longer anyway, so even if we were able to make the first pass take no time at all, the encode would still be very slow.

That said, the code for copying converting the Premiere buffers is not multithreaded right now. If it were, maybe the first pass would go faster.

from adobewebm.

It's also possible that your project is more I/O dependent. To really test the encoder speed, make a project that's just a test pattern or something.

from adobewebm.

I'd think that, instead of using less CPU, the first pass should just be way faster... :)
This all seems a bit non-intuitive.

I am only transcoding a h.264 file, so there shouldn't be I/O issues or any complicated Premiere project for Media Encoder to handle.

Although how long it takes is the most important consideration, not efficiently using the CPU is a problem when comparing to the speed of other encoders that do -- that is, given how long this takes on my CPU, I could use completely insane x264 settings so that the gains from VP9 would be minimal at the same speed (I gather that --cpu-use affects speed/quality?). If this could be four or five times faster (which sounds plausible given how much CPU is left idle), it'd be a compelling alternative.

I could do my own "multithreading" by encoding several files at the same time, but this has its own shortcomings.

from adobewebm.

The really important thing is how fast the video gets encoded, and at what quality. If you can somehow encode quickly without using much CPU, more power to you. But I assume VP9 doesn't do that. VP8 is a more fair comparison with H.264 though.

I think of VP9 as the choice for when your bit rate is set and you're hoping to get the most quality for that bitrate, regardless of the encoding time. If encoding time is more of a consideration, maybe up the bitrate and use VP8.

from adobewebm.

Yeah, that's the thing - it's veeery slow, that's why the low CPU usage is a problem. Wish it could just use more power and get it done faster.

I am trying to strike a balance between encoding time, quality and file size (we all are, certainly), but encoding time and quality are slightly more important than file size. So I won't be using VP9 unless I need something very specific with file size and h.265 is not an option.

Again, thank you very much for your help and insight. I'll keep an eye on updates and hope they improve the encoding speed for my hardware. Closing this issue for now as it's clear it's not a bug on your plugin.

Cheers.

from adobewebm.