Personal computing discussed
jmc2 wrote:VideoReDo has released V6 with x265 HEVC (BETA Test Trial).
I tried that and then Handbrake.
Both only used about 1\3 of my 3930 6core/12thread cpu. (4 threads or so)
So a quad core is all anyone is going to need? Is this normal?
The simplest x265.TS output was almost real time at 27fps.
Up the quality with a SLOW to VERY SLOW preset and it is ten times slower. 2.5fps
defaultluser wrote:Handbrake has trouble scaling beyond 6 cores, but it should scale pretty well from 4 to 6.
https://handbrake.fr/docs/en/latest/tec ... mance.html
Sometimes Handbreak doesn't max-out my Core i7 4790k, depending on the film being encoded, so it could just be varying the amount of threading based on complexity of source content? I would try multiple movies to see how performance is?
Thread Pools
x265 creates one or more thread pools per encoder, one pool per NUMA node (typically a CPU socket). --pools specifies the number of pools and the number of threads per pool the encoder will allocate. By default x265 allocates one thread per (hyperthreaded) CPU core on each NUMA node.
Redocbew wrote:The number of threads involved is dependent on the codec and the source material. Encoding an old DVD won't scale very well no matter what you try to do to it, but encoding a 4k video will.
In general, shouldn't your encoding process be tuned towards the best visual results rather than using up all the threads from your leet CPU?
chuckula wrote:In the reencoding of drone footage I've been doing recently I've been using x265 via an ffmpeg interface. No problem railing my cores but I'm doing it on a quad core so that's not as hard to do.
My question is about the first pass/second pass operation. I've seen some online sources saying that's an older methodolgy that's been replaced by just doing everything in one pass. Is that true or is a two pass process still the best way to encode the video either for quality or performance?
techguy wrote:[quote=
jihadjoe wrote:Found this link detailing the various switches related to threading with x265.
https://x265.readthedocs.io/en/default/threading.html
x265 via Handbrake loads up all 8 cores on my SB-E Xeon and 9900k just fine, but certain options might be relevant to Threadripper as AFAIK it does make use of multiple NUMA nodes.
jmc2 wrote:That is interesting, on my first gen 16 core threadripper, x264 would only use 30 something %. So 10-11 cores(threads?).
Have not tried HEVC on the threadripper yet.
On my 6 core, x264 and a HD file can sit at 95-100% for one pass. But HEVC was 30+% both passes.
I tend to convert dvd level .mpgs to x264.mp4s so not a demanding job.
If you know what the "magic" switch is to get 80% use out of 16 core please let me know.
Thanks,
jmc
Redocbew wrote:The number of threads involved is dependent on the codec and the source material. Encoding an old DVD won't scale very well no matter what you try to do to it, but encoding a 4k video will.
In general, shouldn't your encoding process be tuned towards the best visual results rather than using up all the threads from your leet CPU?
jmc2 wrote:Redocbew wrote:The number of threads involved is dependent on the codec and the source material. Encoding an old DVD won't scale very well no matter what you try to do to it, but encoding a 4k video will.
In general, shouldn't your encoding process be tuned towards the best visual results rather than using up all the threads from your leet CPU?
I do go for quality first. The "slow" to "very slow" (x264) handbrake preset drops the fps from 7x real time to 4-5x real time and that is ok.
HEVC goes from almost real time(27fps) to 1/10 real time (2.5fps)(very slow preset) and that is not ok.
And seeing only 1/3 cpu use, gotta hope there is something that can be done to speed things up to an acceptable level by using more of the cpu.
With HEVC finally coming to VideoReDo this is the first time I've explored x265 and have lots to learn.
jmc2 wrote:HEVC goes from almost real time(27fps) to 1/10 real time (2.5fps)(very slow preset) and that is not ok
techguy wrote:Redocbew wrote:The number of threads involved is dependent on the codec and the source material. Encoding an old DVD won't scale very well no matter what you try to do to it, but encoding a 4k video will.
In general, shouldn't your encoding process be tuned towards the best visual results rather than using up all the threads from your leet CPU?
This is just plain wrong.
The screenshot I showed earlier with 80% CPU utilization and over 700 FPS was a DVD.
It's all in the settings folks.
Redocbew wrote:techguy wrote:Redocbew wrote:The number of threads involved is dependent on the codec and the source material. Encoding an old DVD won't scale very well no matter what you try to do to it, but encoding a 4k video will.
In general, shouldn't your encoding process be tuned towards the best visual results rather than using up all the threads from your leet CPU?
This is just plain wrong.
The screenshot I showed earlier with 80% CPU utilization and over 700 FPS was a DVD.
It's all in the settings folks.
I'll rephrase the point just to make it a bit clearer. On a 12 core CPU, the fact that an encoder may be using 12 cores instead of 8 or 10 does not necessarily mean the encoder is doing a "better job". Handbrake doesn't even let you set the number of threads explicitly, and clearly that's not a problem. It just lets the codec handle that. I suppose it's still possible to limit effective scaling just by providing the encoder with really oddball source material, but in general that seems unlikely.
Again, that doesn't mean all of your various "settings" aren't doing anything, but they're not affecting how your encode scales.
Redocbew wrote:That's not the same example. The point(again) is that it's beyond your control using Handbrake, so there's no point in telling the OP to look for some magic knob or dial that'll help improve scaling because there isn't one. The problem, whatever it is, has to be somewhere else.
Redocbew wrote:That's not the same example. The point(again) is that it's beyond your control using Handbrake, so there's no point in telling the OP to look for some magic knob or dial that'll help improve scaling because there isn't one. The problem, whatever it is, has to be somewhere else.
jihadjoe wrote:Redocbew wrote:That's not the same example. The point(again) is that it's beyond your control using Handbrake, so there's no point in telling the OP to look for some magic knob or dial that'll help improve scaling because there isn't one. The problem, whatever it is, has to be somewhere else.
The whole "Extra Options" box in Handbrake's Video encode settings is specifically there so advanced users can tweak their encode settings. Not everything has to be manipulated with a GUI dropdown or slider.
Usacomp2k3 wrote:those option change what the encoding is doing. It's not checking a "do the same encode but use more cores".
Handbrake wrote:The hardware you run on can have a large effect on performance. HandBrake can scale well up to 6 to 8 CPU cores with diminishing returns thereafter. So a 4 core CPU can be nearly twice as fast as a dual Core equivalent, however a 16 core may not be twice as fast as an 8 core but may still offer significant increases in performance. The CPU scaling curve does vary greatly by source and settings used.
Redocbew wrote:I was ignoring diminishing returns to try to keep things simple, but yeah there's that also.
Redocbew wrote:I think it's also easy to forget that in terms of technology DVDs are old.
Glorious wrote:As I said, I'm pretty indifferent to a lot of "quality" stuff, but I'm very sensitive to someone screwing that up.
It's just not the same, so if the argument is "ALWAYS just use THIS preset" as a "solution", I have to reject that off the bat.
Glorious wrote:Well, that's the entire concept of "performance scaling" in relation to cores, isn't it? I mean, if the benefit of "more cores" diminishes, then no, performance doesn't scale very well, right?
Glorious wrote:And that's definitely the part that I think is valuable: I haven't done that in a *long* time. So it is patently possible, and indeed very likely, that my impressions are out-of-date and just wrong now. I appreciate someone giving a modern update, because without it my "knowlwedge" just grows increasingly long-in-the-tooth.
Usacomp2k3 wrote:I'm not very sensitive to picture of audio quality either. It rarely makes a bad movie more enjoyable and rarely makes a good movie not enjoyable. I'm ok with a "good enough" preset that "just works" and wold gladly take longer render time (ie 2-pass) and larger file size without having to muck with settings.
Usacomp2k3 wrote:jihadjoe wrote:Redocbew wrote:That's not the same example. The point(again) is that it's beyond your control using Handbrake, so there's no point in telling the OP to look for some magic knob or dial that'll help improve scaling because there isn't one. The problem, whatever it is, has to be somewhere else.
The whole "Extra Options" box in Handbrake's Video encode settings is specifically there so advanced users can tweak their encode settings. Not everything has to be manipulated with a GUI dropdown or slider.
Those option change what the encoding is doing. It's not checking a "do the same encode but use more cores".
Redocbew wrote:True, but I was having enough trouble just trying to explain that scaling wasn't a thing available for user control without explaining the concept in general