Comparison VP9 encode time between libvpx v1.7.0 and v1.8.2+

[Jonathan Lenart]

Hello,

I have been experimenting with various versions of libvpx, for VP9 encoding, and have come across an interesting behavior that I am attempting to fully understand.

The setup is pretty minimalist, with a 1-minute video being encoded at 1280x720. This is done via two-pass, with the following flags set: "-threads 8 -cpu-used 2 -tile-columns 3 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25", and running ffmpeg 5.1 on an 8-core i9 (16 HT) laptop.

The resulting encode time across versions is a bit surprising. When using libvpx v.1.7.0 it is roughly 0.7X, but if using libvpx v1.8.2 (or above, all the way to v1.12.0), that drops down to 0.35X (2x the encode time). Addition of the "row-mt" flag bumps libvpx v1.7.0 to near real-time (~0.95X), and sees a slight decrease in encode time for libvpx v1.8.2+ as well (but still well under the 0.7X of v1.7.0 without the flag).

Would there have been a change between libvpx v1.7.0 and v1.8.2 which explains the significant increase in encode time?

Thank you,

    Jonathan

--

Jonathan Lenart

Staff Software Engineer | JWPLAYER

530 7th Ave., Ste. 1601
New York, NY 10018

[James Zern]

On Wed, Oct 26, 2022 at 1:15 PM 'Jonathan Lenart' via WebM Discussion <webm-d...@webmproject.org> wrote:

Hello,

I have been experimenting with various versions of libvpx, for VP9 encoding, and have come across an interesting behavior that I am attempting to fully understand.

The setup is pretty minimalist, with a 1-minute video being encoded at 1280x720. This is done via two-pass, with the following flags set: "-threads 8 -cpu-used 2 -tile-columns 3 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25", and running ffmpeg 5.1 on an 8-core i9 (16 HT) laptop.

The resulting encode time across versions is a bit surprising. When using libvpx v.1.7.0 it is roughly 0.7X, but if using libvpx v1.8.2 (or above, all the way to v1.12.0), that drops down to 0.35X (2x the encode time). Addition of the "row-mt" flag bumps libvpx v1.7.0 to near real-time (~0.95X), and sees a slight decrease in encode time for libvpx v1.8.2+ as well (but still well under the 0.7X of v1.7.0 without the flag).

Would there have been a change between libvpx v1.7.0 and v1.8.2 which explains the significant increase in encode time?

Thanks for the report. I haven't tried to reproduce this yet, but there can be changes between versions to the speed levels to enable or disable encoder tools. There may have been some changes to better balance the trade off between speed and quality across cpu-used levels, though this sounds a little extreme. I created https://crbug.com/webm/1784 to track this.

 

Thank you,

    Jonathan

--

Jonathan Lenart

Staff Software Engineer | JWPLAYER

530 7th Ave., Ste. 1601
New York, NY 10018

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webm-discuss/CAJywtm0spvOoDoS2nwMh-tROD_jX8Nv%2BCY24K%3DjT9BJCjHCD-g%40mail.gmail.com.

[John Luther]

Thanks, James! 👋🏻