1080p x264 encoding slow

[rockydon]

I have party this weekend need to compress few videos so we can watch at my friends place

My video source are m2ts,I tried megui with x264 settings making b frame 3 and ReFrames 5 @ level 4.1 for resolutions 1920 X 1080 ,my progression rate goes below 8fps for second pass and takes really lot of time to encodes,I think I won't b able to complete them on time

How can I get faster encode,or also answering my query recommend me other gui/tool for similar encoding with better output

[LoRd_MuldeR]

Use the x264 preset system! Simply use the slowest "--preset" option that you can bear. Or, in other words, switch to the next faster "--preset" until encoding speed is acceptable.

Of course, using a faster preset inevitably results is worse "quality per bit" ratio. So, when using faster presets, you will either have to accept larger files (higher average bitrate) or worse visual quality. You decide ;)

Another option would be down-scaling to, e.g., 720p. The extra CPU spent for the down-scaling should be negligible compared to the time that you save for encoding at lower resolution...

[rockydon]

Use the x264 preset system!
Using that only,I just mentioned my specifications

Another option would be down-scaling to, e.g., 720p. The extra CPU spent for the down-scaling should be negligible compared to the time that you save for encoding at lower resolution...

Ya even I thought same,but back of the mind I just thought 1080p will b better for watching with pals

[LoRd_MuldeR]

Well, if you want faster encoding speed, some sacrifice must be made ;)

[microchip8]

there is no magic that will give you "great" quality and fast encoding speed. if you want the latter, use a faster preset or lower your encoding settings

[rockydon]

This is what my current scenario,is this ok or no

http://i.imgur.com/67OhvsU.jpg

And my OS is 32 bit,changing it to 64 bit will have some benefits?

[LoRd_MuldeR]

And my OS is 32 bit,changing it to 64 bit will have some benefits?

Yes, 64-Bit encoder will give a nice speed-up, compared to 32-Bit encoder.

That's not so much because of the 64 bits, but more because x86-64 (i.e the 64-Bit extension of the x86 architecture) coincidentally added more registers to the CPU.

Note: A 64-Bit encoder necessarily requires a 64-Bit operating system. But a 64-Bit operating system alone wont't speed-up a 32-Bit encoder at all.

[jpsdr]

But a 64-Bit operating system alone wont't speed-up a 32-Bit encoder at all.
I've realised, in some specific cases, that may not be true.
Trying to use asm/YMM registers, i've discovered something i didn't know. YMM registers can be used on 32 bits programs, but not under 32bits OS (something with the ASM code of some YMM instructions being the same of other 32bits only instructions).
So, technicaly, a 32 program which check the AVX2 possibilities, will have a "yes" under a 64bits OS, and a "no", under a 32 bits OS.
So, in that case, a 64bits OS alone, will speed-up the 32bits program, if this one have the possibility to use AVX2 (and of course if the use of AVX2 speed-up the program :D) .

[nevcairiel]

I've realised, in some specific cases, that may not be true.
Trying to use asm/YMM registers, i've discovered something i didn't know. YMM registers can be used on 32 bits programs, but not under 32bits OS (something with the ASM code of some YMM instructions being the same of other 32bits only instructions).
So, technicaly, a 32 program which check the AVX2 possibilities, will have a "yes" under a 64bits OS, and a "no", under a 32 bits OS.
So, in that case, a 64bits OS alone, will speed-up the 32bits program, if this one have the possibility to use AVX2 (and of course if the use of AVX2 speed-up the program :D) .

I don't think this is true. A 32-bit OS should be able to use AVX just fine, as long as it implements the required state support (which all Windows do since 7)
The main limitation here is that 32-bit applications can only use 8 SIMD registers, both for XMM or YMM, while 64-bit can access all 16.

[jpsdr]

No, i've learned it the very hard way, it's true, after hours of blood and pain i've found this (http://masm32.com/board/index.php?topic=1405.msg35186#msg35186).

