簡介利用 VS2015 在 32 位 Windows 環(huán)境下編譯 FFmpeg 6.0.1 后打包的資源面向需要在 Win32 平臺做音視頻開發(fā)、二次封裝或功能裁剪的技術(shù)人員。下載后可直接獲得可用的 DLL、頭文件和導(dǎo)入庫經(jīng)過實測能夠正常調(diào)用省去手動編譯和依賴配置的時間。壓縮包共 222 個文件大小約 10.89MB包含 139 個頭文件、24 個 C 源碼文件以及 7 個 DLL 動態(tài)庫、7 個 LIB 導(dǎo)入庫和 7 個 DEF 導(dǎo)出定義文件同時附帶 pkg-config 所需的 .pc 文件、FFmpeg 可執(zhí)行程序、預(yù)設(shè)參數(shù)文件和說明文檔。文件組織清晰動態(tài)庫可直接用于工程鏈接源碼和頭文件便于查看內(nèi)部實現(xiàn)或按需裁剪man 手冊頁則覆蓋過濾器、編解碼器、格式、設(shè)備與協(xié)議等模塊適合開發(fā)時查詢接口和參數(shù)。目前已有 414 人學(xué)習(xí)下載對于想在 Win32 下快速搭建 FFmpeg 開發(fā)環(huán)境、兼顧源碼閱讀和文檔查閱的開發(fā)者是一份很實際的資源。1. 都到6.x了為什么還有人在找32位ffmpeg先說結(jié)論ffmpeg 6.0.1的32位版本沒有過時它只是服務(wù)的人群不再發(fā)聲了。我自己是在給一臺老工控機(jī)做視頻采集方案時被迫回頭折騰32位編譯的后來發(fā)現(xiàn)這個需求遠(yuǎn)比想象中普遍只是平時大家不太會主動聊。1.1 存量老機(jī)器的現(xiàn)實約束Windows XP、Win7 32位、老款嵌入式主板、工控機(jī)、POS機(jī)、車載中控這些設(shè)備到今天依然在大量運(yùn)行。它們的CPU架構(gòu)早就被官方和各大軟件廠商放棄但生產(chǎn)環(huán)境里不可能說換就換。如果你需要在這些設(shè)備上做視頻推流、RTSP拉流、截圖分析ffmpeg 6.0.1的32位版本就是少數(shù)還能拿到新編碼器和新協(xié)議修復(fù)的選擇。很多人會問為什么不直接用老版本ffmpeg 3.x因為老版本對H.265、AV1、HEVC的硬解支持、對某些RTSP廠商私有協(xié)議的處理、對m3u8加密流的兼容性都有明顯短板。視頻編碼領(lǐng)域這十幾年變化太快哪怕是2023年發(fā)布的6.0.1在某些新設(shè)備推流場景下也都才剛追平。所以與其找一個十年前的老版本將就不如自己在新的源碼樹上編一個32位版本出來。1.2 集成到32位宿主程序的無奈另一個很典型的需求是把自己寫的程序或第三方SDK與ffmpeg做靜態(tài)集成。很多商業(yè)SDK、老項目、銀行柜臺程序、醫(yī)療影像軟件底層還是32位的PE文件或者32位ELF。你的宿主進(jìn)程是32位的就沒辦法直接LoadLibrary一個64位的ffmpeg哪怕你的操作系統(tǒng)是64位的Windows 10或Linux服務(wù)器。這種情況下編譯一個32位版本的ffmpeg動態(tài)庫或靜態(tài)庫然后把你的模塊一起鏈進(jìn)去是最省事的路線。架構(gòu)不匹配不是靠“換個路徑”或者“改個權(quán)限”能繞過去的必須老老實實準(zhǔn)備32位目標(biāo)文件。1.3 測試矩陣?yán)锏募嫒菪孕枨筮€有一種場景你可能想不到做商業(yè)化軟件分發(fā)QA測試矩陣?yán)锉仨毟采w32位系統(tǒng)環(huán)境否則測試報告就不完整。有些產(chǎn)品的用戶畫像就是老設(shè)備你的CI/CD流水線里就得有一個job專門編32位ffmpeg、跑32位回歸。我自己就碰到過這種情況編譯環(huán)境全是新的容器和新的工具鏈但客戶現(xiàn)場反饋說“在32位系統(tǒng)上跑不起來”一查果然是ffmpeg編成了64位。從那兒之后我的發(fā)布腳本里永遠(yuǎn)會保留一個32位構(gòu)建產(chǎn)物哪怕平時根本用不到。2. 獲取32位ffmpeg 6.0.1的現(xiàn)成渠道如果不太想自己編譯先看看現(xiàn)成輪子。這里分幾類渠道說清楚免得你花一晚上踩我踩過的坑。2.1 官方?jīng)]提供Windows二進(jìn)制別白等FFmpeg官方項目本身是不提供Windows預(yù)編譯二進(jìn)制的官網(wǎng)只給Linux源碼包。所以你在網(wǎng)上搜“ffmpeg-6.0.1 win32下載”能搜到的基本全是第三方構(gòu)建站點或個人打包。如果你看到某個名氣不大的下載站掛著“官方32位版”字樣心里要打個問號官方從來沒發(fā)過Windows二進(jìn)制哪來的官方版這里不是說第三方一定不安全而是提醒你別下載來歷不明的exe尤其要小心被捆綁了多余的東西。2.2 gyan.dev / BtbN 等第三方構(gòu)建怎么選目前靠譜的第三方構(gòu)建主要是兩個渠道gyan.dev提供Windows的 release 和 full 兩種版本full版本編碼器更全release版本更精簡。它的下載頁里能選32位版本我記得是帶“win32”字樣。BtbNGitHub Actions自動構(gòu)建提供ffmpeg-master-latest-win32-gpl.zip這類產(chǎn)物。它是持續(xù)集成自動編的基本可以認(rèn)為是當(dāng)前源碼的滾動構(gòu)建不一定恰好是6.0.1這個tag但如果你只需要“6.x級別的功能”完全夠用。如果項目里有嚴(yán)格版本要求比如你們內(nèi)部依賴某個特定commit或必須鎖6.0.1的API行為那第三方滾動構(gòu)建就幫不上忙了還是得回到源碼自編譯。2.3 拿到文件后立刻做的架構(gòu)驗證下載完別急著放進(jìn)生產(chǎn)環(huán)境先驗證一下這個文件到底是32位還是64位。Windows下用命令行dumpbin /headers ffmpeg.exe找輸出里的“machine”字段x86表示32位x64表示64位。如果沒有dumpbin用Git Bash或MSYS2自帶的file命令也行file ffmpeg.exe # 輸出示例PE32 executable (console) Intel 80386, for MS WindowsPE32且Intel 80386就是32位。如果是PE32那是64位。這個檢查十秒鐘的事能幫你避免把整個測試環(huán)境帶偏。3. Windows環(huán)境親手編譯32位版MSYS2路線實操如果你必須鎖死6.0.1版本或者需要裁剪模塊那就到了自己編譯這一步。Windows環(huán)境下我最推薦的是MSYS2 MinGW-w64路線不要拿Visual Studio去硬碰ffmpeg那套configure腳本編起來痛苦得多。3.1 安裝MINGW32環(huán)境時的兩個細(xì)節(jié)先裝MSYS2然后打開“MSYS2 MINGW32”這個shell注意名字里帶32不是MSYS2 MSYS也不是MINGW64執(zhí)行pacman -S mingw-w64-i686-toolchain mingw-w64-i686-yasm這里有兩個細(xì)節(jié)值得注意必須裝mingw-w64-i686前綴的包不要裝mingw-w64-x86_64。前綴決定目標(biāo)架構(gòu)裝錯了編出來的還是64位。ffmpeg的configure在生成匯編優(yōu)化時依賴yasm或nasmWindows上更常用yasm。不裝也能編但很多SIMD優(yōu)化會被跳過性能差距能達(dá)到20%以上。依賴庫libx264、libmp3lame、libvpx等同樣用i686前綴裝比如pacman -S mingw-w64-i686-libx264 mingw-w64-i686-libmp3lame3.2 configure參數(shù)怎么給才算是真正的32位解壓ffmpeg-6.0.1源碼后在MINGW32 shell里執(zhí)行configure我這里給一套經(jīng)過驗證的參數(shù)./configure \ --archx86 \ --target-osmingw32 \ --cross-prefixi686-w64-mingw32- \ --enable-cross-compile \ --disable-doc \ --disable-debug \ --enable-gpl \ --enable-libx264 \ --enable-libmp3lame \ --extra-cflags-m32 \ --extra-ldflags-m32我在MINGW32 shell下實測--archx86和--target-osmingw32是定位32位架構(gòu)的關(guān)鍵。--cross-prefix指定i686的交叉編譯前綴這樣configure能找到32位的gcc。--enable-cross-compile是必須打開的否則configure會嘗試在本地跑編譯產(chǎn)物來探測運(yùn)行行為而本地shell是32位的、編出來的程序也是32位的邏輯上沒問題但configure對它自己“跨平臺”這件事特別敏感不聲明的話容易報錯。如果你不想要GPL組件把--enable-gpl和--enable-libx264去掉即可靜態(tài)鏈接下許可證問題值得注意公司內(nèi)部用無所謂對外分發(fā)要慎重。配置完成后直接make -j8i7級別機(jī)器完整編一遍大概五六分鐘。編完在源碼目錄下找ffmpeg.exe和ffprobe.exe。3.3 編譯完成的驗證與打包驗證一定不要省file ffmpeg.exe ./ffmpeg.exe -versionfile確認(rèn)是PE32架構(gòu)-version確認(rèn)版本號是6.0.1再順手轉(zhuǎn)一個測試視頻確認(rèn)編碼器能工作./ffmpeg.exe -i test.mp4 -c:v libx264 -preset fast test_out.mp4如果要用到dll形式的運(yùn)行庫別忘了把MinGW32的bin目錄下對應(yīng)的32位dll一起拷出去。最簡單的辦法是編成靜態(tài)版本即configure時不加--enable-shared讓編出來的exe盡量自包含會省掉很多部署麻煩。4. Linux下編譯32位ffmpeg 6.0.1容器最省心Linux下的32位編譯我強(qiáng)烈建議用容器隔離不要在開發(fā)機(jī)上直接搞因為多架構(gòu)依賴很容易把系統(tǒng)環(huán)境搞亂。4.1 docker跑386容器避免環(huán)境污染用linux/386平臺起一個干凈的Debian或Ubuntu容器一步到位docker run --rm -it --platform linux/386 debian:bullseye bash進(jìn)容器后先裝編譯工具鏈和依賴apt update apt install -y build-essential yasm pkg-config libx264-dev注意容器已經(jīng)是386平臺理論上不需要再加-m32直接configure就行./configure --disable-doc --disable-debug --enable-gpl --enable-libx264 make -j$(nproc)這種方式最大的好處是容器內(nèi)的libx264.so、libmp3lame.so自動是32位的不會出現(xiàn)“編譯器是32位、庫卻是64位”的奇葩鏈接錯誤。我第一次自己搞的時候就是在64位宿主機(jī)上硬編被各種dso參數(shù)坑了整整一個下午。4.2 本機(jī)直接-m32編譯的依賴坑如果你不想用容器堅持在64位Linux宿主機(jī)上編譯32位目標(biāo)需要做兩件額外的事安裝multilib支持apt install gcc-multilib g-multilib沒有這個包-m32參數(shù)會直接報找不到bits/predefs.h之類的頭文件。32位開發(fā)庫64位系統(tǒng)默認(rèn)只裝了64位的libx264-dev想鏈接32位版本要么換裝:i386架構(gòu)包要么重新編譯一套32位依賴庫放進(jìn)自定義前綴目錄然后用--extra-ldflags-L/你的32位庫路徑強(qiáng)制指定。說句實話這套流程在純手工操作下非常容易翻車因為依賴庫之間的版本匹配、路徑匹配、pkg-config路徑匹配都要自己維護(hù)。非必要不推薦。4.3 靜態(tài)鏈接與動態(tài)鏈接的取舍Linux上這步的取舍比Windows更明顯。動態(tài)鏈接的話發(fā)布時要跟著帶上一堆.so.6、.so.7你無法預(yù)知用戶系統(tǒng)里到底裝了哪一版依賴。ffmpeg 6.0.1對庫的SONAME有要求版本不匹配經(jīng)常啟動就報undefined symbol。我更推薦靜態(tài)鏈接部署configure時加上--disable-shared --enable-static編譯選項里用-static或-static-libgcc -static-libstdc得到的就是一個能扔到任何相同架構(gòu)Linux上直接跑的裸二進(jìn)制。唯一要注意的是靜態(tài)鏈接GPL庫后分發(fā)二進(jìn)制時必須提供對應(yīng)的源碼獲取途徑這是GPL條款的要求商用場景下尤其別忽略。5. 運(yùn)行時的匹配問題dll、so與庫檢查方法很多人在這一步卡住ffmpeg.exe明明就在當(dāng)前目錄雙擊卻提示“找不到libx264-168.dll”或者“不是有效的Win32應(yīng)用程序”。這里把排查手段講透。5.1 32位程序在64位系統(tǒng)上的加載機(jī)制Windows 64位系統(tǒng)通過WoW64層運(yùn)行32位程序正常情況下32位exe能正常運(yùn)行。但如果缺失32位依賴dll錯誤提示五花八門最常見的是“找不到XXX.dll”和“應(yīng)用程序無法啟動”。核心原則32位進(jìn)程只能加載32位dll64位進(jìn)程只能加載64位dll。別指望把64位的libx264.dll改名放到syswow64目錄就能騙過加載器它不看文件名看PE頭里的機(jī)器類型。所以如果你下載的ffmpeg是32位完整的full版理論上自帶所有dll但如果只拷貝了exe而漏了dll啟動就會失敗。5.2 Windows與Linux下的架構(gòu)檢查命令Windows排查依賴與架構(gòu)我常用這幾個手段查看exe/dll架構(gòu)dumpbin /headers查看exe依賴了哪些dll和它們的位置用Process Explorer或dumpbin /dependents32位dll不見得存放在System32里很多第三方組件裝到應(yīng)用目錄或SysWOW64別只盯著一個目錄找Linux下更直接file ffmpeg ldd ffmpeg$ file ffmpeg ffmpeg: ELF 32-bit LSB executable, Intel 80386, dynamically linked, ... $ ldd ffmpeg linux-gate.so.1 (0xf7f7a000) libx264.so.164 /usr/lib/i386-linux-gnu/libx264.so.164file輸出里能看到“ELF 32-bit”字樣ldd列出的依賴庫路徑如果指向i386-linux-gnu目錄說明依賴也是32位的鏈路沒問題。另外查看.a靜態(tài)庫是32位還是64位也是靠filefile libavcodec.a輸出顯示i386是32位x86-64是64位。這個排查在集成SDK時非常常用。5.3 常見運(yùn)行錯誤與排查幾個我在實際運(yùn)行中反復(fù)踩過的坑列出來你對照看“不是有效的Win32應(yīng)用程序”你拿64位exe往32位系統(tǒng)或32位進(jìn)程里塞或者反之。檢查exe架構(gòu)即可?！罢也坏絛ll”依賴沒帶全用dumpbin /dependents看依賴列表把對應(yīng)32位dll補(bǔ)齊。Linux下報cannot execute binary file: Exec format error架構(gòu)不匹配可能拿32位二進(jìn)制往64位系統(tǒng)上放但沒開multiarch支持。64位系統(tǒng)默認(rèn)能跑32位用戶態(tài)程序但缺32位動態(tài)鏈接器ld-linux.so.2時就會報這個錯裝libc6:i386解決。6. 32位版日常操作命令截圖、合并、推流一次說清拿到32位ffmpeg后日常最常見的幾個操作這里把命令和參數(shù)邏輯一并寫清楚。6.1 截圖與基礎(chǔ)轉(zhuǎn)碼視頻里截一幀出來做封面、做預(yù)覽是使用頻率最高的操作ffmpeg -i input.mp4 -vframes 1 output.png-vframes 1的意思是只處理一幀。熱詞里提到加了這個參數(shù)還是報“the specified filename”錯誤多半是輸出路徑不存在或者文件名里帶了非法字符Windows下尤其注意別用反斜杠結(jié)尾?；A(chǔ)轉(zhuǎn)碼相對直觀ffmpeg -i input.mp4 -c:v libx264 -preset fast -crf 23 -c:a aac output.mp4-crf 23是H.264的默認(rèn)質(zhì)量值越小越清晰、文件越大。個人經(jīng)驗是19到23之間日常夠用真正要批量處理時先用一個小段測試找到均衡點再全量跑。6.2 合并ts與m3u8轉(zhuǎn)mp4很多流媒體緩存放下來是一段段ts切片合并用concat協(xié)議最簡單ffmpeg -f concat -safe 0 -i list.txt -c copy output.tslist.txt內(nèi)容格式file seg1.ts file seg2.ts file seg3.ts注意-safe 0要放在-i之前不然安全模式默認(rèn)不允許絕對路徑。合并完再轉(zhuǎn)成mp4或者直接對m3u8索引文件操作ffmpeg -i playlist.m3u8 -c copy output.mp4如果服務(wù)器帶寬不穩(wěn)定建議先完整下載切片到本地再合并直接-i指定m3u8容易因為網(wǎng)絡(luò)抖動中途失敗。6.3 推流參數(shù)中的-y、-re到底什么意思這兩個參數(shù)幾乎每次推流都會出現(xiàn)但很多人只是照抄-y覆蓋輸出文件。推流時輸出是一個RTMP/RTSP地址原本不存在“覆蓋”的問題但如果你在調(diào)試階段輸出到本地文件不加-y時每次都會被詢問是否覆蓋腳本里就會卡住。-re按原始幀率讀取輸入。它的作用是讓ffmpeg以“實時”速度讀文件而不是一口氣讀完。推流場景必須加否則ffmpeg會以最快速度把視頻推完導(dǎo)致畫面像開了倍速直播流瞬間就結(jié)束。典型推流命令ffmpeg -re -i input.mp4 -c copy -f flv rtmp://your-server/live/stream-c copy表示不做轉(zhuǎn)碼直接把原始編碼數(shù)據(jù)打包進(jìn)FLV。如果你要推給不支持H.265的流媒體服務(wù)需要先把輸入轉(zhuǎn)成H.264ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -c:a aac -f flv rtmp://your-server/live/stream32位ffmpeg在轉(zhuǎn)碼和推流上的性能和64位版本差距其實沒有想象中那么大主要差異出在硬件加速編解碼器上某些GPU硬編庫沒有32位版本這就只能軟編頂上了。說到最后我還是想提醒一句如果你只是普通使用直接去下載現(xiàn)成的32位靜態(tài)構(gòu)建就行別為了折騰而折騰。但如果你要鎖定6.0.1、要裁剪模塊、要集成進(jìn)自己的32位程序那就按照上面容器或MSYS2的流程自己編譯這份源碼樹是干凈的產(chǎn)物也完全可控。整個過程里最容易忽略的從來不是configure參數(shù)而是架構(gòu)驗證和依賴庫的架構(gòu)匹配——文件到手、庫鏈接好之后記得先跑一遍file和對應(yīng)系統(tǒng)的依賴檢查命令再放進(jìn)真實環(huán)境驗證一遍轉(zhuǎn)碼、截圖、推流三條主流程這樣才算是真正把32位ffmpeg用踏實了。本文還有配套的精品資源點擊獲取