[FFmpeg-devel] [DISCUSSION] Adding ARM64EC support to FFmpeg

[FFmpeg-devel] [DISCUSSION] Adding ARM64EC support to FFmpeg

[harish.rajaselvan--- via ffmpeg-devel]

Hi everyone,
 
I'm reaching out regarding ARM64EC support for FFmpeg on Windows.

I have been working on enabling ARM64EC compilation and have successfully built FFmpeg binaries for this target. To achieve this it required modifications to the build configuration files and to the gas-preprocessor.pl script (maintained in https://github.com/FFmpeg/gas-preprocessor). Should changes to gas-preprocessor.pl be submitted as a pull request to its repository, or also sent to this mailing list for review?
 
I would like to submit these patches upstream for review and feedback from the community in the near future in this thread. Please let us know if we can proceed with submitting them, or if there are any challenges we should anticipate for enabling for this target.
 
Additionally, I would like to know the point of contact for hosting ARM64EC binaries (for example, via btbn or gyan.dev), so that people targeting this platform can have access to FFmpeg builds for this target.
 
Looking forward to your feedback.
 
Thanks,
Harish Raja Selvan
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Mon, 22 Sep 2025, harish.rajaselvan--- via ffmpeg-devel wrote:

> I have been working on enabling ARM64EC compilation and have 
> successfully built FFmpeg binaries for this target. To achieve this it 
> required modifications to the build configuration files and to the 
> gas-preprocessor.pl script (maintained in 
> https://github.com/FFmpeg/gas-preprocessor). Should changes to 
> gas-preprocessor.pl be submitted as a pull request to its repository, or 
> also sent to this mailing list for review?

I'm not sure if we have a policy for this; reviewing it on the mailing 
list probably gives it more visibility than as a PR in a repo that very 
few follows.

> I would like to submit these patches upstream for review and feedback 
> from the community in the near future in this thread. Please let us know 
> if we can proceed with submitting them, or if there are any challenges 
> we should anticipate for enabling for this target.

Feel free to send patches for review - although I cannot guarantee that we 
are willing to integrate the changes.

As far as I can see, for building for ARM64EC with MSVC, the changes 
required mainly are for passing "-machine:arm64ec" to lib.exe, and for 
filtering out the -arm64EC option from the compiler command in 
gas-preprocessor.pl.

Such changes probably are straightforward and probably can be accepted.

If building with https://github.com/mstorsjo/llvm-mingw/releases (with the 
latest 2 releases), no such changes are needed, and it's possible to 
configure a build with just "--cross-prefix=arm64ec-w64-mingw32- 
--target-os=mingw32 --arch=aarch64".

The other, much more major issue, is that all aarch64 assembly may need to 
be tweaked to work in ARM64EC mode. This may need rewrites (or ugly 
conditionals) to avoid using registers that are forbidden in ARM64EC mode.

(Building with Clang makes this aspect much more straightforward, as Clang 
gives warnings about the use of forbidden registers, like "warning: 
register Q25 is disallowed on ARM64EC.".)

We would have to see the proposed patches to see if these changes are 
palatable or if they are too outrageous for us to want to take them 
upstream.

> Additionally, I would like to know the point of contact for hosting 
> ARM64EC binaries (for example, via btbn or gyan.dev), so that people 
> targeting this platform can have access to FFmpeg builds for this 
> target.

Upstream ffmpeg can't make any promises about this; you'd have to convince 
the developers providing those builds to do it. Personally, I'm 
unconvinced.

For users of the plain ffmpeg.exe binaries, I don't see any reason why 
anyone would want to run an ARM64EC version rather than a plain regular 
ARM64 build. (The main theoretical reason is if intending to load a binary 
x86_64 plugin, but I don't know what plugins that would be?)

The main reason for wanting an ARM64EC build of ffmpeg is for integrating 
into an app that still runs in emulated x86_64 mode - then you'd want 
linking against the libraries and not just using the commandline 
executable. I'm not familiar with those binary distributions, whether they 
include such libraries as well, or only the end executables. If they do 
provide libraries as well, I could see some value in it, but it's of 
course totally up to them whether they feel it's worth the effort (I doubt 
it).

// Martin

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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Harish Raja Selvan via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 5259 bytes --]

Hello,

Following up on the discussion above on ARM64EC support, I’ve prepared a patch to
update gas-preprocessor.pl that enables FFmpeg to be compiled for ARM64EC
target on Windows. This change ensures that -m flags are not eliminated for
ARM64EC target, allowing assembly files to preprocess as expected. This
avoids build failures.

The patch has been tested locally & allows FFmpeg to build successfully for
ARM64EC target. Attaching the patch file and in-lined here for your reference.

Thanks,
Harish Raja Selvan.

In-Lined patch:

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 62c1a04..b2e38c0 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -166,6 +166,7 @@ if ($as_type ne "armasm") {
     @gcc_cmd = grep ! /^-D/, @gcc_cmd;
 } else {
     @preprocess_c_cmd = grep ! /^-m/, @preprocess_c_cmd;
+    @preprocess_c_cmd = grep ! /^ARM64EC/, @preprocess_c_cmd;

     @preprocess_c_cmd = grep ! /^-G/, @preprocess_c_cmd;
     @preprocess_c_cmd = grep ! /^-W/, @preprocess_c_cmd;
@@ -195,7 +196,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;
+    @gcc_cmd = grep !/^-m/, @gcc_cmd if !grep /-arm64EC/, @gcc_cmd;
+    @gcc_cmd = grep ! /^-arm64EC/, @gcc_cmd;
     @gcc_cmd = grep ! /^-M/, @gcc_cmd;
     @gcc_cmd = grep ! /^-c$/, @gcc_cmd;
     @gcc_cmd = grep ! /^-I/, @gcc_cmd;
--
2.50.1.windows.1

________________________________
From: Martin Storsjö <martin@martin.st>
Sent: 22 September 2025 17:18
To: harish.rajaselvan--- via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
Cc: Harish Raja Selvan <harish.rajaselvan@multicorewareinc.com>
Subject: Re: [FFmpeg-devel] [DISCUSSION] Adding ARM64EC support to FFmpeg

On Mon, 22 Sep 2025, harish.rajaselvan--- via ffmpeg-devel wrote:

> I have been working on enabling ARM64EC compilation and have
> successfully built FFmpeg binaries for this target. To achieve this it
> required modifications to the build configuration files and to the
> gas-preprocessor.pl script (maintained in
> https://github.com/FFmpeg/gas-preprocessor). Should changes to
> gas-preprocessor.pl be submitted as a pull request to its repository, or
> also sent to this mailing list for review?

I'm not sure if we have a policy for this; reviewing it on the mailing
list probably gives it more visibility than as a PR in a repo that very
few follows.

> I would like to submit these patches upstream for review and feedback
> from the community in the near future in this thread. Please let us know
> if we can proceed with submitting them, or if there are any challenges
> we should anticipate for enabling for this target.

Feel free to send patches for review - although I cannot guarantee that we
are willing to integrate the changes.

As far as I can see, for building for ARM64EC with MSVC, the changes
required mainly are for passing "-machine:arm64ec" to lib.exe, and for
filtering out the -arm64EC option from the compiler command in
gas-preprocessor.pl.

Such changes probably are straightforward and probably can be accepted.

If building with https://github.com/mstorsjo/llvm-mingw/releases (with the
latest 2 releases), no such changes are needed, and it's possible to
configure a build with just "--cross-prefix=arm64ec-w64-mingw32-
--target-os=mingw32 --arch=aarch64".

The other, much more major issue, is that all aarch64 assembly may need to
be tweaked to work in ARM64EC mode. This may need rewrites (or ugly
conditionals) to avoid using registers that are forbidden in ARM64EC mode.

(Building with Clang makes this aspect much more straightforward, as Clang
gives warnings about the use of forbidden registers, like "warning:
register Q25 is disallowed on ARM64EC.".)

We would have to see the proposed patches to see if these changes are
palatable or if they are too outrageous for us to want to take them
upstream.

> Additionally, I would like to know the point of contact for hosting
> ARM64EC binaries (for example, via btbn or gyan.dev), so that people
> targeting this platform can have access to FFmpeg builds for this
> target.

Upstream ffmpeg can't make any promises about this; you'd have to convince
the developers providing those builds to do it. Personally, I'm
unconvinced.

For users of the plain ffmpeg.exe binaries, I don't see any reason why
anyone would want to run an ARM64EC version rather than a plain regular
ARM64 build. (The main theoretical reason is if intending to load a binary
x86_64 plugin, but I don't know what plugins that would be?)

The main reason for wanting an ARM64EC build of ffmpeg is for integrating
into an app that still runs in emulated x86_64 mode - then you'd want
linking against the libraries and not just using the commandline
executable. I'm not familiar with those binary distributions, whether they
include such libraries as well, or only the end executables. If they do
provide libraries as well, I could see some value in it, but it's of
course totally up to them whether they feel it's worth the effort (I doubt
it).

// Martin


[-- Attachment #2: 0001-ffmpeg-gas-preprocessor-enable-ARM64EC-compilation.patch --]
[-- Type: application/octet-stream, Size: 1666 bytes --]

[-- Attachment #3: Type: text/plain, Size: 163 bytes --]

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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Tue, 23 Sep 2025, Harish Raja Selvan wrote:

> Following up on the discussion above on ARM64EC support, I’ve prepared a
> patch to
> update gas-preprocessor.pl that enables FFmpeg to be compiled for ARM64EC
> target on Windows. This change ensures that -m flags are not eliminated for
> ARM64EC target, allowing assembly files to preprocess as expected. This
> avoids build failures.

It is entirely unclear to me what -m flags you would expect to be seeing 
here. I can understand the part of the patch to filter out the flag 
-arm64EC, but I don't see where a flag "ARM64EC" would come from for 
preprocess_c_cd, or where any -m flags would come from.

To make sense of the patch, I would suggest you at least explain what kind 
of configure flags you are using in combination with these patches.

My attempts with ARM64EC with MSVC are configured with --arch=arm64 
--target-os=win32 --toolchain=msvc --extra-cflags="-arm64EC" 
--extra-ldflags="-machine:arm64ec". I guess you are doing something other 
than that, if you're getting -m flags somewhere.

Ideally, post both your build system patches and the gas-preprocessor 
patch at the same time.

Also, don't top post.

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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Harish Raja Selvan via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Hello,

Thank you for your feedback and questions about the ARM64EC patch.
I’m sharing the build system patch for enabling ARM64EC support in FFmpeg.
This patch addresses .def file generation for ARM64EC builds on Windows.

In-Lined patch:

diff --git a/compat/windows/makedef b/compat/windows/makedef
index add8222d13..59e300ab61 100755
--- a/compat/windows/makedef
+++ b/compat/windows/makedef
@@ -108,7 +108,12 @@ if [ -n "$NM" ]; then
               cut -d' ' -f3 |
               sed -e "s/^${prefix}//")
 else
-    dump=$(dumpbin.exe -linkermember:1 ${libname} |
+    member=1
+    arch=$VSCMD_ARG_TGT_ARCH
+    if [ "${arch^^}" = "ARM64EC" ]; then
+        member=32
+    fi
+        dump=$(dumpbin.exe -linkermember:${member} ${libname} |
               sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e "s/ \{1,\}${prefix}/ /" -e 's/ \{1,\}/ /g' |
               tail -n +2 |
               cut -d' ' -f3)
@@ -121,7 +126,7 @@ list=""
 for exp in ${regex}; do
     list="${list}"'
 '$(echo "${dump}" |
-          grep "^${exp}" |
+          grep "^${exp}" | awk '!/\$exit_thunk/{print}' |
           sed -e 's/^/    /')
 done

--
2.50.0.windows.1

For reference, here is the configuration used to build FFmpeg with MSVC for ARM64EC:
I've also attached the same configuration in ffmpeg-arm64ec-msvc.config for convenience.

# find_ar_lib resolves to /usr/share/automake-1.16/ar-lib
AR_LIB="$(find_ar_lib)"
AR_CMD="${AR_LIB} lib.exe -machine:arm64ec"
ARCH="arm64"

"${SRC_DIR}/configure" \
    --toolchain=msvc \
    --target-os=win64 \
    --cc=cl.exe \
    --cxx=cl.exe \
    --extra-cxxflags="-arm64EC" \
    --extra-cflags="-arm64EC" \
    --extra-ldflags="/machine:arm64ec" \
    --as="armasm64.exe -machine ARM64EC" \
    --ld=link.exe \
    --ar="${AR_CMD}" \
    --arch="${ARCH}"

In my setup, this configuration requires the gas-preprocessor.pl patch, as the build otherwise ends with a “GNU assembler not found” error.

Thanks,
Harish Raja Selvan.

[-- Attachment #2: 0001-compat-windows-makedef-fix-.def-generation-for-ARM64.patch --]
[-- Type: application/octet-stream, Size: 2032 bytes --]

[-- Attachment #3: 0001-ffmpeg-gas-preprocessor-enable-ARM64EC-compilation.patch --]
[-- Type: application/octet-stream, Size: 1666 bytes --]

[-- Attachment #4: config-arm64ec-msvc.config --]
[-- Type: application/xml, Size: 480 bytes --]

[-- Attachment #5: Type: text/plain, Size: 163 bytes --]

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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Tue, 30 Sep 2025, Harish Raja Selvan wrote:

> Thank you for your feedback and questions about the ARM64EC patch.
> I’m sharing the build system patch for enabling ARM64EC support in FFmpeg.
> This patch addresses .def file generation for ARM64EC builds on Windows.
> 
> In-Lined patch:
> 
> diff --git a/compat/windows/makedef b/compat/windows/makedef
> index add8222d13..59e300ab61 100755
> --- a/compat/windows/makedef
> +++ b/compat/windows/makedef
> @@ -108,7 +108,12 @@ if [ -n "$NM" ]; then
>                cut -d' ' -f3 |
>                sed -e "s/^${prefix}//")
>  else
> -    dump=$(dumpbin.exe -linkermember:1 ${libname} |
> +    member=1
> +    arch=$VSCMD_ARG_TGT_ARCH
> +    if [ "${arch^^}" = "ARM64EC" ]; then
> +        member=32
> +    fi

We shouldn't inspect any VSCMD_* env variables here in order to deduce the 
target architecture. (Also, how do you initialize the environment in order 
to get such a variable set? If you just open a regular arm64 VS command 
prompt, which AFAIK is the default environment for arm64ec compilation, I 
wouldn't expect such a variable to be set?)

Instead we need to deduce the architecture from something else here - 
potentially by passing some parameter from configure.

> +        dump=$(dumpbin.exe -linkermember:${member} ${libname} |
>                sed -e '/public symbols/,$!d' -e '/^ \{1,\}Summary/,$d' -e
> "s/ \{1,\}${prefix}/ /" -e 's/ \{1,\}/ /g' |
>                tail -n +2 |
>                cut -d' ' -f3)
> @@ -121,7 +126,7 @@ list=""
>  for exp in ${regex}; do
>      list="${list}"'
>  '$(echo "${dump}" |
> -          grep "^${exp}" |
> +          grep "^${exp}" | awk '!/\$exit_thunk/{print}' |

I presume the added awk expression here is just to filter out any line 
that doesn't match '$exit_thunk'? Why not just a "grep -v '$exit_thunk'"? 
And that can be in the dump expression as well, in order not to need to do 
that filtering for each expression. (If we add it to the dump expression, 
we do need to include it in both variants of the dump expression though; 
it's possible to build arm64ec with mingw style tools as well.)

For me, this doesn't really end up matching any symbols - I only get the 
data symbols. What does EXTERN_PREFIX end up being set to in your 
configurations; for me it's an empty string. Does it get set to "#" in 
your case?


> For reference, here is the configuration used to build FFmpeg with MSVC for
> ARM64EC:
> I've also attached the same configuration in ffmpeg-arm64ec-msvc.config for
> convenience.
> 
> # find_ar_lib resolves to /usr/share/automake-1.16/ar-lib
> AR_LIB="$(find_ar_lib)"
> AR_CMD="${AR_LIB} lib.exe -machine:arm64ec"

Why do you need any extra ar-lib here? This works fine for me with just 
AR_CMD="lib.exe -machine:arm64ec".

> ARCH="arm64"
> 
> "${SRC_DIR}/configure" \
>     --toolchain=msvc \
>     --target-os=win64 \
>     --cc=cl.exe \
>     --cxx=cl.exe \
>     --extra-cxxflags="-arm64EC" \
>     --extra-cflags="-arm64EC" \
>     --extra-ldflags="/machine:arm64ec" \
>     --as="armasm64.exe -machine ARM64EC" \
>     --ld=link.exe \
>     --ar="${AR_CMD}" \
>     --arch="${ARCH}"
> 
> In my setup, this configuration requires the gas-preprocessor.pl patch, as
> the build otherwise ends with a “GNU assembler not found” error.

Thanks - with this context, it's easier to review your gas-preprocessor 
patch.

As far as I can see, this builds fine without any extra modifications of 
ffmpeg, as long as gas-preprocessor is patched. Building with 
--enable-shared would require the suggested changes to makedef, but those 
changes aren't entirely right in order to work for me in my tests.

I have an alternative suggestion on how to do the gas-preprocessor patch - 
I'll send those patches and CC you on them.

Another alternative for gas-preprocessor would be to just look for the 
-arm64EC option, and inject the "-machine arm64ec" options implicitly in 
that case (it turns out I actually had such a patch lying around since 
experiments in 2021), but it's perhaps more transparent to force the 
caller of gas-preprocessor to provide the option.

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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

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

Hello,

Le maanantaina 22. syyskuuta 2025, 13.04.40 Itä-Euroopan kesäaika 
harish.rajaselvan--- via ffmpeg-devel a écrit :
> I'm reaching out regarding ARM64EC support for FFmpeg on Windows.

I don't really see the point. There is no use case for FFmpeg proper (the 
executable) to target ARM64EC, and the use care for libav.* seem flimsy at 
best.

To make matters worse, this would really only serve proprietary software. 
Open-source software should, and most likely can, be recompiled to the normal 
Windows/UEFI variant of the AArch64 ABI. If this was a simple question of 
tweaking build parameters and some macros, that could be acceptable.

But this will constrain the assembler is aggravating. It probably requires 
major changes already, but even if it doesn't, I don't think we should 
constrain future assembler code nor expect developers to support the JIT-
friendly ABI.

> Additionally, I would like to know the point of contact for hosting ARM64EC
> binaries (for example, via btbn or gyan.dev), so that people targeting this
> platform can have access to FFmpeg builds for this target.

I don't think that the community resources should be spent on making those 
builds at all. It looks like that would only benefit proprietary Windows apps 
ISVs. That being the case, they should fund the CI setup and running 
themselves.

-- 
ヅニ-クーモン・レミ
Hagalund ny stad, f.d. Finska republik Nylands



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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Sat, 27 Sep 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:

> But this will constrain the assembler is aggravating. It probably requires
> major changes already, but even if it doesn't, I don't think we should
> constrain future assembler code nor expect developers to support the JIT-
> friendly ABI.

This is indeed a core concern of mine as well.

I don't mind adding build system tweaks to make it possible to build, but 
having to modify all the assembly to make it properly compatible with 
arm64ec isn't really feasible or maintainable.

Given the information in your other mails, it sounds like you don't make 
any modifications to the aarch64 assembly at all - so it uses all the 
aarch64 registers, including the ones that are disallowed to use in 
arm64ec mode.

If building with MSVC with the suggested configuration, building produces 
a very large number of warnings of this kind:

Z:\home\martin\code\ffmpeg-msvc-arm64ec\libavutil\aarch64\float_dsp_neon.o.asm(1056) 
: warning A4253: this instruction uses forbidden registers
         fmul            v16.4s, v0.4s,  v4.4s

The same also is produced if building with Clang:

src/libavutil/aarch64/float_dsp_neon.S:32:9: warning: register Q16 is 
disallowed on ARM64EC.
         fmul v16.4s, v0.4s, v4.4s
         ^

I've tried to talk to acquaintances to figure out exactly what one can 
expect to work and what one can't expect to work, if using assembly 
routines with all registers in arm64ec mode.

First off, calling a C function, which turns out to be in x86_64 mode, 
will clobber those registers. But for assembly which only works as leaf 
functions, that don't call C functions (and those C functions are internal 
in ffmpeg, which also are in arm64ec mode, not x86_64), this shouldn't be 
happening.

Secondly, unwinding through such functions won't work correctly either. 
But we never provide any unwind info for assembly functions, and don't 
expect to unwind through them anyway, so that's probably not an issue 
either.

Inspecting (and possibly single-stepping through) such code in a debugger 
could break.

One case which really can break though, is if some other process suspends 
and resumes the thread - as a form of manual scheduling. This sounds 
exotic, but I'm told these things do exist.

All in all, it sounds to me like these things actually can work, at least 
with some amount of caveats. In that case, it sounds acceptable to add 
build system tweaks to make it buildable, as long as the assembly itself 
doesn't need compromises for this mode.

I tested a checkasm.exe built in this mode, both with MSVC and with Clang, 
and it seems to run fine in a single-shot test at least.

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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

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

Le 3 octobre 2025 15:44:56 GMT+03:00, "Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org> a écrit :
>First off, calling a C function, which turns out to be in x86_64 mode, will clobber those registers.

Will it? I thought code JITed from x86_64 to AArch64 could *not* access the reserved registers, and that was why they were forbidden (which barely makes sense to me).

I don't understand how this can be a problem except for green threads and long jumps. But that shouldn't be allowed to happen if you're using FFmpeg anyway - it could dead lock - regardless of the instruction set.

But again, the use case seems very unclear. I'm sure some people are using x86 FFmpeg on Arm, but how do you credibly end up with an AArch64 FFmpeg inside an Arm64EC process?

We shouldn't go out of our way to support an academic exercise or some weird proprietary insane code.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Martin Storsjö via ffmpeg-devel]

On Fri, 3 Oct 2025, Rémi Denis-Courmont wrote:

> Le 3 octobre 2025 15:44:56 GMT+03:00, "Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org> a écrit :
>> First off, calling a C function, which turns out to be in x86_64 mode, 
>> will clobber those registers.
>
> Will it? I thought code JITed from x86_64 to AArch64 could *not* access 
> the reserved registers, and that was why they were forbidden (which 
> barely makes sense to me).

The JITed code itself probably doesn't don't use those registers, no, and 
probably not the JIT compiler itself either. I'm not entirely sure about 
which case actually would clobber them - but I'm told this is a case that 
can do it. Perhaps there's some serialization to/from CONTEXT in some of 
the transitions (perhaps when invoking the JIT compiler?).

> But again, the use case seems very unclear.

Requesting us to provide premade builds for this mode seems very unclear, 
yes - that sounds unreasonable to me.

Wanting to use the libav* libraries in a hybrid x86_64/arm64ec process 
seems like something quite plausible though. Not something I'd go out of 
my way to complicate other things to accomplish, but reasonable build 
system tweaks to allow such builds sound tolerable to me.

> I'm sure some people are using x86 FFmpeg on Arm, but how do you 
> credibly end up with an AArch64 FFmpeg inside an Arm64EC process?

I don't quite understand what you mean here. Do you mean how one does to 
end up with the aarch64 assembly touching all registers, in an arm64ec 
process? Or how one does to retrofit an aarch64 ffmpeg DLL into an arm64ec 
process?

For the former - it works just fine to build and assemble our current 
aarch64 assembly, unmodified, with both MSVC and LLVM build tools. Both of 
them complain loudly about code touching the unavailable registers, but it 
still builds fine, and runs fine in practice.

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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

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

Le perjantaina 3. lokakuuta 2025, 18.11.55 Itä-Euroopan kesäaika Martin 
Storsjö a écrit :
> Wanting to use the libav* libraries in a hybrid x86_64/arm64ec process
> seems like something quite plausible though. Not something I'd go out of
> my way to complicate other things to accomplish, but reasonable build
> system tweaks to allow such builds sound tolerable to me.

Is it that plausible? That seems far less plausible than running a plain 
x86_64 application on an Arm system. Especially for something performance 
sensitive as FFmpeg, you would want a proper native port. Sure, you could very 
well end up with slow x86 code due to "non-technical challenges" (euphemism 
for the vendor not providing an Arm build or your IT department lagging 
behind).

But realistically, you're not going to be able to replace an x86 
libavcodec.dll with an AArch64 libavcodec.dll in such an x86 app. The chance 
of finding the right build options to get a compatible ABI are pretty much 
zero. In fact, they are very exactly zero because the libavutil ABI depends on 
the ISA due notably to the CPU feature flags, configuration parameters, etc.

So this can only work if you have Arm64EC application code calling an 
hypothetical Arm64EC libav*, but also calling x86 code on independent code 
paths. Why would you not port the x86 code to Arm too (or run them in a 
separate process)? That seems pretty fringe if not academic to me.

-- 
Rémi Denis-Courmont
Hagalund ny stad, f.d. Finska republik Nylands



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

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

[Stephen Hutchinson via ffmpeg-devel]

On 10/3/25 12:39 PM, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Le perjantaina 3. lokakuuta 2025, 18.11.55 Itä-Euroopan kesäaika Martin
> Storsjö a écrit :
>> Wanting to use the libav* libraries in a hybrid x86_64/arm64ec process
>> seems like something quite plausible though. Not something I'd go out of
>> my way to complicate other things to accomplish, but reasonable build
>> system tweaks to allow such builds sound tolerable to me.
> 
> Is it that plausible? That seems far less plausible than running a plain
> x86_64 application on an Arm system. Especially for something performance
> sensitive as FFmpeg, you would want a proper native port. Sure, you could very
> well end up with slow x86 code due to "non-technical challenges" (euphemism
> for the vendor not providing an Arm build or your IT department lagging
> behind).
> 
> But realistically, you're not going to be able to replace an x86
> libavcodec.dll with an AArch64 libavcodec.dll in such an x86 app. The chance
> of finding the right build options to get a compatible ABI are pretty much
> zero. In fact, they are very exactly zero because the libavutil ABI depends on
> the ISA due notably to the CPU feature flags, configuration parameters, etc.
> 
> So this can only work if you have Arm64EC application code calling an
> hypothetical Arm64EC libav*, but also calling x86 code on independent code
> paths. Why would you not port the x86 code to Arm too (or run them in a
> separate process)? That seems pretty fringe if not academic to me.
> 

While I haven't gotten through adding the more newly-added external
libraries to the tedious mingw build guide, IIRC most/all of them
already can be built natively for AArch64, so I can't really think of a
publicly-available set of circumstances where someone would be linking
an x86-64 dependency into a native Arm instance of FFmpeg.

I could see it as trying to use x86-64 builds of AviSynth+, though.
That's LoadLibrary, and I either can't remember or haven't seen
anything that describes how the Arm64EC concept behaves when using
dynamic loading.

Yes, there is a native AArch64 Windows release of AviSynth+,
but there won't be one for Arm64EC, because we dropped support
for building with MSVC outside of x86(-64).  An llvm-mingw-built
Arm64EC core wouldn't be able to load MSVC-built x86-64 plugins.

So it wouldn't surprise me if people stubbornly refuse to use
the AArch64 release because they don't want to let go of a build
of a plugin that the plugin author only published for x86-64
(even if said plugin is FOSS).
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

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

Le perjantaina 3. lokakuuta 2025, 23.49.46 Itä-Euroopan kesäaika Stephen 
Hutchinson via ffmpeg-devel a écrit :
> While I haven't gotten through adding the more newly-added external
> libraries to the tedious mingw build guide, IIRC most/all of them
> already can be built natively for AArch64, so I can't really think of a
> publicly-available set of circumstances where someone would be linking
> an x86-64 dependency into a native Arm instance of FFmpeg.
> 
> I could see it as trying to use x86-64 builds of AviSynth+, though.
> That's LoadLibrary, and I either can't remember or haven't seen
> anything that describes how the Arm64EC concept behaves when using
> dynamic loading.
> 
> Yes, there is a native AArch64 Windows release of AviSynth+,
> but there won't be one for Arm64EC, because we dropped support
> for building with MSVC outside of x86(-64).  An llvm-mingw-built
> Arm64EC core wouldn't be able to load MSVC-built x86-64 plugins.
> 
> So it wouldn't surprise me if people stubbornly refuse to use
> the AArch64 release because they don't want to let go of a build
> of a plugin that the plugin author only published for x86-64
> (even if said plugin is FOSS).

Ok, fair enough. Though on second thought, I think that the problem of how to 
build that is far worse than the problem of register allocations in assembler.

-- 
ヅニ-クーモン・レミ
Tapio's place new town, former Finnish Republic of Uusimaa



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