[FFmpeg-devel] [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[FFmpeg-devel] [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Martin Storsjö via ffmpeg-devel]

Filter them out from the preprocessor invocation, and don't remove
them based on matching the "^-m" pattern.

As an alternative, we could also have gas-preprocessor.pl implicitly
add this option if the option "-arm64EC" is found, but requiring
the user to pass "-machine arm64ec" explicitly is more transparent.
---
 gas-preprocessor.pl | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 62c1a04..234c005 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -104,13 +104,17 @@ if ($as_type eq "armasm") {
 
     $preprocess_c_cmd[0] = "cpp";
 
-    # Remove -ignore XX parameter pairs from preprocess_c_cmd
+    # Remove -ignore XX and -machine XX parameter pairs from preprocess_c_cmd
     my $index = 1;
     while ($index < $#preprocess_c_cmd) {
         if ($preprocess_c_cmd[$index] eq "-ignore" and $index + 1 < $#preprocess_c_cmd) {
             splice(@preprocess_c_cmd, $index, 2);
             next;
         }
+        if ($preprocess_c_cmd[$index] eq "-machine" and $index + 1 < $#preprocess_c_cmd) {
+            splice(@preprocess_c_cmd, $index, 2);
+            next;
+        }
         $index++;
     }
     if (grep /^-MM$/, @preprocess_c_cmd) {
@@ -195,7 +199,8 @@ if ($as_type ne "armasm") {
     # which doesn't support any of the common compiler/preprocessor options.
     @gcc_cmd = grep ! /^-D/, @gcc_cmd;
     @gcc_cmd = grep ! /^-U/, @gcc_cmd;
-    @gcc_cmd = grep ! /^-m/, @gcc_cmd;
+    # Remove -m* parameters, except for -machine, which is a valid armasm option.
+    @gcc_cmd = grep ! /^-m(?!achine)/, @gcc_cmd;
     @gcc_cmd = grep ! /^-M/, @gcc_cmd;
     @gcc_cmd = grep ! /^-c$/, @gcc_cmd;
     @gcc_cmd = grep ! /^-I/, @gcc_cmd;
-- 
2.43.0

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] [GASPP PATCH 2/2] Filter out the cl.exe option -arm64EC from armasm

[Martin Storsjö via ffmpeg-devel]

---
 gas-preprocessor.pl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 234c005..1ba0563 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -188,6 +188,7 @@ if ($as_type ne "armasm") {
     @gcc_cmd = grep ! /^-Z/, @gcc_cmd;
     @gcc_cmd = grep ! /^-fp/, @gcc_cmd;
     @gcc_cmd = grep ! /^-EHsc$/, @gcc_cmd;
+    @gcc_cmd = grep ! /^-arm64EC$/, @gcc_cmd;
     @gcc_cmd = grep ! /^-O/, @gcc_cmd;
     @gcc_cmd = grep ! /^-FS/, @gcc_cmd;
     @gcc_cmd = grep ! /^-w/, @gcc_cmd;
-- 
2.43.0

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Martin Storsjö via ffmpeg-devel]

On Fri, 3 Oct 2025, Martin Storsjö wrote:

> Filter them out from the preprocessor invocation, and don't remove
> them based on matching the "^-m" pattern.
>
> As an alternative, we could also have gas-preprocessor.pl implicitly
> add this option if the option "-arm64EC" is found, but requiring
> the user to pass "-machine arm64ec" explicitly is more transparent.
> ---
> gas-preprocessor.pl | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)

Ping Harish - does this look like a reasonable alternative to your patch? 
If you agree with this direction (and the other patch here), I'd go ahead 
and apply these, to have the gas-preprocessor aspect of arm64ec done.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Harish Raja Selvan via ffmpeg-devel]

Hi Martin,
Thanks for the patch! I’ve tested it, and it works as expected. The static ARM64EC build of FFmpeg now builds successfully without any additional code changes. I’m now looking into the changes needed in the makedef script for the --enable-shared build.
Thanks,
Harish.
________________________________
From: Martin Storsjö <martin@martin.st>
Sent: 09 October 2025 17:41
To: ffmpeg-devel@ffmpeg.org <ffmpeg-devel@ffmpeg.org>
Cc: Harish Raja Selvan <harish.rajaselvan@multicorewareinc.com>
Subject: Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

On Fri, 3 Oct 2025, Martin Storsjö wrote:

> Filter them out from the preprocessor invocation, and don't remove
> them based on matching the "^-m" pattern.
>
> As an alternative, we could also have gas-preprocessor.pl implicitly
> add this option if the option "-arm64EC" is found, but requiring
> the user to pass "-machine arm64ec" explicitly is more transparent.
> ---
> gas-preprocessor.pl | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)