[rockydon]

Note: A 64-Bit encoder necessarily requires a 64-Bit operating system. But a 64-Bit operating system alone wont't speed-up a 32-Bit encoder at all.
What difference will it make,say a video of 1hr 30 mins will take how much time in both OS,just asking it approximately,which can I get 64bit megui

[jpsdr]

A long time ago, i've compared 32bits x264 under XP32 vs 64bits x264 under XP64. Speed gain was around 40%. But, the parameter/profile you use may also have an effect. It's not impossible that you'll get different results between fast or very slow.

[sneaker_ger]

Yes, 40% sounds like an edge case. 10% on average is more realistic. MeGUI 32 bit includes 64 bit x264, btw.

[rockydon]

Yes, 40% sounds like an edge case. 10% on average is more realistic. MeGUI 32 bit includes 64 bit x264, btw.

I m thinking of changing OS or should I change megui with 64 bit and if yes then guide me how to use

[sneaker_ger]

It's not "or". 64 bit OS is required for 64 bit x264 even when used through MeGUI 32 bit.

[rockydon]

It's not "or". 64 bit OS is required for 64 bit x264 even when used through MeGUI 32 bit.

I didn't know this,how to operate 64 bit x264 through 32 but megui,pls gv details,I will b happy if I could complete my work on time as I said earlier need to complete before tmrw

I have two videos left each of length over 120 mins

[nevcairiel]

No, i've learned it the very hard way, it's true, after hours of blood and pain i've found this (http://masm32.com/board/index.php?topic=1405.msg35186#msg35186).

Not sure what that guy did wrong, but its still not correct. 32-bit operating systems can use AVX. VEX encoding is possible in 32-bit, although a bit limited, hence the limit to only 8 registers. Only when using the other 8 registers would it be interpreted as LDS/LES (which is why they are unavailable).
Perhaps 32-bit requires a slightly newer windows afterall, since Windows 7 still has some remnants of 16-bit DOS support that may clash with VEX encoding (which 64-bit Windows no longer has). Try Windows 8 32-bit instead. ;)

Here is how it works:

Intel was in the need of a new unused byte, which didn’t really exist. What they did instead, was to share two existing opcodes, for each prefix. The sharing works in a special way, that let them know if you meant to use the original instruction or the new prefix. The chosen instructions are LDS (0xc4) and LES (0xc5). When you examine the second byte of these instructions, the byte upon which the new information is extracted from, you can learn that the most significant two bits can’t be set together (I.E: the value of 0xc0 or higher). However, if they are set, the processor will raise an illegal instruction exception. This is where the VEX prefix enters into the game. Instead of raising an exception they will be decoded as this special multi-byte prefix.

[sneaker_ger]

I didn't know this,how to operate 64 bit x264 through 32 but megui,pls gv details,I will b happy if I could complete my work on time as I said earlier need to complete before tmrw
I believe it's used automatically if you run it on a 64 bit OS. You can check using Windows Task Manager while it is encoding. If the x264 process has the "*32" it is 32 bit, otherwise it is 64 bit.

[Taurus]

I believe it's used automatically if you run it on a 64 bit OS.

Yes, MeGui switches automatically to x264 64bit on 64bit windows operating systems.
So, no chance to speedup the workflow exchanging x264 binary on 32bit OS.....:mad::D

[rockydon]

I tried in my 32 bit OS,its 32 bit encoding

[QBhd]

Of course it is... x64 ONLY works in a x64 OS. You will NEVER get any x64 process to work under a 32-bit OS

QB

[LoRd_MuldeR]

I've realised, in some specific cases, that may not be true.
Trying to use asm/YMM registers, i've discovered something i didn't know. YMM registers can be used on 32 bits programs, but not under 32bits OS (something with the ASM code of some YMM instructions being the same of other 32bits only instructions).
So, technicaly, a 32 program which check the AVX2 possibilities, will have a "yes" under a 64bits OS, and a "no", under a 32 bits OS.
I don't think this is true. A 32-bit OS should be able to use AVX just fine, as long as it implements the required state support (which all Windows do since 7)
The main limitation here is that 32-bit applications can only use 8 SIMD registers, both for XMM or YMM, while 64-bit can access all 16.

