Since this is not rare issue and produces broken .blend files, setting to high prio

Fix a typo cleaning the patch

thanks! this is a great feature in our pipeline to be able to quickly set global exposure to our full edit, but since we now use sounds, it's quite hard to use. even with vse channels on which sound strip are on disable still makes the exposure/gamma edit slow.

This is by design - it is not possible to draw channel region in a way that it is not covering preview.

Changes to include comments by Nexyom and ISS.
Specially:

@Georg K (georg) I reopened your original report, so lets handle that there.

The issue is still present in
version: 3.3.0 Alpha, branch: master, commit date: 2022-06-18 22:14, hash: 575884b82786, type: Release
build date: 2022-06-19, 10:09:11
platform: 'Linux-5.17.15-1-MANJARO-x86_64-with-glibc2.35'

Looked at history, and there is no explanation why dependency graph update was added. From what I can see it has no value, but I may be mistaken as well. Will have to propose the change and ask for feedback.

Can confirm the issue.

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.

Interesting, When I investigate original file, bmain->versionfile is 302 and bmain->subversionfile is 8. Yet older version seems to report this incorrectly. I guess this is different issue anyway...

@Hamdi Ozbayburtlu (hamdio) The trouble is that the DNxHD export option is available even though it may not support the current project settings. And there is no information on what is supported and what's not.

