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 -- [email protected] To unsubscribe send an email to [email protected]
