FFMpegCore实战踩坑记:从Windows部署到Linux Docker,我的配置血泪史
FFMpegCore实战踩坑记从Windows部署到Linux Docker我的配置血泪史开发环境里跑得欢生产环境里泪两行——这大概是我最近用FFMpegCore做音视频处理项目最真实的写照。作为一个.NET开发者本以为把本地测试通过的代码扔到服务器就能万事大吉结果从Windows迁移到Linux Docker环境的过程简直是一部血泪史。今天我就把这些坑一个个刨出来给后来者铺条稍微平坦点的路。1. 环境准备不只是下载FFmpeg那么简单第一次接触FFMpegCore时我以为只要Install-Package就完事了。直到部署时才发现这库只是个壳真正的FFmpeg二进制文件得自己准备。Windows下倒是简单官网下载zip解压到项目目录就行# Windows开发环境典型结构 ProjectRoot/ ├── ffmpeg/ │ ├── ffmpeg.exe │ ├── ffprobe.exe │ └── ... ├── appsettings.json └── YourProject.csproj但在Linux环境下事情就开始变得复杂。首先得考虑架构问题——是x64还是ARMglibc版本是否兼容我遇到过最坑的情况是本地测试用的Ubuntu 20.04和服务器上的CentOS 7不兼容因为glibc版本差了整整一代。重要提示生产环境用的FFmpeg二进制最好在目标系统上直接编译或者使用对应发行版的官方包2. 跨平台资源嵌入.csproj里的魔法为了让FFmpeg二进制文件能跟着程序走需要在.csproj里配置资源嵌入。Windows下这样写没问题ItemGroup Content Includeffmpeg\** CopyToOutputDirectoryPreserveNewest/CopyToOutputDirectory /Content /ItemGroup但部署到Linux时发现两个致命问题文件名大小写敏感FFmpeg.exe vs ffmpegWindows的.exe在Linux根本没法执行最终解决方案是用条件编译ItemGroup Condition$(RuntimeIdentifier) win-x64 Content Includeffmpeg\win\** CopyToOutputDirectoryPreserveNewest/CopyToOutputDirectory /Content /ItemGroup ItemGroup Condition$(RuntimeIdentifier) linux-x64 Content Includeffmpeg\linux\** CopyToOutputDirectoryPreserveNewest/CopyToOutputDirectory Executabletrue/Executable /Content /ItemGroup3. Docker部署动态库的地狱之旅本以为把Linux版FFmpeg打包进Docker就完事了结果遇到各种动态库缺失错误ffmpeg: error while loading shared libraries: libx264.so.164: cannot open shared object file解决方案是在Dockerfile里安装所有依赖FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base RUN apt-get update apt-get install -y \ libx264-dev \ libfdk-aac-dev \ libvpx-dev \ libopus-dev \ rm -rf /var/lib/apt/lists/*更坑的是权限问题——即使FFmpeg二进制在容器里也可能因为权限不够无法执行。需要在启动脚本里加chmod x /app/ffmpeg/ffmpeg chmod x /app/ffmpeg/ffprobe4. 运行时配置路径问题的终极解决方案即使所有文件都到位了FFMpegCore可能还是找不到FFmpeg。这时需要根据环境动态配置string ffmpegPath RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? Path.Combine(AppContext.BaseDirectory, ffmpeg, ffmpeg.exe) : Path.Combine(AppContext.BaseDirectory, ffmpeg, ffmpeg); GlobalFFOptions.Configure(new FFOptions { BinaryFolder Path.GetDirectoryName(ffmpegPath), TemporaryFilesFolder /tmp, UseIncludedFFmpeg true });对于Docker环境还需要注意/tmp目录的写入权限临时文件清理策略内存限制视频处理很吃内存5. 实战案例一个完整的Docker部署方案最后分享我的终极解决方案目录结构ProjectRoot/ ├── ffmpeg/ │ ├── win/ │ │ └── (Windows binaries) │ └── linux/ │ └── (Linux binaries) ├── Dockerfile └── YourProject/ ├── Program.cs └── YourProject.csproj对应的Dockerfile关键部分FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build WORKDIR /src COPY . . RUN dotnet publish -c Release -o /app -r linux-x64 --self-contained false FROM mcr.microsoft.com/dotnet/aspnet:6.0 RUN apt-get update apt-get install -y \ libx264-dev \ libfdk-aac-dev \ rm -rf /var/lib/apt/lists/* WORKDIR /app COPY --frombuild /app . COPY --frombuild /src/ffmpeg/linux /app/ffmpeg RUN chmod x /app/ffmpeg/ffmpeg chmod x /app/ffmpeg/ffprobe ENTRYPOINT [dotnet, YourProject.dll]启动时确保设置正确的权限docker run -v /tmp:/tmp -e TEMP/tmp your-image这套方案在我最近三个项目中都验证通过从Windows开发到Linux Docker部署再没出过幺蛾子。不过音视频处理永远有意想不到的坑比如最近遇到的一个HDR转SDR的颜色失真问题那又是另一个悲伤的故事了。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2446169.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!