Selur's Little Message Board
x264 and x265 - Printable Version

+- 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)

Pages: 1 2 3


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: Searching the net for Error Code 0x0000007f in Windows should show tons of additional infos.

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]


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.
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.
thanks for the help !!!
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: [Image: xle1t4r.png]

where is this file and what is its name?