With benchmarks is always important to share information about which file was used for comparison and which CPU.

The code looks all good to me,will commit it once i get to the code.

Tried to redo it with a HDxHR render of "Daily Dweebs", and this code change doesn't have any effect.

Trying to look at the ffmpeg/libav code and I notice something like this for h264: https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/writeffmpeg.c$1649

Which is using a 10 years old ffmpeg profile with apparently decapped settings: https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

...and trying to change it to something newer like this...

BKE_ffmpeg_property_add_string(rd, "video", "bf:2");
BKE_ffmpeg_property_add_string(rd, "video", "g:12");
BKE_ffmpeg_property_add_string(rd, "video", "crf:18");
BKE_ffmpeg_property_add_string(rd, "video", "pix_fmt:yuv420p");
BKE_ffmpeg_property_add_string(rd, "video", "tune:fastdecode");
BKE_ffmpeg_property_add_string(rd, "video", "preset:ultrafast");

...breaks it, so I wonder if some part of libav isn't updated with the ffmpeg updates? https://developer.blender.org/rBS5db2d9c82b7f56545393afaad0a600cc4f77d66a

Anyway, what do I know, maybe it's time for a refactor of the FFmpeg code?
(...but keeping in mind, that according to LazyDodo's profiling it was on the Blender side of things and not ffmpeg, that things was slowing down the render process)

We don't use libav. It also not immediately clear what you expect from refactoring FFmpeg code. There should always be a goal of any refactor.
For the lack of speedup, not all codecs supports threading. I'm not sure whether HDxHR is one of them or not though.

In any case, such refactor discussion as the code review is to stay on topic.

Is there anything wrong with the proposed change here?

Did another test, with no difference in render time, Which is odd, since there doesn't seem to be any thread specification originally here(which is why I looked up the profiles and ended up at h264 profile). I guess the default ffmpeg setting can't be to use all threads? But maybe we won't see much improvement, because the bottleneck is on the Blender side of things as LazyDodo's profiling pointed out: https://developer.blender.org/D8126
Anyway, I guess it can't hurt to specify the exact number of threads available(- threads 0 should do the same(unless it is flawed))?

The reason for me suggesting a refactor(or an update), is that ex. the h264 profile seems to be obsolete and there are new ways to optimize renders and utilize hardware encoding in ffmpeg as mentioned here: https://blender.community/c/rightclickselect/0Mfbbc/ The overall main goal for the refactor could be faster encoding and decoding of video in Blender.

Rendering the proxy in this file:

Using this:

rv->c->thread_count = BLI_system_thread_count();
rv->c->thread_type = FF_THREAD_SLICE;

Takes: 23 sec.

Using this:

rv->c->thread_count = 0;

Takes: 35 sec.

And using none of the above takes: 28-32 sec.

So, from my understanding being explicit in the threading count/model is something we should do in order to have best performance.