@Hamdi Ozbayburtlu (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...

@Peter Fog (tintwotin) if you pick one the supported resolution and bitrates here it works fine:

Valid DNxHD profiles:
- Frame size: 1920x1080p; bitrate: 175Mbps; pixel format: yuv422p10
- Frame size: 1920x1080p; bitrate: 185Mbps; pixel format: yuv422p10
- Frame size: 1920x1080p; bitrate: 365Mbps; pixel format: yuv422p10
- Frame size: 1920x1080p; bitrate: 440Mbps; pixel format: yuv422p10
- Frame size: 1920x1080p; bitrate: 115Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 120Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 145Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 240Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 290Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 175Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 185Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 220Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 365Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 440Mbps; pixel format: yuv422p
- Frame size: 1920x1080i; bitrate: 185Mbps; pixel format: yuv422p10
- Frame size: 1920x1080i; bitrate: 220Mbps; pixel format: yuv422p10
- Frame size: 1920x1080i; bitrate: 120Mbps; pixel format: yuv422p
- Frame size: 1920x1080i; bitrate: 145Mbps; pixel format: yuv422p
- Frame size: 1920x1080i; bitrate: 185Mbps; pixel format: yuv422p
- Frame size: 1920x1080i; bitrate: 220Mbps; pixel format: yuv422p
- Frame size: 1440x1080i; bitrate: 120Mbps; pixel format: yuv422p
- Frame size: 1440x1080i; bitrate: 145Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 90Mbps; pixel format: yuv422p10
- Frame size: 1280x720p; bitrate: 180Mbps; pixel format: yuv422p10
- Frame size: 1280x720p; bitrate: 220Mbps; pixel format: yuv422p10
- Frame size: 1280x720p; bitrate: 90Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 110Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 180Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 220Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 60Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 75Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 120Mbps; pixel format: yuv422p
- Frame size: 1280x720p; bitrate: 145Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 36Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 45Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 75Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 90Mbps; pixel format: yuv422p
- Frame size: 1920x1080p; bitrate: 350Mbps; pixel format: yuv444p10, gbrp10
- Frame size: 1920x1080p; bitrate: 390Mbps; pixel format: yuv444p10, gbrp10
- Frame size: 1920x1080p; bitrate: 440Mbps; pixel format: yuv444p10, gbrp10
- Frame size: 1920x1080p; bitrate: 730Mbps; pixel format: yuv444p10, gbrp10
- Frame size: 1920x1080p; bitrate: 880Mbps; pixel format: yuv444p10, gbrp10
- Frame size: 960x720p; bitrate: 42Mbps; pixel format: yuv422p
- Frame size: 960x720p; bitrate: 60Mbps; pixel format: yuv422p
- Frame size: 960x720p; bitrate: 75Mbps; pixel format: yuv422p
- Frame size: 960x720p; bitrate: 115Mbps; pixel format: yuv422p
- Frame size: 1440x1080p; bitrate: 63Mbps; pixel format: yuv422p
- Frame size: 1440x1080p; bitrate: 84Mbps; pixel format: yuv422p
- Frame size: 1440x1080p; bitrate: 100Mbps; pixel format: yuv422p
- Frame size: 1440x1080p; bitrate: 110Mbps; pixel format: yuv422p
- Frame size: 1440x1080i; bitrate: 80Mbps; pixel format: yuv422p
- Frame size: 1440x1080i; bitrate: 90Mbps; pixel format: yuv422p
- Frame size: 1440x1080i; bitrate: 100Mbps; pixel format: yuv422p
- Frame size: 1440x1080i; bitrate: 110Mbps; pixel format: yuv422p

I've tried the configuration below with 36Mbps bitrate and all seems good:

After investigating my Blender versions (all of them are official daily builds), I guess it is startup file which was copy-pasted from version to version. Here it is originally founded in 2.93 folder:

@Richard Antalik (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.

I have noticed, that opening file with version 3.1 and saving file fixed this issue - strange as file would go through versioning anyway. Then I opened file with version 3.0.1 and it says, that file is written with newer version - sub 43, but release subversion is 42.

I have no idea how this could happen. It seems to thhink there is sequencer data and so it adds channel region. I am not sure what is best way to investigate area in particular. Will try to simplify layout and workspaces and iterate over elements.

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.

I am getting this on the example file

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 @Ray Molenkamp (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 (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...

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.

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.

@Corwin Kerr (ckerr) Is this still an issue?
I can not reproduce the issue with neither 3.2 nor current master branch on MacPro with AMD W6800X card.

Can confirm, trying to set from Right Click menu on the toolshelf operators goes to wm.

Since solution for this is not trivial, will classify as known issue.

Assigning to @Hamdi Ozbayburtlu (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.

@Richard Antalik (ISS) Maybe consider also adding Slide now you know how it is done?

Affect by rB7afcfe111aac: VSE: Make time operations self-contained
@Richard Antalik (ISS) ^

Hi, thanks for the report
Yes, it's a regression and I can confirm too.

Thanks for the follow-up.

Will close, since new channel system has been implemented and does not have this issue.

Closing since this has been changed by rBc968dae05441b8d2c68916260d728c4a8d01c464.

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.

Definitely not fixed for me.

Not seeing it fixed in 3.2.0 Stable yet.

It seems to be fixed for me in 3.2 Stable.

For help using Blender, please try one of the community websites: https://www.blender.org/community/

@Jeroen Bakker (jbakker) hi, would it be ok to mention this fix for corrective release? T98661: 3.2: Potential candidates for corrective releases

Yay, this is fixed in the 3.3.0 Master D15134 branch. Thank you. Not seeing it fixed in 3.2.0 Stable yet.

@Georg K (georg) I also have the same issue on an older AMD GPU on Mesa, and the same workaround fixes the issue for me if applied on my GPU, so your problem can probably be solved in a similar way.

Sorry for chiming in, but since this is so very similar, I was hoping that my issue could be solved in a similar way: https://developer.blender.org/T86686 (has been closed because nobody could reproduce it, but I see it in 3.2/3.3 every day - probably thanks to my old AMD card and mesa).
before this patch:

Should be done in master, add windows to the workaround.

Bisected to rB439f86ac89bdd649aa9ccfe258c5f80474788449.

This is bug persists as of:

I can reliably reproduce this every time. I have a modern processor:

Thanks for logs. Yes, that is the problem I was suspecting. I have fix for this, but it is sitting for quite long time so will have to go over code again to see if it is ready to go, then poke reviewers.

This is what gets logged when I do the slice.

@Omar Emara (OmarSquircleArt) Can you run blender with --debug-ffmpeg argument and paste output when you see incorrect frame?

@Omar Emara (OmarSquircleArt) If you have time you can bisect. I would ask @Clément Foucault (fclem) if such effort would be helpful though.

Do you need me to bisect?

Can't reproduce here. Since software GL works well, it's most likely issue is within GPU driver.

I cannot reproduce this, tested on all three machines of mine (Windows+AMD, Windows+Intel, Mac+M1). No screen issues here. Tested with latest 3.2 build.

Sorry, lost track of this issue and forgot to check. I have tried now with 3.1.2 and 3.3, unfortunately I was still not able to reproduce.

I can reproduce reliably every time on an older AMD GPU, though can't reproduce with software GL.

Thanks for the information. I managed to repro this again (but does not occur frequently)
Will mark this as confirmed for now.
Will also ask others if they can repro or not

In T98015#1369796, @hamza.SMA (hamza.elbarmaki) wrote:

peace,
those commits cannot be also gor 3.2.x ?

peace,
those commits cannot be also gor 3.2.x ?

JF Matheu did some great 2d widgets in python which may serve as UI reference for the surround position widget:

Just a small change; MEM_SAFE_FREE(x) is pretty much the same as the current code, but easier to read.

address review comments

• Fix syntax error
• Invalidate cache and check linked scenes

again :)