ffmpeg / vp9 advice.

[osgZach]

Hi,

I'm guessing this would be the right place for this question, but I'm just getting my feet wet with VP9, trying to see what I can get out of it and such.

Right now I'm using ffmpeg / libvpx and I'm trying to understand why my CPU usage appears to be so low. Assuming this is not an erroneous assumption based on what I'm seeing via Windows CPU usage graph and some different settings I've tried.

Basically on both my i5 and my FX8320 I never see the CPU meter ramp up to 99% etc. On my i5 (quad core) it hits about 50% with around equal usage on all 4 cores, sometimes one or two might spike up a little higher. Virtually the same on my FX8320 (8 cores, yes I know 4 of them are "virtual"). Although on my FX8320 its more like 25% and I'll see see high-end activity spikes on 3 out of the 8 CPU graphs.

I've tried raising -thread and lowering it and nothing really changes there, I get a consistent FPS of about 10 - 12 on my second pass encoding run on both machines.

The only major divergence I have seen is that for whatever reason, when I do a fast first pass (speed 4) on the i5 it hums along and levels out around 125fps or so. On my FX8320 though it chugs along much much slower, at around half speed or less. I'm not sure why that would be either.

So this is what I see on the FX8320 while running the current encode that is going at around 10 - 12 FPS

http://i.imgur.com/hUK5jbv.png

The file used for input is a UTCodec lossless AVI, with a resolution of 864x486. Target bitrate is 750Kbps. There is no audio track.


The command lines I am using are pretty much verbatim this page
http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

using the VOD listing.

I'm really trying to go for very good quality, while still keeping a fast encode speed, and the aim is I'm trying to find something that produces smaller files than x264 can at the same quality level I'm aiming for.

HEVC/x265 is nice (on the limited Anime tests I did) and encodes a lot faster, but has virtually no real web-browser / streaming support and that's really what I'm looking for here. It's more of a "low bandwidth access to my library" kind of thing I guess.

Right now its kind of an academic / curiosity thing. So if anyone can offer advice on tweaks to flags and such I can try, it would help me out a lot. I'm not very good at parsing documentation as half the descriptions just read like tech jargon to me and I don't really understand their relationship to performance/quality etc.

[Selur]

Right now I'm using ffmpeg / libvpx and I'm trying to understand why my CPU usage appears to be so low.
vp9 isn't that optimized for multithreading and is known to no utilize the cpu that well with one encoding,... (to be fair multithreading has become better, but it's nowhere near x264 or x265)

[osgZach]

ok I was afraid of that. Thanks

[mandarinka]

If you can, split the encode into 8 parts and combine the streams after the act. That is probably only way to get decent "threading". Their encoding implementation AFAIK uses tiles which has detrimental effect on quality of the result (similar to slice threads if not worse).

[BadFrame]

I'm not running ffmpeg but instead the 'official' encoder (vpxenc) and from my tests cpu utilization is very dependant on source resolution, for example on a 1316x720 clip I get ~88% cpu utilization on a core i5 (4 cores), but on a 958x720 clip I only get ~46-48% .

[mandarinka]

IIRC the tiles in VP9 are split vertically, so the encoder might be using less of them if your horizontal resolution is lower (some minimum width for the tile being enforced?). That is just a guess though, I didn't investigate this.

[osgZach]

Yeah I didn't say anything before but I noticed that as well. Once I started doing higher resolution tests, I noticed an increase in the CPU usage.

[pieter3d]

Tiles in VP9 must be at least 256 pixels wide, and a power of two amount. So, you can have at most two.

[benwaggoner]

IIRC the tiles in VP9 are split vertically, so the encoder might be using less of them if your horizontal resolution is lower (some minimum width for the tile being enforced?). That is just a guess though, I didn't investigate this.
Which probably makes it worse than slices, as statistically there is lot more horizontal than vertical motion in typical content. All those horizontal pans...

[pieter3d]

VP9 doesn't do entropy adaption within the frame, so you don't get as big a loss from tiles as you do in HEVC. Motion vector prediction however, does get broken by the tile boundary, so they aren't free. In VP9 the loopfilter ignores tile boundaries, and motion vectors values have no restrictions that depend on tile boundaries. In my testing, the coding efficiency penalty associated with tiles isn't very high at all.

Tiles are much cheaper than slices since you don't have to send a slice header over and over (with largely the same content).

[benwaggoner]

VP9 doesn't do entropy adaption within the frame, so you don't get as big a loss from tiles as you do in HEVC. Motion vector prediction however, does get broken by the tile boundary, so they aren't free. In VP9 the loopfilter ignores tile boundaries, and motion vectors values have no restrictions that depend on tile boundaries. In my testing, the coding efficiency penalty associated with tiles isn't very high at all.
Well, that's good. Keeping entropy decoding context would help a lot (although it seems like that would limit parallelism for encode and decode).

I'd worry about the motion vector prediction when doing horizontal pans, but if it's only every 256 rows, and each slice is able to reference any part of its reference frames, that shouldn't be too bad. With most scripted 24p content, horizontal pans aren't too hard to encode anyway with all that motion blur. High shutter speed sports might be where this could come in.

[XaLBa]

IIRC the tiles in VP9 are split vertically, so the encoder might be using less of them if your horizontal resolution is lower (some minimum width for the tile being enforced?). That is just a guess though, I didn't investigate this.

Yes, this is exactly it. Encoder utilizes tile threading, and minimum tile width is 256 pixels. Also tile number must be a power of 2.

So encoder may begin to use 4 tiles on at least 1024 pixels. 958 is close, but still 2 tiles.