Ping Harish - does this look like a reasonable alternative to your patch?
If you agree with this direction (and the other patch here), I'd go ahead
and apply these, to have the gas-preprocessor aspect of arm64ec done.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Martin Storsjö via ffmpeg-devel]

On Fri, 10 Oct 2025, Harish Raja Selvan wrote:

> Hi Martin,
> Thanks for the patch! I’ve tested it, and it works as expected. The static
> ARM64EC build of FFmpeg now builds successfully without any additional code
> changes. I’m now looking into the changes needed in the makedef script for
> the --enable-shared build.

Thanks - then I'll go ahead and apply these two patches on 
gas-preprocessor.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Harish Raja Selvan via ffmpeg-devel]

Hi Martin,
Just wanted to check if you have an estimate for when the ARM64EC related patches for gas-preprocessor and the makedef script changes might be upstreamed.
Thanks,
Harish
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Martin Storsjö via ffmpeg-devel]

Hi,

On Fri, 7 Nov 2025, Harish Raja Selvan wrote:

> Just wanted to check if you have an estimate for when the ARM64EC related
> patches for gas-preprocessor

The patch for gas-preprocessor was merged already many weeks ago. (We 
agreed to go with my version of that patch.)

> and the makedef script changes might be upstreamed.

Rémi had concerns about this - not so much specifically about the makedef 
patch at hand, but about the overall premise of this.

We still haven't heard any concrete explanation on what your intended 
usecase is. We're aware of the general concept - but we'd want to 
understand which concrete way you intend for it to be used.

While the toolchain ensures ABI compatibility between x86_64 and arm64ec, 
that only holds up when actually compiling the exact same code across the 
two - but there are a number of arch specific ifdefs (ARCH_X86 vs 
ARCH_AARCH64) that do lead to a number of inconsistencies in the ABI 
surfaces of the libraries (that can be more or less subtle).

We are not willing to accept patches to the libraries themselves for 
tweaking such details (or anything else relating to arm64ec) - as that 
would potentially lead to a large extra maintainance burden. And we'd also 
like to make it clear that building in this configuration is entirely 
unsupported.

With the questions above answered, and the limitations above acknowledgd, 
the makedef patch could be acceptable to merge - if I correctly understood 
and summarized the discussion with Rémi.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Rémi Denis-Courmont via ffmpeg-devel]

Le 7 novembre 2025 05:51:33 GMT+02:00, Harish Raja Selvan via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> a écrit :
>Hi Martin,
>Just wanted to check if you have an estimate for when the ARM64EC related patches for gas-preprocessor and the makedef script changes might be upstreamed.

Not before you stop ignoring feedback sent to this mailing list. You're being very rude, IMO.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Harish Raja Selvan via ffmpeg-devel]

Hi Martin and Rémi,

Thank you for the clarification and for summarizing the discussion. I understand the concerns about ABI consistency and the maintenance implications.

To clarify the intended use case: many Windows applications such as Jianying Pro<https://www.jianying.com/web/professional>, WPS Office<https://www.wps.com/> and OpenShot<https://www.openshot.org/> currently ship as x64-only binaries and dynamically load FFmpeg DLLs at runtime. On Windows ARM64 devices, these applications run under x64 emulation, which introduces noticeable performance overhead.

