+- Selur's Little Message Board (https://forum.selur.net)
+-- Forum: Hybrid - Support (https://forum.selur.net/forum-1.html)
+--- Forum: Problems & Questions (https://forum.selur.net/forum-3.html)
+--- Thread: x264 and x265 (/thread-2863.html)
RE: x264 and x265 - humanoid86 - 29.08.2022
other applications using the same codecs use only threads
and these applications are stable
does the hybrid use the whole processor?
RE: x264 and x265 - Selur - 29.08.2022
Hybrid is a graphical user interface, it is single threaded.
In when using x264 it uses the x264 command line encoder, when using x265 it uses the x265 command line encoder.
Both have options to requires xy threads from the OS.
How those are distributed is decided by the OS.
There is no such thing as as using a whole processor.
Process priorities and threads assinged to an application is decided by the OS, so unless the tools you use runs with admin rights (which Hybrid doesn't) it can't influence which threads it or the tools it uses gets assigned.
Error code 0x0000007f stands for UNEXPECTED_KERNEL_MODE_TRAP, cause for this usually is:
- a defect (or overheated) RAM module
- combination of non compatible RAM modules
- a defect (or overheated) main module
- buggy mainboard drivers
- Symantec AntiVirus or Norton AntiVirus running (see: https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/stop-error-code-0x0000007f)
If you think that this is just causes by the encoder requesting to many thread both x264 and x265 allow to limit the number of requested threads.
x265->Misc->Threading&Co->Pools/Threads->1/XXX
x264->Base->Threads->XXX
Cu Selur
RE: x264 and x265 - humanoid86 - 30.08.2022
please, your app is awesome!
please talk to HandBrake & Shutter encoder app developers = their apps are very stable
https://handbrake.fr/
https://www.shutterencoder.com/en/
P.S: they probably changed the "priorities" of the OS
RE: x264 and x265 - Selur - 30.08.2022
Sorry, but those programs work fundamentally different than Hybrid as they use libraries not command line programs and thes process audio&video in parallel noch separated.
-> I told you how you could lower the thread count the encoders use, I told you tons of stuff you could try. Thats all I'm willing to do.
Cu Selur
RE: x264 and x265 - humanoid86 - 30.08.2022
thanks
RE: x264 and x265 - humanoid86 - 01.09.2022
(29.08.2022, 18:21)Selur Wrote: x265->Misc->Threading&Co->Pools/Threads->1/XXX
Cu Selur
x265(base)->main10->profile 6.2
x265->Misc->Threading&Co->Pools/Threads-> 4 / 20
(~0,12%~) the processing process started - sometimes microfreezes, but continues to process
~very slow~
how to understand this item "Pools"?
RE: x264 and x265 - karthauzi - 02.09.2022
1. ARM is not even remotely as fast an x86 CPU in encoding stuff. It is not worth the work, absolutely not.
2. be a little kinder @humanoid86, i personally wouldnt help you, if you are so rude.
3. I watched also your Threads and posts, if you dont upload a Debug log at least, Selur cant help you.
![[Image: xle1t4r.png]](https://i.imgur.com/xle1t4r.png)
RE: x264 and x265 - Selur - 02.09.2022
On single cpu systems I would recommand to stick with 1 pool and only change the thread count. (that is why I wrote: 1/XXX not X/Y or something similar)
Assuming you have some basic understanding how memory and cpu ressource allocation works in Windows reading: https://x265.readthedocs.io/en/master/threading.html
might be interessting.
Cu Selur
RE: x264 and x265 - humanoid86 - 02.09.2022
(02.09.2022, 16:21)karthauzi Wrote: 1. ARM is not even remotely as fast an x86 CPU in encoding stuff. It is not worth the work, absolutely not.thanks for the help !!!
2. be a little kinder @humanoid86, i personally wouldnt help you, if you are so rude.
3. I watched also your Threads and posts, if you dont upload a Debug log at least, Selur cant help you.
but this CPU compatibility issue
all new processors will be like this, Selur does not understand this.
RE: x264 and x265 - humanoid86 - 03.09.2022
(02.09.2022, 16:21)karthauzi Wrote:
where is this file and what is its name?