Right. When executing a 64-Bit operating system, the processor will be running in "long mode" (i.e. 64-Bit extensions enabled), but the kernel is going to switch the processor's sub-mode from "64-Bit mode" into "compat mode" before allowing any 32-Bit process to execute. It switches back to "64-Bit mode" when a 64-Bit process executes. And, in "compat mode", the processor behaves exactly like a 32-Bit processor, or like a 64-Bit processor running a 32-Bit system ("legacy mode").

Consequently, a 32-Bit process running on a 64-Bit operating system can not do anything that it couldn't do as well when running on a 32-Bit operating system (on the same processor). The same limitations still apply! Anyway, AVX does work in "32-Bit mode", and thus under 32-Bit operating systems, just fine. But AVX requires explicit support from the operating system, because the OS needs to save/restore the new AVX registers on context switch. Just CPU support is not enough.

So, when switching from a non-AVX-aware 32-Bit operating system to an AVX-aware 64-Bit operating system, you will gain the ability to run AVX code - in "64-Bit mode" and in "compat mode". But it has nothing to do with the "bitness" of the OS!

(BTW: To the best of my knowledge, the first Windows operating systems to support AVX were Windows 7 SP-1 and Windows Server 2008 R2 SP-1. There was no AVX support in Windows 7 RTM)

See also:
https://en.wikipedia.org/wiki/X86-64#Operating_modes

[jpsdr]