By building FFmpeg as ARM64EC, these existing x64 applications can load native ARM64 FFmpeg DLLs via the ARM64EC compatibility layer. The host application continues running under emulation, but the heavy video encoding, decoding, and processing paths execute natively on ARM. This can provide significant performance improvement and acts like a stopgap until native ARM ports of these applications become available. It also helps end users with a smooth and gradual way to move toward full ARM support.

I acknowledge the ABI inconsistencies that can arise from architecture-specific ifdefs, and I understand that this build configuration is not officially supported.

I appreciate your consideration, and I hope this clarifies the intent behind the proposal.

Best regards,
Harish.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Harish Raja Selvan via ffmpeg-devel]

Hi Martin and Rémi,
I wanted to add a bit more context on the practical use case.
There are several large and widely used Windows applications especially in enterprise and creator workflows that remain x64-only and rely heavily on FFmpeg at runtime. Examples include Feishu (Lark), Jianying / CapCut, and DingTalk, which are used at very large scale.
Fully porting these applications to native ARM64 is a significant engineering effort and is taking considerable time. On Windows ARM devices, FFmpeg becomes a major performance bottleneck under x64 emulation.
Using ARM64EC FFmpeg allows existing x64 applications to remain unchanged while enabling performance-critical media paths to run natively on ARM, providing a practical transition path for these applications.
If there are any maintenance concerns, technical challenges, or areas where our help would be useful, we would be glad to support and contribute. Having ARM64EC builds of FFmpeg is important for enabling these real-world use cases.
Best regards,
Harish
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Rémi Denis-Courmont via ffmpeg-devel]

Hi,

Thanks for getting back to us. See below.

Le 20 janvier 2026 09:26:56 GMT+02:00, Harish Raja Selvan via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> a écrit :
>Hi Martin and Rémi,
>I wanted to add a bit more context on the practical use case.
>There are several large and widely used Windows applications especially in enterprise and creator workflows that remain x64-only and rely heavily on FFmpeg at runtime. Examples include Feishu (Lark),
> Jianying / CapCut, and DingTalk, which are used at very large scale.
>Fully porting these applications to native ARM64 is a significant engineering effort and is taking considerable time.

Lark is already running on iOS and Android, so I doubt that it'd be x86-only. ByteDance is a 6-digit staff company, surely it can spare a couple of engineers to make a port for Windows on Arm64.

On the other hand, there still is no credible plan how we would make a proper Arm64EC port of FFmpeg. Recall that the current patch only fixes the C code, but it left broken:
- the assembler code, which doesn't conform to the Arm64EC ABI,
- the binary interface, which assumes an Arm64 caller rather than x86 (breaking at least CPU flags).

Overall I doubt that it would be easier to port FFmpeg to Arm64EC *properly* than to port Feishu to Arm64...

Ditto CapCut by the same company and which also has an Harmony OS port that would require Arm support too.

And pretty much the same with DingTalk, albeit by another large Chinese tech company.

> On Windows ARM devices, FFmpeg becomes a major performance bottleneck under x64 emulation.

We all get that, but the elephant in the room that you have not addressed once in the past months is how to make FFmpeg actually support Arm64EC. Currently it compiles, but that's just the easy 10% of the complete job.

Do you have a plan to address the outstanding shortcomings? What would the actual performance look like in such case, seen as it would disable most or all of the assembler optimisations?

Otherwise we are talking in pure hypotheticals here.

>If there are any maintenance concerns, technical challenges, or areas where our help would be useful, we would be glad to support and contribute. Having ARM64EC builds of FFmpeg is important for enabling these real-world use cases.

See above.

Br,
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Martin Storsjö via ffmpeg-devel]

On Tue, 20 Jan 2026, Rémi Denis-Courmont via ffmpeg-devel wrote:

> Do you have a plan to address the outstanding shortcomings? What would 
> the actual performance look like in such case, seen as it would disable 
> most or all of the assembler optimisations?

It is possible to use the current aarch64 assembler as such - even 
though it does violate the arm64ec ABI.

