首页/新闻资讯/正文详情

Windows下用MSYS2+MinGW64编译FFmpeg并集成x264/x265完整指南

发布时间:2026/9/24 18:44:03 来源:云帆数科 栏目:资讯中心
Windows下用MSYS2+MinGW64编译FFmpeg并集成x264/x265完整指南
1. 为什么需要自己编译 FFmpeg三个绕不开的理由很多人在 Windows 下用到 FFmpeg第一反应是去官网下载编译好的 exe 包解压丢进 PATH 就完事了。这个路子应付日常转码确实够用但一旦你开始做这几件事现成包就顶不住了其一你想在 FFmpeg 里集成 x265、libvpx、fdk-aac 这类默认不带或者授权敏感的编解码器其二你需要对 FFmpeg 做定制化的裁剪去掉用不到的协议和滤镜把体积压到最小其三你要基于 FFmpeg 的库libavcodec、libavformat 这些做二次开发需要对接自己工程的编译链。在这三种情况下现成二进制包基本帮不上忙你得从源码编译自己那一套。而在 Windows 平台上从源码构建 FFmpeg 最顺手的路子就是 MSYS2 MinGW64 这套组合。MSYS2 提供了一套类 Unix 的 Shell 环境和 pacman 包管理器MinGW64 则提供 GCC 工具链和 Windows 原生运行库。两者配合既能让你用 ./configure make 这种熟悉的构建方式产出的又是原生 Windows 程序不依赖 Cygwin 的 POSIX 模拟层。这篇文章记录的就是我自己在 Windows 下用 MSYS2 MinGW64 编译 x264、x265、FFmpeg 的完整过程包括环境配置、编译参数、常见报错的定位思路和规避方法。适合需要自建 FFmpeg 开发环境的 Windows 用户参考也适合想弄清楚这套工具链原理的人阅读。2. 环境初始化MSYS2 安装与 MinGW64 链路的配置细节2.1 下载安装与源的选择MSYS2 的安装没什么特别的门槛去官网拿安装包装到一个路径里不要带空格的目录比如C:\msys64然后一路下一步。装完以后你会发现开始菜单里出现了一堆入口什么 MSYS2 MSYS、MSYS2 MINGW64、MSYS2 MINGW32、MSYS2 CLANG64、MSYS2 UCRT64 之类。这里必须搞清楚一个区别MSYS2 的 shell 环境和编译工具链是两回事。MSYS2 MSYS 这个终端里的 GCC 是给 MSYS2 自身环境用的构建出来的程序链接的是 msys-2.0.dll跑在模拟层上不适合发布给普通用户。真正用来编译 Windows 原生程序的是 MINGW64 终端及其对应的mingw-w64-x86_64-toolchain工具链。后面所有操作都在 MINGW64 终端里做不要跑错终端。还有环境变体的选择。MSYS2 现在已经可以装四套不同的 MinGW 工具链分别是 MINGW64、UCRT64、CLANG64、MINGW32。其中 MINGW64 链接的是 msvcrt 运行库UCRT64 链接的是 Universal C Runtime。如果程序只需要在自己机器上用MINGW64 足够如果要往新版本 Windows 上分发或者对宽字符处理有要求UCRT64 更合适。我这篇文章基于 MINGW64 展开因为它在社区里用得最久遇到问题能找到的参考最多。安装之后先更新系统包这一步别跳pacman -Syu如果提示需要重启终端或者重新运行 pacman就关了终端重新打开 MINGW64 再跑一次pacman -Syu把内核相关的包也升完。升级过程中会自动更新 MSYS2 运行时可能出现提示要求关掉当前 shell 再继续照做即可。2.2 安装编译 FFmpeg 三件套所需的依赖包接下来安装工具链和编译 FFmpeg 需要的辅助软件。我在实测中确认以下这一组包足以完成 x264、x265、FFmpeg 的编译不多装也能跑通pacman -S --needed base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake mingw-w64-x86_64-nasm mingw-w64-x86_64-yasm mingw-w64-x86_64-pkgconf逐个解释一下这些包的作用不搞清楚装的是什么后面遇到问题会一头雾水base-devel包含 make、pkgconf、autoconf 等构建工具是编译源码的基础套件。mingw-w64-x86_64-toolchainMinGW64 的 GCC 编译器、头文件、运行库。注意这个包名前面带mingw-w64-x86_64-前缀和 MSYS2 自身的 gcc 是两码事。如果你在 MINGW64 终端里敲gcc -v显示的是 13.2.0 或者更高版本说明装对了。mingw-w64-x86_64-cmake编译 x265 必需。x265 不用 autotools而是用 CMake 构建且还依赖 nasm 生成汇编代码。mingw-w64-x86_64-nasmx264、x265 的汇编优化都需要 nasm。没有 nasmconfigure 会直接提示找不到汇编器x264 能编译但性能大打折扣。mingw-w64-x86_64-yasm老版本 x264 优先找 yasm现在 nasm 也兼容 yasm 语法不过装上有备无患。mingw-w64-x86_64-pkgconfFFmpeg configure 时用来探测系统库的 pkg-config 工具。没有它后面 FFmpeg 找不到 x264、x265 的依赖信息链接阶段会报 undefined reference。装完后验证一下工具链gcc -v cmake --version nasm -v pkg-config --version几个命令的输出版本号齐全环境这块就算准备到位了。3. x264 编译先解决汇编器和输出目录的问题3.1 源码获取与 configure 参数设计x264 的源码不复杂一个仓库就完了。从官网或者 Git 拉取都行git clone https://code.videolan.org/videolan/x264.git或者直接下 release 包。我的建议是用 git clone 拉最新 master因为这个项目本身迭代不频繁master 就是稳定版。进入目录后configure 的参数是我实际验证过的一组./configure --prefix/mingw64 --enable-static --disable-cli --disable-opencl make -j$(nproc) make install拆开来说说每个参数的含义以及容易被忽略的细节。--prefix/mingw64指定安装路径。在 MINGW64 环境里把这个路径设成工具链的系统路径头文件会装到/mingw64/include库文件装到/mingw64/lib。这样后面 FFmpeg configure 时能自动找到 x264 的头文件和库。--enable-static编译静态库FFmpeg 链接的时候直接吃.a文件产出的 exe 不依赖额外的 DLL迁移部署省心。--disable-cli很关键它去掉 x264 的命令行可执行文件只编译 libx264 库。我们最终目标是 FFmpeg 里集成 x264不需要那个单机转码器。--disable-opencl关掉 OpenCL 加速因为启用这个选项后会在运行时动态加载 OpenCL 库如果目标机器没有对应驱动或者开发环境没配 OpenCL SDK链接和运行时都可能出问题。多数场景下 x264 的常规 SIMD 优化已经足够OpenCL 的收益不大徒增隐患。3.2 编译过程中的两个典型坑我在不同机器上编 x264 踩过两个坑都值得单独说一下。第一个坑是nasm 版本过低导致汇编文件语法报错。如果你不是用 pacman 装的 nasm而是在网上随便下了个老版本编到x86_64相关的汇编文件时会报类似error: instruction expected的诡异错误。定位方式很简单nasm -v看版本。MSYS2 仓库里的当前版本基本都满足要求所以优先用 pacman 装别手工弄。第二个坑是configure 提示找不到 yasm 或 nasm但明明已经装好了。这种情况多半是你开错了终端。在 MSYS2 MSYS 终端里PATH 不一定包含/mingw64/bin所以which nasm找不到。另外如果在 Windows 的其他编译环境比如 WinAVR、旧版 MinGW里装过同名的 yasmPATH 顺序也会干扰。解决办法是统一在 MINGW64 终端里操作并且检查 PATH 里有没有乱七八糟的旧环境变量。x264 编译完成后的验证方式也很简单看看库文件是否生成ls /mingw64/lib/libx264.a ls /mingw64/include/x264.h这两个文件存在x264 这一步就过了。4. x265 编译CMake 构建的依赖链路x265 是三者里面最容易出幺蛾子的一个因为它的构建系统是 CMake不是 autotools而且它同时产出静态库和动态库Windows 下还牵扯一个libstdc的链接问题。源码同样从官方仓库拉git clone https://bitbucket.org/multicoreware/x265_git.git或者去官网下载 release 包。x265 的源码根目录下有个build文件夹里面是各平台的构建脚本。Windows 下用build/msys这个子目录里的脚本就行但我更推荐手动执行 cmake 命令因为这样对参数的控制更精细。x265 提供了两种构建模式hign-bit-depth的 10bit/12bit 版本和默认的 8bit。我们这里按通用的 8bit 处理要编 10bit 的话改-DHIGH_BIT_DEPTHON同时要配合-DEXPORT_C_APIOFF和-DENABLE_SHAREDOFF使用。下面这组参数是我验证过的cd x265_git/build/msys cmake -G MSYS Makefiles ../../source -DCMAKE_INSTALL_PREFIX/mingw64 -DENABLE_SHAREDOFF -DENABLE_CLIOFF make -j$(nproc) make install-DENABLE_SHAREDOFF让 x265 只编译静态库不生成 DLL。这个选择和我编译 x264 时保持一致都是为了让 FFmpeg 能静态链接最终 exe 出去就能跑。-DENABLE_CLIOFF关闭命令行工具的编译理由和 x264 的--disable-cli一样。如果这一步报cmake: command not found那就是漏装了mingw-w64-x86_64-cmake。在 MINGW64 终端里用的是这个包提供的 cmake而不是 MSYS2 自身环境的 cmake两者有本质区别。x265 编译期间还有一个值得注意的点它的汇编优化需要 nasmcmake 在配置阶段会检测检测不到就自动降级为 C 实现。所以前面 pacman 装 nasm 那一步不能省否则你编出来的 x265 性能会掉一大截。装完同样验证一下ls /mingw64/lib/libx265.a ls /mingw64/include/x265.h5. FFmpeg 编译configure 参数、依赖探测与静态链接验证5.1 configure 的完整参数与每个参数背后的考量x264、x265 都就位之后重头戏来了。下载 FFmpeg 源码git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg我编译时用的是 master 分支如果你想用更稳定的版本也可以 checkout 某个 release tag比如n7.1。新版 FFmpeg 对编译工具链的版本有要求需要 GCC 12MSYS2 当前的 toolchain 完全满足。configure 参数我实测的这套可以一次跑通cd ffmpeg ./configure --prefix/mingw64 \ --enable-gpl \ --enable-libx264 \ --enable-libx265 \ --enable-static \ --disable-shared \ --extra-cflags-I/mingw64/include \ --extra-ldflags-L/mingw64/lib \ --disable-doc \ --disable-debug make -j$(nproc) make install下面逐个拆解参数为什么这么设--enable-gplx264、x265 都是 GPL 协议FFmpeg 如果要链接它们必须开启 GPL 兼容模式。不开这个configure 会直接拒绝--enable-libx264。--enable-libx264、--enable-libx265这两个开关让 FFmpeg 在 configure 阶段去探测 x264、x265 的存在。探测机制是通过 pkg-config 找.pc文件。x264 和 x265 在make install时已经把.pc文件放进/mingw64/lib/pkgconfig了所以 FFmpeg 能找到。--enable-static --disable-shared强制 FFmpeg 编译静态库不生成 DLL。这样最终产出的 ffmpeg.exe 和 ffprobe.exe 是自包含的拿到别的 Windows 机器上能直接跑不用附带一堆 DLL。注意这里是 FFmpeg 本身的静态库和前面 x264/x265 的静态链接是对应关系。--extra-cflags-I/mingw64/include、--extra-ldflags-L/mingw64/lib很多教程忽略这两行觉得 pkg-config 会自动处理。但实际上 MSYS2 环境下 pkg-config 的搜索路径有时候不太听话显式加上头文件和库路径等于给编译器上了双保险。遇到头文件找不到x264.h或者链接时库找不到的情况先检查这两行有没有写。--disable-doc不编译文档省时间。--disable-debug去掉调试符号减小最终二进制体积。你要是想调试 FFmpeg 内部逻辑这个就别关。5.2 configure 阶段和编译阶段的错误排查configure 阶段最常见的错误是这三种“ERROR: x264 not found using pkg-config”或者“ERROR: x265 not found”。定位思路很简单先手动跑一下 pkg-config 看能不能找到pkg-config --modversion x264 pkg-config --modversion x265如果这两条命令有输出说明.pc文件没问题问题出在 FFmpeg configure 没有把 PKG_CONFIG_PATH 指过去。解决办法是在 configure 之前 export 环境变量export PKG_CONFIG_PATH/mingw64/lib/pkgconfig如果上面两条命令本身就没输出说明 x264 或 x265 没有正确安装到/mingw64回到前面重新检查 make install 有没有成功。“ERROR: Failed to find a nasm assembler”x264 编译时就需要 nasmFFmpeg 同样需要 nasm 来处理部分 SIMD 汇编。检查命令which nasm nasm -v如果 which 找不到确认你是否在 MINGW64 终端里PATH 是否包含/mingw64/bin。“C compiler test failed”这种问题多半和 MSYS2 环境本身不干净有关。比如你之前装了多个版本的 MinGW或者 PATH 里混入了 MSVC 的环境变量。最省事的解决方法是退出后重启 MINGW64 终端清空多余环境变量再试或者在 configure 前显式指定 CCexport CCgcc编译阶段遇到错误最常见的反而是“内存不足”导致并行编译崩溃。Windows 下make -j$(nproc)会把所有核心都拉满但 FFmpeg 的某些大文件尤其是libavcodec下带汇编优化的源文件编译时内存占用很高。我在 8GB 内存的机器上遇到过几次gcc: internal compiler error: Killed。解决办法是把并行数降下来make -j4或者更保守一点make -j2虽然慢但至少能编完。5.3 编译产物的验证与静态链接确认编译完成后先跑一下版本检查确认 x264、x265 确实被编进去了ffmpeg -version ffmpeg -encoders | grep -E libx264|libx265ffmpeg -version的输出里如果出现--enable-libx264 --enable-libx265说明 configure 时的开关生效了。-encoders | grep能看到 libx264、libx265 这两个编码器被注册说明实际链接成功。再看静态链接是否干净ldd ffmpeg.exe在 MINGW64 环境里ldd的输出应该只有/mingw64/bin/...下的一堆系统 DLL比如 libgcc_s_seh-1.dll、libwinpthread-1.dll、libstdc-6.dll不应该出现libx264-*.dll、libx265-*.dll或者 msvcrt 之外的第三方 DLL。如果出现了 x264 的 DLL说明前面的--disable-shared没生效或者是 FFmpeg 动态链接了系统里残留的旧库。如果 ldd 输出里还带了一个libstdc-6.dll这个不用担心它是 x265 的 C 运行时依赖。GCC 编译的 C 程序默认动态链接 libstdc除非你编译 x265 时用了-static-libstdc。想彻底去掉这个 DLL可以在 x265 的 cmake 参数里加-DCMAKE_CXX_FLAGS-static-libstdc -static-libgcc但多数使用场景不需要这么刁钻。如果不想手工 grep直接跑一条真实的转码命令验证编码器能实际工作ffmpeg -f lavfi -i testsrcsize640x480:rate30:duration5 -c:v libx264 -preset veryfast -y test_h264.mp4 ffmpeg -f lavfi -i testsrcsize640x480:rate30:duration5 -c:v libx265 -preset veryfast -y test_h265.mp4能正常转出 MP4说明从 x264 到 x265 到 FFmpeg 整条链路都是通的。6. 集成完成后的坑二次开发的库文件路径与后续使用建议编译完 FFmpeg 并确认编码器可用这只是第一步。真正接触过二次开发的人都知道把 FFmpeg 库接进自己的工程是另一道坎。这里有几个基于实际经验总结的注意点。第一别混淆 MSYS2 的路径格式和 Windows 的路径格式。/mingw64/lib/libavcodec.a这个路径在 MSYS2 终端里有效但你在 VS、Qt Creator 或者其他 Windows 原生 IDE 里配置库路径时必须写成C:\msys64\mingw64\lib\libavcodec.a。很多人 configure 时把路径写成/mingw64/...到 IDE 里照抄结果链接器死活找不到文件。第二Windows 下用 MinGW 静态库的依赖顺序是从右往左。你写 CMake 或者 Makefile 链接 FFmpeg 库时顺序应该是-lavformat -lavcodec -lswresample -lswscale -lavutil -lx264 -lx265顺序反了会出现一堆 undefined reference。具体原因可以从 GCC 链接器的符号解析机制去理解简单说链接器在处理静态库时只捡当前未解析的符号从左往右扫后面的库如果引用前面库里的符号而前面已经扫完了就找不到了。所以依赖比较深的库放后面被依赖的底层库放前面。第三MSYS2 编译的库和 MSVC 工程不能直接混用。MinGW 的库文件调用约定和 C 运行时和 MSVC 不同如果你要在 Visual Studio 里做 FFmpeg 开发要么用 Windows 官方提供的预编译开发包带 .lib 文件要么自己用 MSVC 重新编译一遍。很多人在这一步卡住浪费不少时间。反过来MSVC 编出来的库给 MinGW 链也会有符号格式问题。第四升级依赖时注意版本联动。如果你哪天更新了 x265记得重新编译一遍 FFmpeg否则很可能出现链接不上或者运行时行为不一致的问题。原理是 FFmpeg 在 configure 时记录了 x265 的版本宏和 API 头文件版本头文件换新之后旧编译产物残留的符号版本信息可能对不上。最稳妥的做法是更新 x264/x265 源码之后先 make distclean再重新 configure最后 make。我在一次升级中直接 make结果 FFmpeg 编译倒是过了运行时编码出来的视频花屏排查了很久才意识到是库版本错位。第五如果要在 Windows 服务器上长时间挂 FFmpeg 转码任务优先用静态版本。动态链接的 FFmpeg 在某些精简的 Windows Server 环境下可能缺运行库 DLL比如libgcc_s_seh-1.dll。静态版本直接把运行库打进 exe部署的时候 copy 一个可执行文件就行不用额外装环境。7. 补充一套可复用的一键构建脚本最后把整条编译链路整合成一套脚本放到 MSYS2 的 MINGW64 环境下跑可以省掉重复劳动。脚本思路是先确认依赖再依次编译 x264、x265、FFmpeg每个步骤都检查上一步是否成功失败了就中断避免带着错误往下走。#!/bin/bash set -e # 1. 确认工具链 pacman -S --needed --noconfirm \ base-devel \ mingw-w64-x86_64-toolchain \ mingw-w64-x86_64-cmake \ mingw-w64-x86_64-nasm \ mingw-w64-x86_64-yasm \ mingw-w64-x86_64-pkgconf PREFIX/mingw64 # 2. 编译 x264 if [ ! -d x264 ]; then git clone --depth 1 https://code.videolan.org/videolan/x264.git fi cd x264 make distclean 2/dev/null || true ./configure --prefix$PREFIX --enable-static --disable-cli --disable-opencl make -j$(nproc) make install cd .. # 3. 编译 x265 if [ ! -d x265_git ]; then git clone --depth 1 https://bitbucket.org/multicoreware/x265_git.git fi cd x265_git/build/msys cmake -G MSYS Makefiles ../../source \ -DCMAKE_INSTALL_PREFIX$PREFIX \ -DENABLE_SHAREDOFF \ -DENABLE_CLIOFF make -j$(nproc) make install cd ../.. # 4. 编译 FFmpeg if [ ! -d ffmpeg ]; then git clone --depth 1 https://git.ffmpeg.org/ffmpeg.git ffmpeg fi cd ffmpeg make distclean 2/dev/null || true export PKG_CONFIG_PATH$PREFIX/lib/pkgconfig ./configure --prefix$PREFIX \ --enable-gpl \ --enable-libx264 \ --enable-libx265 \ --enable-static \ --disable-shared \ --extra-cflags-I$PREFIX/include \ --extra-ldflags-L$PREFIX/lib \ --disable-doc \ --disable-debug make -j$(nproc) make install cd .. echo Build complete. Run ffmpeg -version to verify.脚本里用make distclean 2/dev/null || true是为了在已有编译中间产物但不干净的目录里重新构建之前最大化消除缓存影响。set -e保证任何一步出错脚本立即退出不会带病往下编译。跑完这个脚本ffmpeg -encoders里能看到 libx264 和 libx265那你的 Windows 最小化 FFmpeg 构建环境就算搭建完成了。后面无论是转码、推流还是做二次开发都从这套基础出发。