You have AVX support under Windows 7 SP-1 x64 (for both 64bits and 32bits programs), but not under Windows 7 SP-1 x86.
See here (http://masm32.com/board/index.php?topic=1405.msg35186#msg35186).

[nevcairiel]

You have AVX support under Windows 7 SP-1 x64 (for both 64bits and 32bits programs), but not under Windows 7 SP-1 x86.
See here (http://masm32.com/board/index.php?topic=1405.msg35186#msg35186).

Some random comments from some random user are hardly convincing and final proof. Perhaps that guy did it wrong, or its 7 32-bit specifically that has issues due to its 16-bit support remnants, but it is not impossible to use AVX on a 32-bit OS.

Since you like that particular forum so much, here I found you an opposing example of a guy that has that same AVX test program working on 7 SP1 32-bit.
http://masm32.com/board/index.php?topic=3227.msg35231#msg35231

[LoRd_MuldeR]

MSDN says:
AVX Registers
These registers correspond to the XSTATE_MASK_GSSE or XSTATE_MASK_AVX masks. New x86 processors, such as the Intel Sandy Bridge (formerly Gesher) processor, support the AVX instructions and register set (YMM0-YMM15). In Windows 7 with Service Pack 1 (SP1), Windows Server 2008 R2, and newer versions of Windows, both x86 and x64 versions of the operating system preserve the AVX registers across thread (and process) switches. To use the AVX registers in kernel mode, drivers (x86 and x64) must explicitly save and restore the AVX registers. AVX registers cannot be used in an interrupt service routine, and arithmetic exceptions are turned off by default.

https://msdn.microsoft.com/de-de/library/ff545910(v=vs.85).aspx

[Groucho2004]

MSDN says:
As does Intel (https://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions):
Microsoft Windows* 7 with Service Pack 1 (SP1) and Microsoft Windows* Server 2008 R2 with SP1-both 32- and 64-bit versions-and later versions of Windows* support Intel AVX save and restore in thread and process switches. Linux* kernels from 2.6.30 (June 2009) and later support Intel AVX, as well.

[jpsdr]

So... why my asm program crashes with a no sense error message under Win7 SP-1 x86 at the line vmovdqa YMMWORD PTR [esi],ymm0 and works if i remove it (or replace by movdqa XMMWORD PTR [esi],xmm0 to be sure that there is no issue with the value within esi), and under Win7 SP-1 x64 the line vmovdqa YMMWORD PTR [rsi],ymm0 is not crashing my program, except... if what i've seen in the link i've posted is true ?
If you have another explaination, i take it, but for now, it's the only one i have which make sense with the issues i've encountered.

[nevcairiel]

It depends what error it crashes with. It may be as simple as missing proper alignment for the source address.
Just the instruction alone doesn't tell us anything.

[LoRd_MuldeR]

jpsdr,

do you check that both, the CPU and the operating system, support AVX before trying to execute AVX ASM?

x264_cpu_cpuid( 1, &eax, &ebx, &ecx, &edx );
[...]
/* Check OXSAVE and AVX bits */
if( (ecx&0x18000000) == 0x18000000 )
{
/* Check for OS support */
x264_cpu_xgetbv( 0, &eax, &edx );
if( (eax&0x6) == 0x6 )
{
cpu |= X264_CPU_AVX;
if( ecx&0x00001000 )
cpu |= X264_CPU_FMA3;
}
}

[jpsdr]

It wasn't an alignment problem. It crashed with a read error on 0xFFFFFFFF, which is a little strange for a write instruction.
And as i was testing my code, i was forcing the AVX path, and i was under Windows 7 SP-1 x86. So, in that developpement stage, i didn't check anything, because i knew the CPU was able to.
So, as my PC is dual boot with Windows 7 SP-1 x64, i've switched to it, and suddenly, the same asm code which was crashing under Windows 7 SP-1 x86, worked perfectly fine. After the x86 version (tested under x64 OS) of the asm code was finished, i've made the x64 version of the asm code.
So, for now, the following :

That has to do with the VEX prefix for AVX, AVX2, AVX512 ... etc. The instruction:
lds si, [bp+10]
is encoded as:
C5760A

The instructions LDS and LES are not valid under 64-bit operating systems. So they are used as VEX prefixes.
vmovaps ymm0, [esi]

is encoded as:
C5FC2806

The result is, a 32-bit application can't use AVX instructions in a native 32-bit environment. The only chance for such a program is to run under a 64-bit Operating System in the compatibility mode.

is the explanation which have much sense.
Of course, i can't say for sure it's the absolute truth, but from what i've experienced, it's for now, the most logical explanation i've read.

[nevcairiel]

I debunked that "explanation" already on the last page, see this:

Intel was in the need of a new unused byte, which didn’t really exist. What they did instead, was to share two existing opcodes, for each prefix. The sharing works in a special way, that let them know if you meant to use the original instruction or the new prefix. The chosen instructions are LDS (0xc4) and LES (0xc5). When you examine the second byte of these instructions, the byte upon which the new information is extracted from, you can learn that the most significant two bits can’t be set together (I.E: the value of 0xc0 or higher). However, if they are set, the processor will raise an illegal instruction exception. This is where the VEX prefix enters into the game. Instead of raising an exception they will be decoded as this special multi-byte prefix.

Basically, it uses "invalid" forms of LDS/LES (using an invalid argument), which then gets translated to VEX - that is the reason you can only use 8 registers, because the second set of 8 would result in a valid LDS/LES instruction, which of course wouldn't work.
Anyway, invalid access at 0xFFFFFFFF often indicates an alignment problem. If the instruction wouldn't be supported at all, you would get an illegal instruction error, not a read error.

[jpsdr]

Anyway, invalid access at 0xFFFFFFFF often indicates an alignment problem.
I've also noticed this in a real alignment issue, but in that case, the exact same 32bits code works under x64 OS, but not under x86 OS (on the same PC with a dual boot => exact same CPU), and i know address is aligned.
Anyway, after developpement, when used "properly", meaning AVX path is used only if CPU and OS report Ok and not forced (something like LoRd_MuldeR described), no crash anymore on any OS, but if AVX path is forced, crash on 32bits OS, no crash on 64bits OS.
In case you didn't guess, if you want, play between opt=4/opt=0 with my last 32bits nnedi3 version.

[LoRd_MuldeR]

And as i was testing my code, i was forcing the AVX path, and i was under Windows 7 SP-1 x86. So, in that developpement stage, i didn't check anything, because i knew the CPU was able to.

CPU support is required to use AVX code, but not sufficient. AVX also needs to be "enabled" by the OS, which is a thing that has to be checked separately from the CPU support. See the twofold check in x264 CPU detection code above.

Consequently, if you did the proper check under the 32-Bit edition of Windows 7 SP1 and that check revealed that AVX is not enabled (even though the CPU supports it), then it would indicate that the 32-Bit edition of Windows 7 (SP1) indeed doesn't support AVX - and thus any attempt to run AVX code is expected to crash. If, on the other hand, the check revealed that AVX support is enabled, but still your AVX code crashes, then it would indicate some problem in your code.

BTW: If it was some issue with the VEX encoding, then I think the problem would occur, regardless whether your 32-Bit process is running under a 32-Bit or under a 64-Bit Windows. That's because, under a 64-Bit operating system, the CPU is switched into "compat mode" by the OS kernel before a 32-Bit process is allowed to execute. And, in "compat mode", the 64-Bit "x86-64" processor behaves exactly like a 32-Bit "x86" processor - including all restrictions. At least it is supposed to ;)

[jpsdr]

Yes, in Windows 7 SP-1 x86, it seems that AVX is not enable, because in automatic mode, it doesn't choose the AVX path (it doesn't crash...). I don't know about 8.1 or 10.
That's why i've switched and booted under Windows 7 x64 to develop/test.
Going back to true original topic : With the same program (for exemple, at random, x264 which can use AVX if avaible), just going from 32bits OS to 64bits OS, can speed-up things significantly... ;)

[LoRd_MuldeR]

Going back to true original topic : With the same program (for exemple, at random, x264 which can use AVX if avaible), just going from 32bits OS to 64bits OS, can speed-up things significantly... ;)

