Maximum CPU threads?

[deadworldisee 0]

Its not a ffmpeg limitation, its only for libx264 . You wont find refference on the documentation for this. You can test for your self using -threads 16 and -threads 20 and you will see the same performance in speed. The maximum performance for a CPU with libx264 is when you see 100% CPU usage.

I am converting hundreds TB of videos for adult website and this is where I have this experience.

[deadworldisee 0]

I'll uh try to shoe horn a 1060 into my $25k Dell 2U server lol...........

Anyway ,you could use max 2 x 1060 in parallel ,because nvidia limits this cards to only max 2 sessions on a motherboard.Waiting for the VOLTA chips and NVENC 6.

With a $2k computer  ,you can have more performance in encoding than that DELL....

Edited May 30, 2017 by deadworldisee

[Waldonnis 148]

Its not a ffmpeg limitation, its only for libx264 . You wont find refference on the documentation for this. You can test for your self using -threads 16 and -threads 20 and you will see the same performance in speed. The maximum performance for a CPU with libx264 is when you see 100% CPU usage.

I am converting hundreds TB of videos for adult website and this is where I have this experience.

 

May want to take a look at x264/common/common.h...code > documentation (or lack of).  There is a lookahead thread max that's set to 16 (which is understandable), but:

#define X264_THREAD_MAX 128

Honestly, performance isn't everything and there is definitely a difference in quality between software and consumer-level hardware encoding unless you just don't use or care about the myriad of tuning and tweaking options available in x264/x265 (or don't want to do a true 2-pass encode, since NVENC does not do that despite the "2-pass" wording).  I use NVENC, QuickSync, and x264/x265 frequently, but all for different purposes.  For final encodes, though, software encoders just offer better compression at a given quality/bitrate target and with more consistent results quality-wise for a whole bunch of reasons.  Half of my most-used x264 options don't even have a corresponding setting with NVENC (QuickSync is better that way, but still not as complete)...

 

This is not to say that software > hardware for every use, though.  For the work you're doing, I would probably go with hardware encoding too.  Besides the "bulk" nature of the work, the demands and requirements are different for websites that offer video clips and/or downloadable movies compared to disc mastering or archival encoding (and larger adaptive streaming providers have their own considerations as well).  Also, some source material isn't as impacted by the limitations of hardware encoding as others.  I don't often say good things about hardware encoders' quality around here, but NVENC and QSV are actually not that bad for general use and some sources - and I wouldn't even consider software encoding when streaming live gaming sessions.  It's just that they're not the "magic bullet" that many claim they are and have some limitations that can't just be ignored just because of the speed.

 

HEVC is a whole other ball of yarn that I won't get into since even x265 has its quirks.

[deadworldisee 0]

Yes there is a difference between software and hardware encoding, but in present NVENC 5 is nearly  at the same quality/compression  with software at the same bitrate, but with speed encoding very fast.

Modifing the #define X264_THREAD_MAX 128 will make the quality worse https://obsproject.com/forum/threads/dual-xeon-dedicated-stream-pc-issues.62039/ and I dont recomend it , There are multiple reasons why is set to 16.

 

 

QuickSync is way slower and with poor quality than NVENC 5. When I am reffering to performance I mean quality/compressing/time .For me 2 pass encoding is a waste of time.

[Waldonnis 148]

Bah, I wrote a long reply and my browser decided to lose it....ah well.

 

Yeah, using the veryfast preset, I can understand your point about hardware vs. software quality.  Most of the real differences don't show up until you move to slower presets or start enabling options that will slow down the encoding process, since veryfast cuts a lot of corners in favour of speed.  Also, without those options, hardware encoding output isn't much different anyway from a quality perspective - and just might even be superiour depending on the source material and bitrate/quality targets simply because they don't disable as much for the preset compared to software encoders (veryfast for nvenc is not the same as veryfast for x264 anyway since the encoders are implemented differently).  By the same token, though, there isn't as much to enable either if you need more than the presets allow for with hardware encoding.  Compression ratio also suffers a bit at faster presets, but the encoder isn't given enough opportunities to improve on that with those presets.  Other factors enter into it as well (B and I frame count/generation, etc.).

 

Two-pass encoding has its place when trying to target specific bitrates/file sizes while preserving some detail (particularly at lower bitrates).  If you're careful with the quantizer values on a per scene basis, though, you won't see much difference (if any).  I rarely need to do a multi-pass encode, since storage or bitrate targets are rarely things I need to consider, but it has its place in the toolbox and I've actually seen the difference both visually and with PSNR/SSIM metrics.  IMO, two-pass is overly hyped by the...ahem...less-than-legal community that loves small file sizes, though.  Given most of their advertised encoding settings, the extra pass makes so little difference that they may as well just do a single pass.

 

As for x264's thread count constants, yeah, I know why they're set to their current values.  I was just dispelling the myth that there's a "hidden" thread count cap of 16, unless you were solely referring to lookahead threads (which is understandably set to 16).  I could argue the assertion that QuickSync is worse from a quality perspective, however, but that's a whole other discussion.  It is undeniably slower, though.

 

Also, when you start getting into HEVC or VP9, things get much worse for hardware encoders.  NVENC's HEVC implementations currently don't even support B-frames, which is a show-stopper for my uses, and that's just the tip of that iceberg.  Even software encoding for both can be very touchy for some source material...I lost a character's entire eye in one of my test clips thanks to x265's overly aggressive smoothing (admittedly a 1080p clip, so it wouldn't have been as much of an issue at higher resolutions).