相关推荐

扫雷数字显示:Flutter for OpenHarmony游戏实战解析
扫雷数字显示:Flutter for OpenHarmony游戏实战解析

我最早接触扫雷还是在PC上,那时候的Windows系统自带游戏,简简单单一个格子面板却总能让人一玩就是一下午。后来做移动端开发,接触了Flutter,又陆续研究OpenHarmony的生态,一个念头就很自然地冒出来:能不能把… · 2026/9/24 18:44:03

从2比10到25比23:中国女排用23天完成一场漂亮的翻身仗
从2比10到25比23:中国女排用23天完成一场漂亮的翻身仗

2比10落后,还能赢吗? 9月22日晚,2026年爱知名古屋亚运会女排决赛,中国女排在第三局开局落后8分的情况下,将比分追至19平,最终以25比23完成逆转。随着日本队最后一次接发球出界,中国女排以3比0击… · 2026/9/24 18:43:57

TransUnet眼底血管分割实战:拆解Transformer与U-Net缝合细节
TransUnet眼底血管分割实战:拆解Transformer与U-Net缝合细节

简介:本资源是一套基于TransUnet架构实现眼底血管DRIVE数据集分割的完整实战方案,面向医学图像分割初学者与深度学习实践者,解决视网膜血管结构精准分割这一典型生物医学图像分析任务。压缩包共76个文件,含40张标注图像&#xff0… · 2026/9/24 18:43:57