IMO that statement is strongly misleading.

If you have an AVX-enabled CPU and if the program you are using contains an AVX-optimized code path, then going from non-AVX-enabled OS to an AVX-enabled OS can speed up things quite a lot, yes. But this has nothing to do with the "bitness" of the OS, or with the "bitness" of the program.

If you see a noteworthy speed-up when going from a 32-Bit OS to a 64-Bit OS (in the same app), then it's mostly because of the additional registers that are available in "64-Bit" mode. But 32-Bit processes running under 64-Bit OS don't get this! You need a "native" 64-Bit program to take advantage of that.

Anyway, I still doubt that the 32-Bit edition Windows 7 with SP1 doesn't support AVX, while the 64-Bit edition does. Microsoft and Intel sources say both editions do. I can not verify at the moment, though, due to the lack of a 32-Bit Windows 7 installation. I see nothing in x264 that disables AVX support on 32-Bit OS.

[Groucho2004]

Yes, in Windows 7 SP-1 x86, it seems that AVX is not enable, because in automatic mode, it doesn't choose the AVX path (it doesn't crash...).
What "automatic mode"? What doesn't choose AVX path? Are you talking about x264? nnedi3?

Edit: I just noticed that in nnedi3 you have AVX2 opts, no AVX. I also came across this (http://stackoverflow.com/questions/34782957/visual-studio-2010-2015-does-not-use-ymm-registers-for-avx-optimization), any chance this may be related to your problem?

[jpsdr]

No, my code is directly in asm. I'm talking about nnedi3. As my use of YMM registers may mix AVX/AVX2 instructions, i didn't wan't to "take my head" and globaly goes to "AVX2", even if some cases "AVX" could have been enough.
After, my code in nnedi3 is :

if (opt==0)
{
const int CPUF=env->GetCPUFlags();

if ((CPUF & CPUF_AVX2) != 0) opt = 4;
else
{
if ((CPUF & CPUF_SSE4_1) != 0) opt = 3;
else
{
if ((CPUF & CPUF_SSE2) != 0) opt = 2;
else opt = 1;
}
}
}

So, under Windows 7 SP-1 x86, opt=0 works, opt=4 crash, meaning clearly that it didn't chose the AVX2 path under Windows 7 SP-1 x86 (otherwise, it would have crashed).
Under Windows 7 SP-1 x64, opt=0 and opt=4 both work.
Of course, in both cases i'm talking of the 32bits version of the plugin.

[Groucho2004]

No, my code is directly in asm. I'm talking about nnedi3. As my use of YMM registers may mix AVX/AVX2 instructions, i didn't wan't to "take my head" and globaly goes to "AVX2", even if some cases "AVX" could have been enough.
After, my code in nnedi3 is :

if (opt==0)
{
const int CPUF=env->GetCPUFlags();

if ((CPUF & CPUF_AVX2) != 0) opt = 4;
else
{
if ((CPUF & CPUF_SSE4_1) != 0) opt = 3;
else
{
if ((CPUF & CPUF_SSE2) != 0) opt = 2;
else opt = 1;
}
}
}

So, under Windows 7 SP-1 x86, opt=0 works, opt=4 crash, meaning clearly that it didn't chose the AVX2 path under Windows 7 SP-1 x86 (otherwise, it would have crashed).
Under Windows 7 SP-1 x64, opt=0 and opt=4 both work.
Of course, in both cases i'm talking of the 32bits version of the plugin.
Your wording is confusing (at least to me). So, "opt=4 crash" means that on W7SP1_32 "(CPUF & CPUF_AVX2)" returns > 0 and then crashes? In that case, the rest of your sentence makes no sense. Maybe it's just me not having slept enough...

[jpsdr]

No. opt is an input paramater of the plugin. So, if in my avs script i put nnedi3(opt=4) it crashes, but if i put nnedi3(opt=0) it doesn't (on x86 OS). On x64 OS, both work.

[LoRd_MuldeR]

FWIW, I did some test with Windows 8.1 32-Bit (Windows 7 32-Bit seems to be impossible to find these days) and AVX definitely does work:
https://s24.postimg.org/fd0oxgpjn/avx_32bit.png

https://s24.postimg.org/dxz48qogh/avx_32bit.png (https://s24.postimg.org/fd0oxgpjn/avx_32bit.png)

(in order to show that 32-Bit x264 running under 32-Bit Windows actually is successfully using AVX, I also tried explicitly disabling AVX, which clearly runs slower)

[jpsdr]

Just out of curiosity, tested under a true full 32 bits OS (installed on HDD and booted from), or running from a VM under a 64bits OS ?
But nevertheless, as i said, i don't know about 8.1 and/or 10, only what i've experienced with 7.

[jpsdr]

HWinfo is "no good", because it also report AVX/AVX2 under my Windows 7 SP-1 x86 on CPU. It seems it reports pure CPU, without OS restriction.

[jpsdr]

AAAARRRRRGGGGGGGGGHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!

Big mistake from my part, something i totaly forgot and just realised !!!!!!!!!
CPUF_AVX2 is AVS+ specific, it doesn't exist on AVS2.6.1, and it's what is installed on my x86 OS (AVS+ is installed on my x64 OS), so it's obvious that in automatic mode it will never go to the AVX2 path !!!!
And if the PVideoFrame dst = env->NewVideoFrame(vi,64); is not working properly in avs2.6 (i think i barely remember something about), it can explain thing...
All my humble apologies... I may have been totaly wrong since the begining...

[Groucho2004]

AAAARRRRRGGGGGGGGGHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!

Big mistake from my part, something i totaly forgot and just realised !!!!!!!!!
CPUF_AVX2 is AVS+ specific, it doesn't exist on AVS2.6.1, and it's what is installed on my x86 OS (AVS+ is installed on my x64 OS), so it's obvious that in automatic mode it will never go to the AVX2 path !!!!
Just roll your own CPU/OS feature detection.

[LoRd_MuldeR]

Just out of curiosity, tested under a true full 32 bits OS (installed on HDD and booted from), or running from a VM under a 64bits OS ?

Yes, VM under 64-Bit OS (Windows 10 x64). But a 64-Bit "host" OS doesn't magically make the "guest" OS support AVX. Neither does an AVX-enbled "host" OS.

For cross-check, here we see a 64-Bit (guest) OS known to not support AVX, running on the exactly same CPU and the exactly same 64-Bit AVX-enabled "host" OS, but still AVX doesn't work:
https://s14.postimg.org/g0mzmeebj/avx_xp64bit.png

https://s14.postimg.org/hfokb4fel/avx_xp64bit.png (https://s14.postimg.org/g0mzmeebj/avx_xp64bit.png)

(So, the host OS or the virtualization software do not "inject" AVX support into the guest OS. The OS itself needs to support AVX, in addition to the CPU. But 32-Bit OS can support AVX, as we have seen before (https://s24.postimg.org/fd0oxgpjn/avx_32bit.png))


HWinfo is "no good", because it also report AVX/AVX2 under my Windows 7 SP-1 x86 on CPU. It seems it reports pure CPU, without OS restriction.

Well, checking whether the CPU does support AVX, as the CPUID instruction does, and checking whether the OS has actually "enabled" AVX, as the XGETVB does, are two different pairs of shoes.

Being a hardware analysis tool, HWiNFO probably only checks the capabilities of the CPU only, indeed.

That's still a perfectly legitimate info, I think. But we need to keep in mind what it means. A software developers, who intends to run AVX code, additionally needs to check the OS support for AVX.


CPUF_AVX2 is AVS+ specific, it doesn't exist on AVS2.6.1, and it's what is installed on my x86 OS (AVS+ is installed on my x64 OS), so it's obvious that in automatic mode it will never go to the AVX2 path !!!!Just roll your own CPU/OS feature detection.

Indeed. Should be straight forward to adapt from, e.g., x264's "cpu.c" file.

[rockydon]

Even after upgrading my OS to 64 bit I couldnt notice speed change in encoding video,I m using megui latest version,is there other bit version for OS

[rockydon]

here is the task manager image,my Os is 64 bit and Megui is 32 bit how can i make it 64 bit megui and is it beneficial to do that,will that enhance my speed

https://s30.postimg.org/iyki46va9/image.png

[sneaker_ger]

It's only important that x264.exe and x265.exe are running in 64 bit. MeGUI itself is not important.

https://www.tenforums.com/tutorials/60878-process-see-if-32-bit-64-bit-windows-10-a.html

[Taurus]

@rockydon
We cant see your encoding settings.
Just for the fun of it I encoded a small snippet 1920/1080/50fps mts/avc
with your settings from the first page of this thread.
No heavy filtering, no resizing nor cropping, just plain encoding within MeGui.
On an old intel core2duo@2400mhz i get roughly 25fps on first pass and 15fps on secand pass.
Sure, if you lower the preset you will get less numbers.
Show us your MeGui logs and mediainfos of input/output file.
On an intel 4790 quadcore/8 threads about 250fps on first pass, 150fps on second pass.
I think you just need better hardware and/or a better understanding of your encoding chain.
And for the third time: MeGui is using the x264 64bit by default. No more speed advantages by changing the gui/application.
Just try Handbrake or any other gui with the same x264 settings and the results will be the same.
If you get a recent grafics adapter you could try hardware encoding.
This will speedup your encoding chain significantly at the expense of slighty loss in quality.
Just my two cents...