I just did a set of test builds of ffmpeg with MSVC, natively for arm64, 
one for arm64ec (with an unpatched ffmpeg) and one for x86_64. For a 
simple testcase of decoding VP9, both the proper arm64 and the less proper 
arm64ec build end up decoding at a similar speed, ~390 fps. The x86_64 
build, running emulated runs at 171 fps.

The fact that the arm64ec ABI is violated by the assembly is mostly not a 
practical problem, as long as it only is called directly by the arm64ec 
code, not by emulated x86_64. There are also some other limitations 
(if someone is suspending/resuming the process, the register state would 
be limited to what is expressible in arm64ec mode). There's of course no 
guarantees that this violation will be tolerated in the same way in future 
versions of Windows either.

The cpuflags part of the library API/ABI is indeed a problem - but for a 
caller user application which doesn't call that (and, practically 
speaking, I would expect that most user apps don't do that), that issue 
doesn't really crop up either.

I'm not arguing for us to support this in any greater form than we 
currently do - anyone wanting to use this can really build it for 
themselves. But in the current form, with ABI violations at all, it does 
practically work quite fine in many cases, and it does give essentially 
the same performance as a native build. But those who want to do that will 
need to worry about the limitations - and I wouldn't expect those who 
currently distribute binary builds of ffmpeg to care to add arm64ec 
builds.

(Do note that the ffmpeg project itself doesn't distribute binary builds, 
that is up to third party volunteers. So at this point, it's not us that 
would need to be convinced, it's those third parties that do binary 
builds.)

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Rémi Denis-Courmont via ffmpeg-devel]

Le 20 janvier 2026 15:34:57 GMT+02:00, "Martin Storsjö" <martin@martin.st> a écrit :
>On Tue, 20 Jan 2026, Rémi Denis-Courmont via ffmpeg-devel wrote:
>
>> Do you have a plan to address the outstanding shortcomings? What would the actual performance look like in such case, seen as it would disable most or all of the assembler optimisations?
>
>It is possible to use the current aarch64 assembler as such - even though it does violate the arm64ec ABI.

In other words, "it works except when it doesn't."

You can also mess with X18, TPIDR or SP in a leaf function, as long as you restore them before return. Tests will pass (and even checkasm won't notice). It seems ridiculous that a few GPRs and half the vectors are forbidden, but there are interoperability reasons for this. Windows is riddled with all sorts of weird code doing weird things even to other apps. If it were about calling to/from x86, only the callee-saved GPRs would be justifiably reserved by the ABI.

Given enough users, someone will find a way to unwittingly expose the bug at their expense. The argument was that those 3 apps are hugely popular to begin with: you cannot have the cake and eat it.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Harish Raja Selvan via ffmpeg-devel]

Hi Martin and Rémi,

Thank you for the detailed explanations.

>From the discussion, we understand that the current situation only covers a small part of what would be required for proper ARM64EC support, and that there are significant remaining gaps.

We would like to ask one clarification to better understand the direction:

If the remaining technical issues (ABI correctness, ARM64EC-compliant assembly, and public interface behavior) were addressed properly, would ARM64EC support be something FFmpeg could consider?

If so, it would also be helpful to understand at a high level what kind of changes would be expected to make such support acceptable.

This will help us understand whether further investigation in this area would be meaningful.

Thank you for your time.

Best regards,
Harish
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm

[Rémi Denis-Courmont via ffmpeg-devel]

Le tiistaina 27. tammikuuta 2026, 9.42.03 Itä-Euroopan normaaliaika Harish 
Raja Selvan via ffmpeg-devel a écrit :
> Hi Martin and Rémi,
> 
> Thank you for the detailed explanations.
> 
> >From the discussion, we understand that the current situation only covers a
> >small part of what would be required for proper ARM64EC support, and that
> >there are significant remaining gaps.
> We would like to ask one clarification to better understand the direction:
> 
> If the remaining technical issues (ABI correctness, ARM64EC-compliant
> assembly, and public interface behavior) were addressed properly, would
> ARM64EC support be something FFmpeg could consider?

It's hard to answer an hypothetical. How would you address those issues?

-- 
ヅニ-クーモン・レミ
https://www.remlab.net/



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org