MP4文件格式深度解析:从box结构到moov索引的底层原理
MP4文件格式深度解析:从box结构到moov索引的底层原理

MP4 这个格式,做音视频开发的人几乎天天在跟它打交道。但说实话,我见过太多人用了好几年 FFmpeg,对 MP4 内部到底长什么样还是一头雾水——命令行能跑通,一旦遇到文件损坏、播放器兼容性异常、seek 定位不准这类问题,就… · 2026/9/24 19:21:11

深入解析MP4 Box结构:从ftyp到mdat的实战指南
深入解析MP4 Box结构:从ftyp到mdat的实战指南

MP4 这个格式,绝大多数人每天都在用,但真正拆开看过它内部结构的人不多。我做音视频开发这些年,接触过的文件格式从 AVI、MKV 到 FLV、TS 都有,MP4 是绕不开的一个——它是目前兼容性最好、生态最完整的容器格式之一。很多人第一次… · 2026/9/24 19:21:11

Windows系统安全加固指南:从账户、Defender到防火墙的实用配置
Windows系统安全加固指南:从账户、Defender到防火墙的实用配置

先说明一个最朴素的道理:Windows系统安全这件事,本质上不是“装个杀毒软件就完事”,而是一整套生活习惯加配置习惯的合集。我见过太多人,电脑里装了五六个安全软件,互相打架,结果系统卡成幻灯片&#xff0c… · 2026/9/24 19:21:11

