VP9 encoding takes about 5x as much time as transcoding with ffmpeg #95743

New Issue

doggon · 2022-02-13T12:01:28+01:00

doggon commented

2022-02-13 12:01:28 +01:00

System Information
Operating system: Arch Linux
Graphics card: Nvidia 1080

Blender Version
Broken: probably all versions

Steps to reproduce
trailer.blend
Video: F13163407

Open file
Render animation

Compare render time to `ffmpeg -loglevel 58 -y -i in.mp4 -ss 0 -to 0.5 -c:a libopus -b:a 128000 -c:v libvpx-vp9 -deadline best -b:v 3472630 out-ffmpeg.webm`

There is significant difference: 30s with ffmpeg vs. 200s with Blender

Also see codec settings for comparison:
P3006 vs. P3005

**System Information** Operating system: Arch Linux Graphics card: Nvidia 1080 **Blender Version** Broken: probably all versions **Steps to reproduce** [trailer.blend](https://archive.blender.org/developer/F13163405/trailer.blend) Video: [F13163407](https://archive.blender.org/developer/F13163407/in.MP4) - Open file - Render animation # Compare render time to `ffmpeg -loglevel 58 -y -i in.mp4 -ss 0 -to 0.5 -c:a libopus -b:a 128000 -c:v libvpx-vp9 -deadline best -b:v 3472630 out-ffmpeg.webm` There is significant difference: 30s with ffmpeg vs. 200s with Blender ---- Also see codec settings for comparison: [P3006](https://archive.blender.org/developer/P3006.txt) vs. [P3005](https://archive.blender.org/developer/P3005.txt)

doggon commented

2022-02-13 12:01:28 +01:00

Added subscriber: @lolpb

Germano Cavalcante commented

2022-02-15 16:08:33 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-02-15 16:08:33 +01:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Germano Cavalcante commented

2022-02-15 16:08:33 +01:00

4 hours vs 11 minutes is actually a big difference. But I don't think this can be confirmed as a bug.

The developers are aware of the limitations and are continuously working to improve performance and other aspects of the video editor.

But due to the difference, I am forwarded to the #vfx_video team in the possibility of a bug.

4 hours vs 11 minutes is actually a big difference. But I don't think this can be confirmed as a bug. The developers are aware of the limitations and are continuously working to improve performance and other aspects of the video editor. But due to the difference, I am forwarded to the #vfx_video team in the possibility of a bug.

Richard Antalik commented

2022-02-15 16:25:41 +01:00

Added subscriber: @iss

Richard Antalik commented

2022-02-15 16:25:41 +01:00

Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'

Richard Antalik commented

2022-02-15 16:25:41 +01:00

If I understand correctly, you render 60 seconds at 60fps ant the process takes 4 hours? That shouldn't happen.

You say Broken: untested - what does this mean? Or did you mean that 3.1.0 is broken?
I need to fully reproduce this issue here, so first thing I need is .blend file. Issue could be with input movie file too, so I will need that as well unless this happens even with generator strip like color or text.

Here rendering took about 11 minutes

If I understand correctly, you render 60 seconds at 60fps ant the process takes 4 hours? That shouldn't happen. You say `Broken: untested` - what does this mean? Or did you mean that 3.1.0 is broken? I need to fully reproduce this issue here, so first thing I need is .blend file. Issue could be with input movie file too, so I will need that as well unless this happens even with generator strip like color or text. Here rendering took about 11 minutes

doggon commented

2022-02-15 16:59:38 +01:00

By broken I mean that didn't test any Blender version where the video didn't render, because really only tested 3.1.0 Beta.
Rendering 60 seconds of playtime at 60 fps takes 4 hours to render, not 60 seconds to render, hope I express myself properly.
Also, time would depend on CPU. Mine is Intel 6700HQ. Will add examples as soon as I can, but can't promise anything soon.

In any case, it should happen the same with any example I guess...

By broken I mean that didn't test any Blender version where the video didn't render, because really only tested 3.1.0 Beta. Rendering 60 seconds of playtime at 60 fps takes 4 hours to render, not 60 seconds to render, hope I express myself properly. Also, time would depend on CPU. Mine is Intel 6700HQ. Will add examples as soon as I can, but can't promise anything soon. In any case, it should happen the same with any example I guess...

Richard Antalik commented

2022-02-16 15:06:25 +01:00

Yes, performance will depend on CPU, but I don't think it would be that slow even with sinlge core CPU. After 8 cores, returns seem to be diminishing anyway at least with full hd media.

doggon commented

2022-02-18 21:49:02 +01:00

Here are all the source, project and result files.
Rendering out-ffmpeg.webm with ffmpeg takes 2m 11s.
Rendering 0001-0600.webm with Blender takes 31m 20s and has double video bitrate than requested in UI settings (about 8Mbps instead of 4Mbps aproximately).
Folder BL_proxy is removed due to large size.

https://mega.nz/folder/UAN0BDQY#AtnS2aW7FaUWLMzyick-Qw

Here are all the source, project and result files. Rendering `out-ffmpeg.webm` with `ffmpeg` takes `2m 11s`. Rendering `0001-0600.webm` with `Blender` takes `31m 20s` and has double video bitrate than requested in UI settings (about 8Mbps instead of 4Mbps aproximately). Folder `BL_proxy` is removed due to large size. https://mega.nz/folder/UAN0BDQY#AtnS2aW7FaUWLMzyick-Qw

Richard Antalik commented

2022-02-20 17:37:37 +01:00

Changed status from 'Needs User Info' to: 'Confirmed'

Richard Antalik commented

2022-02-20 17:37:37 +01:00

Can confirm this looks to be quite slow. From quick look I see this is caused by particular output settings. If I render with default settings for VSE it's much faster. In provided ffmpeg script you did not specify -deadline best option. This is equivalent to slowest encoding speed option in Blender. By default ffmpeg will use "Good" encoding speed.

Checking with good speed, it took 1 minute to complete render with ffmpeg. Blender did complete in 4.5 minutes. Not great, but much better than 30 minutes.
With slowest speed, it took 5 minutes to complete render with ffmpeg. Blender did complete in 25.5 minutes. So there is still significant difference which may be worth investigating.

This seems to be specific to vp9 codec. H264 with sampe settings was done in 20 seconds. So I assume this is a bug

Can confirm this looks to be quite slow. From quick look I see this is caused by particular output settings. If I render with default settings for VSE it's much faster. In provided ffmpeg script you did not specify `-deadline best` option. This is equivalent to slowest encoding speed option in Blender. By default ffmpeg will use "Good" encoding speed. Checking with good speed, it took 1 minute to complete render with ffmpeg. Blender did complete in 4.5 minutes. Not great, but much better than 30 minutes. With slowest speed, it took 5 minutes to complete render with ffmpeg. Blender did complete in 25.5 minutes. So there is still significant difference which may be worth investigating. This seems to be specific to vp9 codec. H264 with sampe settings was done in 20 seconds. So I assume this is a bug

doggon commented

2022-02-20 18:02:47 +01:00

New test with ffmpeg, my believe was that ffmpeg used best encoding speed by default:

Default: 2m 15s
-deadline best: 12m 8s

New test with ffmpeg, my believe was that ffmpeg used best encoding speed by default: - Default: 2m 15s - `-deadline best`: 12m 8s

doggon commented

2022-02-20 18:21:17 +01:00

Also would like to know why rendered video in Blender does not meet set bitrate, so size is much bigger than desired. Any clue why it's so difficult to set?

Evan Wilson commented

2022-02-21 11:09:07 +01:00

Added subscriber: @EAW

Evan Wilson commented

2022-02-21 11:09:07 +01:00

It appears that VP9 encoding times and sizes vary wildly based upon encoding settings.

Here is a table of 19 different encodings of the same 80 second 1080p clip that took between 1 and 131 minutes to complete, resulting in file sizes ranging between 4.4MB and 1.06GB
https://developers.google.com/media/vp9/bitrate-modes#results

The line graph on the following page shows the relative difference between each encoding speed, with speed 1 (the second slowest) only taking 44% of the time as the slowest speed setting of 0.
https://streaminglearningcenter.com/codecs/encoding-vp9-in-ffmpeg-an-update.html

And here are some charts showing that VP9 and x265 taking 12.5x and 16x times longer to encode compared to x254, which fits with your 20 second x264 vs 4.5 minute VP9 @ISS. Getting that compression down to half the size just takes longer.
https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Good-News-AV1-Encoding-Times-Drop-to-Near-Reasonable-Levels-130284.aspx

In #95743#1310762, @lolpb wrote:
Also would like to know why rendered video in Blender does not meet set bitrate, so size is much bigger than desired. Any clue why it's so difficult to set?

I am guessing that this is due to the settings that Blender is sending to FFMpeg. It might be that they are more generalized to the x264 specification people are used to using, and not the particular VP9 only settings that VP9 needs to be performant.

It appears that VP9 encoding times and sizes vary wildly based upon encoding settings. Here is a table of 19 different encodings of the same 80 second 1080p clip that took between 1 and 131 minutes to complete, resulting in file sizes ranging between 4.4MB and 1.06GB https://developers.google.com/media/vp9/bitrate-modes#results The line graph on the following page shows the relative difference between each encoding speed, with speed 1 (the second slowest) only taking 44% of the time as the slowest speed setting of 0. https://streaminglearningcenter.com/codecs/encoding-vp9-in-ffmpeg-an-update.html And here are some charts showing that VP9 and x265 taking 12.5x and 16x times longer to encode compared to x254, which fits with your 20 second x264 vs 4.5 minute VP9 @ISS. Getting that compression down to half the size just takes longer. https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Good-News-AV1-Encoding-Times-Drop-to-Near-Reasonable-Levels-130284.aspx > In #95743#1310762, @lolpb wrote: > Also would like to know why rendered video in Blender does not meet set bitrate, so size is much bigger than desired. Any clue why it's so difficult to set? I am guessing that this is due to the settings that Blender is sending to FFMpeg. It might be that they are more generalized to the x264 specification people are used to using, and not the particular VP9 only settings that VP9 needs to be performant.

doggon commented

2022-02-22 13:22:13 +01:00

In #95743#1311097, @EAW wrote:
And here are some charts showing that VP9 and x265 taking 12.5x and 16x times longer to encode compared to x254, which fits with your 20 second x264 vs 4.5 minute VP9 @ISS. Getting that compression down to half the size just takes longer.

Do you mean x264 not x254?
The reason to use VP9/Opus is that web browsers except Edge don't have licenses to play H.265 media embedded in websites due to pantents. Also other H.264 / WMV/WMA+DRM etc. may have similar issues.

> In #95743#1311097, @EAW wrote: > And here are some charts showing that VP9 and x265 taking 12.5x and 16x times longer to encode compared to x254, which fits with your 20 second x264 vs 4.5 minute VP9 @ISS. Getting that compression down to half the size just takes longer. Do you mean x264 not x254? The reason to use VP9/Opus is that web browsers except Edge don't have licenses to play H.265 media embedded in websites due to pantents. Also other H.264 / WMV/WMA+DRM etc. may have similar issues. - [HEVC H.265 codec support ](https://www.reddit.com/r/firefox/comments/gs4n78/hevc_h265_codec_support/) - [Why are FFmpeg and mpv allowed to use HEVC decoders but Firefox and Chrome are not? ](https://www.quora.com/Why-are-FFmpeg-and-mpv-allowed-to-use-HEVC-decoders-but-Firefox-and-Chrome-are-not)

Richard Antalik commented

2022-06-13 22:25:04 +02:00

Checked this report again, I don't see any codec parameter causing time difference, so issue may be with general ffmpeg settings, but that I would not consider to be a bug. So will change classification to known issue.

As workaround I would avoid using slowest VP9 encoding speed if encoding time is concern.

Perhaps with "good" speed, there is another parameter "speed" that can be set within range 0-5 that can improve performance (with penalties in quality of course), but ffmpeg default is 0 and so I don't think this is necessary. If you need such precise encoder control, it's probably best to render images and use ffmpeg with manual setup.

Checked this report again, I don't see any codec parameter causing time difference, so issue may be with general ffmpeg settings, but that I would not consider to be a bug. So will change classification to known issue. As workaround I would avoid using slowest VP9 encoding speed if encoding time is concern. Perhaps with "good" speed, there is another parameter "speed" that can be set within range 0-5 that can improve performance (with penalties in quality of course), but ffmpeg default is 0 and so I don't think this is necessary. If you need such precise encoder control, it's probably best to render images and use ffmpeg with manual setup.

doggon commented

2022-06-14 00:39:01 +02:00

Thanks for the follow-up.

Richard Antalik changed title from ~~Video render works but takes an awful amount of time~~ to VP9 encoding takes about 5x as much time as transcoding with ffmpeg

2022-06-14 17:55:17 +02:00

Hamdi Ozbayburtlu was assigned by Richard Antalik

2022-06-14 18:14:18 +02:00

Richard Antalik commented

2022-06-14 18:14:18 +02:00

Added subscriber: @hamdio

Richard Antalik commented

2022-06-14 18:14:18 +02:00

Assigning to @hamdio, I have updated description to include simple reproducible case and codec settings in use. Could have left the note, that there is not as dramatic difference with h264 for example, so feel free to investigate.

Hamdi Ozbayburtlu commented

2022-06-15 14:23:26 +02:00

The buffer mode and rate control settings seems to be the issue here, when encoding in blender it's:

[libvpx-vp9 @ 000001bf2b2b8800] decoder buffer model
  rc_buf_sz:                    528
  rc_buf_initial_sz:            396
  rc_buf_optimal_sz:            440
[libvpx-vp9 @ 000001bf2b2b8800] 2 pass rate control settings
  rc_2pass_vbr_bias_pct:        50
  rc_2pass_vbr_minsection_pct:  0
  rc_2pass_vbr_maxsection_pct:  100

while ffmpeg defaults are:

[libvpx-vp9 @ 000001e977f3cfc0] decoder buffer model
  rc_buf_sz:                    6000
  rc_buf_initial_sz:            4000
  rc_buf_optimal_sz:            5000
[libvpx-vp9 @ 000001e977f3cfc0] 2 pass rate control settings
  rc_2pass_vbr_bias_pct:        50
  rc_2pass_vbr_minsection_pct:  0
  rc_2pass_vbr_maxsection_pct:  2000

So possibly blender uses incompatible or irrelevant defaults for vp9.

I also realised libvpx has been compiled without multithread and avx support:

[libvpx-vp9 @ 00000241b808a6c0] --prefix=E:/db25/build/S/VS1564R/Release/vpx --disable-shared --enable-static --disable-install-bins --disable-install-srcs --disable-sse4_1 --disable-sse3 --disable-ssse3 --disable-avx --disable-avx2 --disable-unit-tests --disable-examples --enable-vp8 --enable-vp9 --target=x86_64-win64-gcc --disable-multithread

vs what I've for ffmpeg in wsl:

[libvpx-vp9 @ 0x557c9b345b00] --prefix=/usr --enable-pic --enable-shared --disable-install-bins --disable-install-srcs --size-limit=16384x16384 --enable-postproc --enable-multi-res-encoding --enable-temporal-denoising --enable-vp9-temporal-denoising --enable-vp9-postproc --target=x86_64-linux-gcc

I'll try to recompile blender's avcodec lib in my local and investigate further the codec option default causing buffer/rc difference,

The buffer mode and rate control settings seems to be the issue here, when encoding in blender it's: ``` [libvpx-vp9 @ 000001bf2b2b8800] decoder buffer model rc_buf_sz: 528 rc_buf_initial_sz: 396 rc_buf_optimal_sz: 440 [libvpx-vp9 @ 000001bf2b2b8800] 2 pass rate control settings rc_2pass_vbr_bias_pct: 50 rc_2pass_vbr_minsection_pct: 0 rc_2pass_vbr_maxsection_pct: 100 ``` while ffmpeg defaults are: ``` [libvpx-vp9 @ 000001e977f3cfc0] decoder buffer model rc_buf_sz: 6000 rc_buf_initial_sz: 4000 rc_buf_optimal_sz: 5000 [libvpx-vp9 @ 000001e977f3cfc0] 2 pass rate control settings rc_2pass_vbr_bias_pct: 50 rc_2pass_vbr_minsection_pct: 0 rc_2pass_vbr_maxsection_pct: 2000 ``` So possibly blender uses incompatible or irrelevant defaults for vp9. I also realised `libvpx` has been compiled without multithread and avx support: ``` [libvpx-vp9 @ 00000241b808a6c0] --prefix=E:/db25/build/S/VS1564R/Release/vpx --disable-shared --enable-static --disable-install-bins --disable-install-srcs --disable-sse4_1 --disable-sse3 --disable-ssse3 --disable-avx --disable-avx2 --disable-unit-tests --disable-examples --enable-vp8 --enable-vp9 --target=x86_64-win64-gcc --disable-multithread ``` vs what I've for ffmpeg in wsl: ``` [libvpx-vp9 @ 0x557c9b345b00] --prefix=/usr --enable-pic --enable-shared --disable-install-bins --disable-install-srcs --size-limit=16384x16384 --enable-postproc --enable-multi-res-encoding --enable-temporal-denoising --enable-vp9-temporal-denoising --enable-vp9-postproc --target=x86_64-linux-gcc ``` I'll try to recompile blender's avcodec lib in my local and investigate further the codec option default causing buffer/rc difference,

Ray molenkamp commented

2022-06-15 16:59:15 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2022-06-15 16:59:15 +02:00

took a closer look, it does the right thing for exotic instruction support, so that we could enable, still have to check why threading was disabled.

Richard Antalik commented

2022-06-15 17:33:57 +02:00

@hamdio Thanks for checking, do you know how to change buffer parameters? I tried to pass some arguments, but I wasn't able to change the numbers. Also I have read, that this should only define interval in which codec checks if specified bitrate specs are met, so did not think, that it can have much effect...

Good idea to check compile settings, I did not pay much attention, because I thought I won't understand implications eh.

@hamdio Thanks for checking, do you know how to change buffer parameters? I tried to pass some arguments, but I wasn't able to change the numbers. Also I have read, that this should only define interval in which codec checks if specified bitrate specs are met, so did not think, that it can have much effect... Good idea to check compile settings, I did not pay much attention, because I thought I won't understand implications eh.

Hamdi Ozbayburtlu commented

2022-06-15 18:16:10 +02:00

hmm, I also don't know exactly what param in ffmpeg sets libvpx for that buffer/rate-control settings, still it'd be good to understand the difference. will read ffmpeg code/investigate that.
but thanks to @LazyDodo I've tested with a re-compiled libs:

[libvpx-vp9 @ 00000265ce745380] --prefix=E:/db25/build/S/VS1564R/Release/vpx --disable-shared --enable-static --disable-install-bins --disable-install-srcs --enable-sse4_1 --enable-sse3 --enable-ssse3 --enable-avx --enable-avx2 --disable-unit-tests --disable-examples --enable-vp8 --enable-vp9 --target=x86_64-win64-gcc

and even with the same buffer/rate-control settings, it's definitely much more faster. To put the numbers here can I ask the method you did the time measurements above.

hmm, I also don't know exactly what param in ffmpeg sets libvpx for that buffer/rate-control settings, still it'd be good to understand the difference. will read ffmpeg code/investigate that. but thanks to @LazyDodo I've tested with a re-compiled libs: ``` [libvpx-vp9 @ 00000265ce745380] --prefix=E:/db25/build/S/VS1564R/Release/vpx --disable-shared --enable-static --disable-install-bins --disable-install-srcs --enable-sse4_1 --enable-sse3 --enable-ssse3 --enable-avx --enable-avx2 --disable-unit-tests --disable-examples --enable-vp8 --enable-vp9 --target=x86_64-win64-gcc ``` and even with the same buffer/rate-control settings, it's definitely much more faster. To put the numbers here can I ask the method you did the time measurements above.

Hamdi Ozbayburtlu commented

2022-06-16 15:03:21 +02:00

Just measured the time spend between BKE_ffmpeg_start and BKE_ffmpeg_end throughout the rendering and here are the results by only changing the ffmpeg libs with multithread and avx enabled libvpx.

On a laptop with i9-10980HK (8 Cores and 16G Ram), using a17f74ab341b026387fef6b741e3c0901780526c:

with precompiled win64_vc15/ffmpeg
- rendering took 21.471000 seconds to render frames
- rendering took 153.077000 seconds to finalize, close ffmpeg and flush video frames
with ffmpeg compiled with multithreading and avx support (--enable-sse4_1 --enable-sse3 --enable-ssse3 --enable-avx --enable-avx2 --disable-unit-tests --disable-examples --enable-vp8 --enable-vp9 --target=x86_64-win64-gcc):
- rendering took 8.055000 seconds to render frames
- rendering took 39.078000 seconds to finalize, close ffmpeg and flush video frames
ffmpeg command (time ffmpeg -loglevel 58 -y -i in.mp4 -ss 0 -to 0.5 -c:a libopus -b:a 128000 -c:v libvpx-vp9 -deadline best -b:v 3472630 out-ffmpeg.webm) on the same system
- real 0m36.218s

So enabling multithreading for libvpx seems to be helping this vp9 performance issue. Which is already on the TODO list for next release.

Just measured the time spend between `BKE_ffmpeg_start` and `BKE_ffmpeg_end` throughout the rendering and here are the results by only changing the ffmpeg libs with multithread and avx enabled libvpx. On a laptop with `i9-10980HK` (8 Cores and 16G Ram), using a17f74ab341b026387fef6b741e3c0901780526c: - with precompiled [win64_vc15/ffmpeg ](https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15/ffmpeg/) - rendering took **21.471000** seconds to render frames - rendering took **153.077000** seconds to finalize, close ffmpeg and flush video frames - with ffmpeg compiled with multithreading and avx support (`--enable-sse4_1 --enable-sse3 --enable-ssse3 --enable-avx --enable-avx2 --disable-unit-tests --disable-examples --enable-vp8 --enable-vp9 --target=x86_64-win64-gcc`): - rendering took **8.055000** seconds to render frames - rendering took **39.078000** seconds to finalize, close ffmpeg and flush video frames - ffmpeg command (`time ffmpeg -loglevel 58 -y -i in.mp4 -ss 0 -to 0.5 -c:a libopus -b:a 128000 -c:v libvpx-vp9 -deadline best -b:v 3472630 out-ffmpeg.webm`) on the same system - real 0m**36.218s** So enabling multithreading for libvpx seems to be helping this vp9 performance issue. Which is already on the TODO list for next release.

Hamdi Ozbayburtlu commented

2022-06-16 16:46:14 +02:00

@iss I can confirm blender is not doing anything wrong with the vp9 encoder buffer settings, it's all configurable and I can play with rc_2pass_vbr_maxsection_pct and rc_buf_sz of vpxenc through the available options (Bitrate, Min/Max Bitrate and Buffer) in encoder output settings panel. Observed the values exactly as described in ffmpeg documentation :

bufsize (buf-sz, buf-optimal-sz)
Set ratecontrol buffer size (in bits). Note vpxenc’s options are specified in milliseconds, the libvpx wrapper converts this value as follows: buf-sz = bufsize * 1000 / bitrate, buf-optimal-sz = bufsize * 1000 / bitrate * 5 / 6.

maxrate (maxsection-pct)
Set GOP max bitrate in bits/s. Note vpxenc’s option is specified as a percentage of the target bitrate, the libvpx wrapper converts this value as follows: (maxrate * 100 / bitrate).

The difference between ffmpeg command was just because not providing any buffer setting, so one can get the same rc_buf_sz out from ffmpeg via

ffmpeg ... -c:v libvpx-vp9 -bufsize 1,835,008 -b:v 3472630 out-ffmpeg.webm

So this slowness is purely because of missing vpxenc multithreading capability. As a result assigning it to @LazyDodo to enable it on the next ffmpeg build.

@iss I can confirm blender is not doing anything wrong with the vp9 encoder buffer settings, it's all configurable and I can play with `rc_2pass_vbr_maxsection_pct` and `rc_buf_sz` of `vpxenc` through the available options (Bitrate, Min/Max Bitrate and Buffer) in encoder output settings panel. Observed the values exactly as described in [ffmpeg documentation ](https://ffmpeg.org/ffmpeg-codecs.html#Options-31) : > bufsize (buf-sz, buf-optimal-sz) > Set ratecontrol buffer size (in bits). Note vpxenc’s options are specified in milliseconds, the libvpx wrapper converts this value as follows: buf-sz = bufsize * 1000 / bitrate, buf-optimal-sz = bufsize * 1000 / bitrate * 5 / 6. > maxrate (maxsection-pct) > Set GOP max bitrate in bits/s. Note vpxenc’s option is specified as a percentage of the target bitrate, the libvpx wrapper converts this value as follows: (maxrate * 100 / bitrate). The difference between ffmpeg command was just because not providing any buffer setting, so one can get the same `rc_buf_sz` out from ffmpeg via > ffmpeg ... -c:v libvpx-vp9 -bufsize **1,835,008** -b:v 3472630 out-ffmpeg.webm So this slowness is purely because of missing `vpxenc` multithreading capability. As a result assigning it to @LazyDodo to enable it on the next ffmpeg build.

Hamdi Ozbayburtlu removed their assignment 2022-06-16 16:47:04 +02:00

Ray molenkamp was assigned by Hamdi Ozbayburtlu

2022-06-16 16:47:04 +02:00

Richard Antalik commented

2022-06-16 18:48:30 +02:00

@hamdio Thanks for analysis, Since we don't do 2-pass encoding, I don't think it's necessary to set these. question is if buf-sz and buf-optimal-sz should be calculated from bitrate or just set to some default value or could be kept as is...

@LazyDodo If compile options will be changed, shall we look at difference in mainly libx264 too before libs are updated? Maybe there are some fps to be squeezed out...

@hamdio Thanks for analysis, Since we don't do 2-pass encoding, I don't think it's necessary to set these. question is if `buf-sz` and `buf-optimal-sz` should be calculated from bitrate or just set to some default value or could be kept as is... @LazyDodo If compile options will be changed, shall we look at difference in mainly libx264 too before libs are updated? Maybe there are some fps to be squeezed out...

Ray molenkamp commented

2022-06-17 03:15:17 +02:00

I can build with whatever flags you desire, he current x264 flags are pretty close to stock if someone has improvements to suggest i'll be happy to make some test builds to see if they improve things, i don't think a vp9 ticket is the ideal place to discuss this though.

I can build with whatever flags you desire, he [current x264 flags](https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/cmake/x264.cmake) are pretty close to stock if someone has improvements to suggest i'll be happy to make some test builds to see if they improve things, i don't think a vp9 ticket is the ideal place to discuss this though.

blender-admin commented

2022-07-26 13:17:23 +02:00

This issue was referenced by aa788b759a

This issue was referenced by aa788b759a4119cc93f09c71b5aae270d160c01a

Brecht Van Lommel commented

2022-07-26 13:44:52 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2022-07-26 13:44:52 +02:00

doggon commented

2022-07-26 17:53:55 +02:00

Than you!!!