户外蓝牙音箱选购避坑指南:从参数解读到场景选型
户外蓝牙音箱选购避坑指南:从参数解读到场景选型

开篇我只说实话:户外蓝牙音箱这玩意儿,买过的人十有八九都踩过坑。我前前后后经手过不下二十台,从几十块的塑料小方块到上千元的旗舰款都用了个遍,在山上、海边、暴雨天、沙漠里都实际操过。今天这篇不聊虚的,就把我这… · 2026/9/24 19:21:11

MP4文件格式深度解析:从Box结构到实际应用
MP4文件格式深度解析:从Box结构到实际应用

1. 从一个“打不开的视频”说起:MP4文件格式到底藏着什么很多人第一次对MP4文件产生好奇,不是因为想研究它,而是因为被它坑过。比如你从某个设备导出一段录像,扩展名明明是.mp4,双击却打不开;或者你写了个程… · 2026/9/24 19:21:10

暗黑模式类热门插件
暗黑模式类热门插件

1. 引言Chrome 插件(扩展程序)是运行在 Chrome 浏览器中的小型软件程序,能够扩展浏览器功能、提升工作效率,甚至彻底改变网页的使用体验。比如很多人用过的 Dark Reader,可以一键把几乎所有网站变成暗黑模式&#xff0… · 2026/9/24 19:21:04

基于YOLOv8的渔船作业监控系统:从环境搭建到边缘部署全流程
基于YOLOv8的渔船作业监控系统:从环境搭建到边缘部署全流程

简介:这是一套面向计算机、人工智能、自动化等专业学生与教师的毕业设计级项目资源,围绕YOLOv8实现渔船作业监控系统,可用于毕设、课程设计、大作业或项目立项演示。压缩包共97个文件,约24.21MB,以70个Python源码文件为… · 2026/9/24 0:00:13

1D-CNN时间序列建模实战:从Conv1d原理到工业落地
1D-CNN时间序列建模实战:从Conv1d原理到工业落地

简介:面向时间序列数据建模的一维卷积神经网络完整实现,适合深度学习入门者及需要快速验证时序模型的研究者,能够从音频、文本、传感器或股价等序列中挖掘局部特征与时间依赖。压缩包体积很小,只有3KB,内含3个Python脚… · 2026/9/24 0:00:26

柔软的L:汉语语流中被忽视的舌肌张力控制
柔软的L:汉语语流中被忽视的舌肌张力控制

1. 这个“L”不是字母表里的L,而是舌尖上的L最近在几个方言群和语音教学社群里,反复看到有人发一句:“也说字母L:柔软的长舌”。初看以为是英语发音课笔记,点开才发现全是方言爱好者、播音系学生、语言康复师甚至戏曲演… · 2026/9/24 0:00:44

了解更多?预约专属演示

我们的顾问将为您一对一讲解产品与方案

企业微信二维码