1. 為什么非要自己編譯一份FFmpeg如果你只是想推 H.264 的 RTMP 流Ubuntu 18.04 上通過 apt 直接安裝的 FFmpeg 完全夠用系統(tǒng)源里那個(gè) 3.4 版本雖然老但推流 H.264 一點(diǎn)問題沒有?？尚枨笠坏┳兂伞鞍?H.265 畫面推成 RTMP”自帶版本立刻翻臉報(bào)錯(cuò)非常直接[flv 0x...] Could not find tag for codec hevc in stream #0, codec not currently supported in container這句話翻譯過來就是FLV 封裝器muxer的編碼格式表里根本沒有 HEVC 這個(gè)條目它不知道該怎么把 H.265 的數(shù)據(jù)包塞進(jìn) FLV/RTMP 的流里。這不是你的參數(shù)寫錯(cuò)了也不是 FFmpeg 不認(rèn)識(shí) H.265而是 RTMP 的老協(xié)議規(guī)范在設(shè)計(jì)時(shí)只認(rèn) H.264、VP6 那一批老編碼格式。要解決這個(gè)問題本質(zhì)上就兩條路要么換用新版 FFmpeg 內(nèi)建的增強(qiáng) RTMP 能力要么自己改源碼、讓 FLV 封裝器支持 HEVC。目前生產(chǎn)環(huán)境里大量攝像頭方案、直播服務(wù)端和自研播放器沿用的還是“HEVC codec id 12”這套老約定所以自己編譯一份打過補(bǔ)丁的 FFmpeg反而是最通用、最好控制的做法。這篇文章就完整記錄我在 Ubuntu 18.04 下從零編譯、打補(bǔ)丁、推流驗(yàn)證的全過程所有步驟都按可復(fù)現(xiàn)的粒度寫清楚了。1.1 系統(tǒng)自帶FFmpeg到底缺了什么Ubuntu 18.04 的 apt 源里的 FFmpeg默認(rèn)沒有開啟 libx265 編碼器也沒有完整的 RTMP 推流能力。更重要的是它作為一份“原版”代碼遵循的是 RTMP/FLV 的原始規(guī)范而原始規(guī)范里沒有 H.265 的位置。所以哪怕你手動(dòng)裝了 libx265-dev系統(tǒng)自帶那份 FFmpeg 也不會(huì)讓你把 H.265 數(shù)據(jù)封裝進(jìn) FLV 容器里。有人可能想用-c:v libx265去推結(jié)果發(fā)現(xiàn)命令剛執(zhí)行就停在初始化階段根本到不了編碼那一步。這就是因?yàn)榉庋b器在avformat_write_header階段檢查編碼格式表時(shí)發(fā)現(xiàn) HEVC 沒有對(duì)應(yīng)的 FLV codec tag于是直接拒絕了輸出。搞清楚這個(gè)報(bào)錯(cuò)出現(xiàn)的時(shí)機(jī)很重要它不是推流中途才掛而是輸出格式初始化時(shí)就掛了。另外還要理解一層關(guān)系FFmpeg 推 RTMP實(shí)際是“flv 封裝器”拼出 FLV tag 的字節(jié)流然后把字節(jié)流交給“rtmp 協(xié)議層”發(fā)送到服務(wù)器。RTMP 協(xié)議層本身對(duì)視頻編碼格式并不敏感它只是搬運(yùn) FLV 數(shù)據(jù)塊。真正攔路的是 flv 封裝器那一層所以補(bǔ)丁的主戰(zhàn)場在libavformat/flvenc.c和libavformat/flv.h。1.2 這套補(bǔ)丁方案的來龍去脈FLV 容器里視頻 tag 的第一個(gè)字節(jié)用低 4 位表示視頻編碼 ID。原規(guī)范里H.264 對(duì)應(yīng) ID 7VP6 對(duì)應(yīng) ID 4所以你在抓包工具里看到的 H.264 視頻 tag 首字節(jié)一般是 0x17關(guān)鍵幀或 0x27非關(guān)鍵幀。而 H.265 在原規(guī)范里根本沒有官方 ID。后來為了在 RTMP 鏈路里跑 H.265行業(yè)內(nèi)逐步形成了一個(gè)事實(shí)約定把 codec id 120x0C定義為 HEVC。支持“H.265 RTMP”的流媒體服務(wù)器和播放器都是拿著這個(gè) ID 互相認(rèn)的。服務(wù)器看到視頻 tag 首字節(jié)低 4 位是 12就知道接下來按 H.265 的配置記錄格式解析播放器也是靠這個(gè) ID 決定調(diào)用哪個(gè)解碼器。我們要打的補(bǔ)丁本質(zhì)就是把 FFmpeg 的 FLV 封裝器改造成能輸出這套格式第一在編碼格式表里登記 HEVC 與 codec id 12 的映射關(guān)系第二像 H.264 那樣在關(guān)鍵幀之前把 H.265 的配置記錄HEVCDecoderConfigurationRecord里面包含 VPS、SPS、PPS作為 sequence header 發(fā)出去第三把編碼器輸出的 Annex B 格式 NAL 包轉(zhuǎn)成 FLV 里使用的 length-prefixed 形式。這三件事做完FFmpeg 就能把 H.265 畫面推成 RTMP 流了。1.3 誰需要、誰不需要這套方案先潑點(diǎn)冷水。H.265 推 RTMP 不是“推出去誰都能播”的通用能力它需要服務(wù)器端和播放端都認(rèn)這套約定。如果你只是本地錄文件、推 H.264、或者播放端完全不受控比如只能用通用桌面播放器那就沒必要折騰編譯。很多桌面播放器至今只認(rèn) RTMP 里的 H.264你推 H.265 過去就是黑屏或花屏這不是你編碼參數(shù)的問題是播放端壓根不認(rèn)這個(gè)格式。反過來如果你在做直播采集、攝像頭/NVR 上云、低帶寬直播、或者自研播放器那這套方案就非常值。H.265 在同等畫質(zhì)下碼率通常比 H.264 省 30% 到 50%同樣是 1080p 畫面H.264 可能要 4 到 6 MbpsH.265 壓到 2.5 到 3.5 Mbps 就能達(dá)到差不多的觀感。帶寬成本下來之后服務(wù)器壓力、存儲(chǔ)成本都會(huì)跟著降。下文所有操作都默認(rèn)你是“自己控制服務(wù)端和播放端”的場景。2. 環(huán)境準(zhǔn)備Ubuntu 18.04 的依賴安裝2.1 系統(tǒng)基礎(chǔ)工具編譯 FFmpeg 第一步是裝好編譯工具鏈。Ubuntu 18.04 的默認(rèn)源里這些東西都有直接 apt 安裝即可sudo apt update sudo apt install -y build-essential pkg-config git curl如果你用的 Ubuntu 18.04 已經(jīng)比較舊apt update 可能會(huì)遇到源失效的情況這是老版本鏡像下線導(dǎo)致的。解決辦法就是把 apt 源切換到當(dāng)前還能用的鏡像源具體切換方式每家公司鏡像都有說明這里不展開。裝好之后確認(rèn)一下gcc --version能正常輸出別在編譯中途才想起編譯器沒裝。這里有一個(gè)實(shí)際經(jīng)驗(yàn)不要圖省事用 Ubuntu 20.04 或更新系統(tǒng)的 apt 包去湊合。標(biāo)題既然限定在 18.04就按 18.04 的依賴情況來因?yàn)椴煌到y(tǒng)版本里 x265 庫的版本、soname 都不一樣混著用藥不對(duì)癥。2.2 匯編器為什么必須裝sudo apt install -y yasm nasm這兩個(gè)匯編器不是可選依賴是硬依賴。FFmpeg 的 x86 平臺(tái)優(yōu)化代碼、x264、x265 的匯編加速都依賴它們。很多人編譯 x264 或 FFmpeg 時(shí)卡在nasm not found就是少了這一步。Ubuntu 18.04 源里的 nasm 版本是 2.13.02yasm 是 1.3.0對(duì) FFmpeg 4.4 和 x265 2.6 來說完全夠用。值得多提一句的是yasm 和 nasm 的語法體系不同不能互相替代。FFmpeg 內(nèi)部大量內(nèi)聯(lián)匯編用的是 nasm/yasm 兩套都能處理的格式但 x264 編譯時(shí)需要 nasmlibvpx 也需要。所以別偷懶兩個(gè)都裝上一勞永逸。2.3 編解碼依賴庫清單推流 H.265 到 RTMP音頻那邊通常還需要 AAC所以除了 x265 之外建議把常用編解碼庫一次裝齊。下面是我實(shí)測可用的安裝命令sudo apt install -y libx264-dev libx265-dev libvpx-dev libmp3lame-dev libopus-dev sudo apt install -y libfdk-aac-dev如果你執(zhí)行apt install libfdk-aac-dev提示找不到包說明系統(tǒng)沒開 multiverse 軟件源。Ubuntu 18.04 的 fdk-aac 在 multiverse 里開一下源再裝sudo apt install -y software-properties-common sudo add-apt-repository multiverse sudo apt update sudo apt install -y libfdk-aac-dev這套依賴?yán)飈ibx264 和 libx265 是核心。x264 是為了留一條 H.264 推流的后路萬一目標(biāo)服務(wù)器不認(rèn) H.265你還能切回去libvpx、libmp3lame、libopus 是音頻和 VP8/VP9 編碼的補(bǔ)充裝上之后 FFmpeg 的可選編碼覆蓋就比較完整了。libfdk-aac 是目前 FFmpeg 里質(zhì)量最好的 AAC 編碼器但它的許可證和 GPL 不兼容所以后續(xù) configure 需要加--enable-nonfree這一點(diǎn)到配置時(shí)再說。2.4 關(guān)于libx265版本的一句話提醒Ubuntu 18.04 自帶的 libx265-dev 是 2.x 老版本只有 8-bit 編碼能力。對(duì)直播場景來說8-bit 反而更穩(wěn)因?yàn)橥屏鞲袷胶筒シ哦私獯a器大多按 8-bit 驗(yàn)證。如果你的項(xiàng)目確實(shí)需要 10-bit H.265或者想要新版 x265 的速度優(yōu)化那建議單獨(dú)從源碼編譯一份更新的 x265再把 FFmpeg 的 configure 指向它。本文后面全都基于 apt 版本的 libx265-dev先把鏈路跑通升級(jí) x265 是后面的事。裝完依賴之后可以用dpkg -l | grep -E libx26|libfdk快速核對(duì)一下幾個(gè)關(guān)鍵包是否在位。3. 源碼獲取與 H.265 補(bǔ)丁的三個(gè)關(guān)鍵修改3.1 選擇哪個(gè)FFmpeg版本我推薦用 4.4.x 分支下文以 4.4.2 為例。這個(gè)版本在攝像頭、編碼器、直播服務(wù)商的項(xiàng)目里用得非常多穩(wěn)定性已經(jīng)過大量生產(chǎn)驗(yàn)證。5.x、6.x 分支也能改但代碼位置有差異網(wǎng)上找到的很多補(bǔ)丁也是按 4.x 寫的。另外一個(gè)現(xiàn)實(shí)問題新版 FFmpeg 主線對(duì)增強(qiáng) RTMP 有了原生支持它用 FourCC比如 “hvc1” 標(biāo)識(shí) H.265的方式工作這和我們要打的“codec id 12”老補(bǔ)丁格式不是一套。如果你的服務(wù)端和播放器是按老格式實(shí)現(xiàn)的直接拿新版 FFmpeg 推流雙方對(duì)不上反而推不進(jìn)去。所以做生產(chǎn)集成時(shí)版本鎖定很重要。下載源碼wget -c https://ffmpeg.org/releases/ffmpeg-4.4.2.tar.xz tar xf ffmpeg-4.4.2.tar.xz cd ffmpeg-4.4.23.2 補(bǔ)丁第一處flv.h 增加 codec id先打開libavformat/flv.h找到聲明 FLV codec id 的枚舉位置在里面加一行enum { FLV_CODECID_VP6F 5, FLV_CODECID_H264 7, FLV_CODECID_AAC 10, FLV_CODECID_H265 12, // 新增H.265 over RTMP 的行業(yè)通行 ID };注意這個(gè) 12 不是 FLV 原規(guī)范定義的它是業(yè)界為了讓 H.265 走 RTMP 而約定出來的擴(kuò)展值。你熟悉的 H.264 對(duì)應(yīng) 7所以你在網(wǎng)上看到的視頻 tag 首字節(jié) 0x17、0x27 就是“幀類型 codec id 7”拼出來的。H.265 對(duì)應(yīng) 12首字節(jié)就是 0x2C關(guān)鍵幀、0x3C非關(guān)鍵幀這類組合。3.3 補(bǔ)丁第二處flvenc.c 的 codec tag 表接著打開libavformat/flvenc.c找到flv_video_codec_ids[]數(shù)組在 H264 那行后面加一行static const AVCodecTag flv_video_codec_ids[] { { AV_CODEC_ID_FLV1, FLV_CODECID_SCREENVIDEO }, { AV_CODEC_ID_VP6, FLV_CODECID_VP6 }, { AV_CODEC_ID_VP6F, FLV_CODECID_VP6 }, { AV_CODEC_ID_H264, FLV_CODECID_H264 }, { AV_CODEC_ID_HEVC, FLV_CODECID_H265 }, // 新增 { AV_CODEC_ID_NONE, 0} };這個(gè)數(shù)組是 FLV 封裝器判斷“某種編碼能不能裝進(jìn) FLV”的依據(jù)。av_codec_get_tag在寫頭的時(shí)候會(huì)查這張表查不到就直接報(bào)Could not find tag for codec hevc。加了這行報(bào)錯(cuò)自然消失。3.4 補(bǔ)丁第三處寫 sequence header這是最關(guān)鍵的一處也是難度最高的一處。H.264 在 FLV 里的封裝套路是第一個(gè)視頻 tag 不攜帶圖像數(shù)據(jù)而是攜帶 AVCDecoderConfigurationRecord里面是 SPS、PPS 等解碼參數(shù)這個(gè) tag 的第二個(gè)字節(jié)是 0表示“sequence header”。之后每個(gè)真正的幀用四字節(jié)長度前綴把 NAL 單元串起來。H.265 要照葫蘆畫瓢把它的 HEVCDecoderConfigurationRecord里面是 VPS、SPS、PPS作為 sequence header 發(fā)出去。在flv_write_packet函數(shù)里找到 H264 的分支在它后面加一個(gè) HEVC 分支大致邏輯如下} else if (par-codec_id AV_CODEC_ID_HEVC) { if (par-extradata par-extradata_size 0) { avio_w8(pb, 0x2C); // 關(guān)鍵幀 H265 codec id 12 avio_w8(pb, 0); // AVCPacketType: sequence header avio_w24(pb, 0); // CompositionTime 設(shè)為 0 avio_write(pb, par-extradata, par-extradata_size); } }但注意光發(fā) extradata 還不夠真正的幀數(shù)據(jù)也要處理。H.264 的現(xiàn)有邏輯里如果編碼器給出的包以00 00 00 01開頭的 Annex B 起始碼flvenc.c 會(huì)調(diào)用ff_avc_parse_nal_units之類的函數(shù)把它轉(zhuǎn)成四字節(jié)長度前綴形式。HEVC 分支也要做同樣的轉(zhuǎn)換對(duì)應(yīng)的處理函數(shù)在h2645_parse相關(guān)代碼里可以找到啟發(fā)。很多現(xiàn)成的補(bǔ)丁干脆就是把 H264 分支復(fù)制一份把AV_CODEC_ID_H264換成AV_CODEC_ID_HEVC把 avc 配置記錄的處理換成 hevc 配置記錄的處理再在 codec id 的位置用 12實(shí)測就能跑通。這里我強(qiáng)調(diào)一句這部分修改因?yàn)?FFmpeg 版本不同、x265 版本不同代碼細(xì)節(jié)會(huì)有差異不要指望一個(gè) diff 拷遍天下。補(bǔ)丁的核心思想就三點(diǎn)——登記 codec id、發(fā)配置記錄、轉(zhuǎn) NAL 長度前綴。弄懂這三點(diǎn)遇到任何版本你都能自己改。3.5 解碼端要不要改如果你編譯這份 FFmpeg 只是為了推流那改上面三個(gè)地方就夠了不需要碰解碼端。但如果你想用這份 FFmpeg 自己拉流驗(yàn)證、或者做轉(zhuǎn)流轉(zhuǎn)發(fā)那libavformat/flvdec.c里也需要對(duì)應(yīng)的 H.265 解析支持否則播放的時(shí)候同樣會(huì)因?yàn)椴徽J(rèn)識(shí) codec id 12 而報(bào)錯(cuò)。實(shí)操建議是把推流和拉流分開先用支持 H.265 RTMP 的服務(wù)端和播放器驗(yàn)證封裝格式正確再用這份 FFmpeg 做推流端。不要一上來就指望同一個(gè)二進(jìn)制把拉流播放也全包了那樣排錯(cuò)時(shí)變量太多。4. configure、編譯與安裝4.1 configure參數(shù)逐項(xiàng)解讀打完全部補(bǔ)丁之后開始配置。下面是我在 Ubuntu 18.04 上驗(yàn)證過的一段完整 configure./configure \ --prefix/usr/local \ --enable-gpl \ --enable-nonfree \ --enable-libx264 \ --enable-libx265 \ --enable-libfdk-aac \ --enable-libmp3lame \ --enable-libopus \ --enable-libvpx \ --enable-pthreads幾個(gè)參數(shù)要說明白--enable-gplx264、x265 這些庫基于 GPLFFmpeg 要鏈接它們必須打開這個(gè)開關(guān)。--enable-nonfreelibfdk-aac 的許可證和 GPL 不兼容必須配合--enable-nonfree才能一起編。如果前面 fdk-aac 沒裝成功那這里就把--enable-libfdk-aac和--enable-nonfree一起去掉音頻用 FFmpeg 自帶的原生aac編碼器也能用只是質(zhì)量略遜。--enable-libx265這就是我們這次的主角H.265 編碼能力來自它。--enable-libx264保留 H.264 推流能力萬一服務(wù)器不支持 H.265 還能降級(jí)。--enable-pthreads多線程編碼x265 本身的多線程能力也需要它。配置完成后注意看輸出末尾的 configuration 匯總應(yīng)該有x265 yes之類的字樣。如果沒有多半是 pkg-config 找不到 x265 庫回頭檢查 libx265-dev 是否真的裝上了。4.2 編譯與安裝make -j$(nproc)這里有個(gè)實(shí)際教訓(xùn)-j$(nproc)在核心多的機(jī)器上會(huì)把內(nèi)存吃滿。FFmpeg 鏈接階段很吃內(nèi)存如果你只有 4G 內(nèi)存還開 16 核并行很容易 OOM。保守起見內(nèi)存不夠就手動(dòng)限制make -j4編譯完成后sudo make install sudo ldconfigldconfig這步很多人會(huì)漏。FFmpeg 默認(rèn)裝到/usr/local/lib如果系統(tǒng) ldconfig 緩存里沒有這個(gè)路徑運(yùn)行時(shí)就會(huì)報(bào)error while loading shared libraries: libavcodec.so.58。穩(wěn)妥的做法是把路徑寫進(jìn) ld 配置echo /usr/local/lib | sudo tee /etc/ld.so.conf.d/ffmpeg.conf sudo ldconfig4.3 驗(yàn)證編譯結(jié)果裝完之后先確認(rèn)用的是不是剛編譯出來的那份which ffmpeg ffmpeg -version | head -n 5如果which ffmpeg顯示的還是/usr/bin/ffmpeg說明 shell 的路徑緩存或 PATH 順序有問題先hash -r或者直接跑/usr/local/bin/ffmpeg -version驗(yàn)證。接著檢查我們最關(guān)心的兩樣ffmpeg -hide_banner -encoders | grep 265 ffmpeg -hide_banner -protocols | grep rtmp第一行應(yīng)該能看到libx265第二行應(yīng)該能看到rtmp。最后再確認(rèn)一下編譯配置ffmpeg -hide_banner -buildconf | grep -E x265|fdk|gpl能看到--enable-libx265就說明這份二進(jìn)制確實(shí)帶 H.265 編碼能力補(bǔ)丁也在這個(gè)二進(jìn)制里生效了。5. 推流實(shí)操H.265編碼 RTMP5.1 一條能跑的推流命令編譯和補(bǔ)丁都正常后推流命令反而不復(fù)雜。從一個(gè)本地文件推流最簡單的形態(tài)是這樣ffmpeg -re -i 1080p.mp4 \ -c:v libx265 -preset veryfast -b:v 3000k \ -maxrate 3600k -bufsize 6000k \ -c:a aac -b:a 128k -ar 44100 \ -g 60 -keyint_min 60 -sc_threshold 0 \ -x265-params bframes0 \ -f flv rtmp://你的服務(wù)器地址/live/test逐個(gè)解釋。-re表示按原視頻的幀率來讀文件模擬實(shí)時(shí)推流不加這個(gè)參數(shù) FFmpeg 會(huì)以最快速度讀完文件然后瞬間推完直播場景必須加。-c:v libx265指定 H.265 編碼器。-b:v 3000k是目標(biāo)碼率1080p H.265 直播一般 2.5 到 4 Mbps 之間就能達(dá)到可用畫質(zhì)這個(gè)值需要根據(jù)內(nèi)容動(dòng)態(tài)微調(diào)。-preset veryfast是編碼速度和壓縮率的折中直播場景推薦 veryfast 或 faster別用 medium延遲會(huì)變大、CPU 占用也高。音頻方面-c:a aac用的是 FFmpeg 原生 AAC 編碼器如果你編譯時(shí)帶上了 fdk-aac可以換成-c:a libfdk_aac音質(zhì)更好。-g 60是 GOP 大小也就是每 60 幀一個(gè)關(guān)鍵幀在 30 幀率下相當(dāng)于 2 秒一個(gè)關(guān)鍵幀這個(gè)值對(duì)直播延遲和首開速度影響很大。-x265-params bframes0是關(guān)掉 B 幀直播場景強(qiáng)烈建議關(guān)能讓播放端不用為了重排幀序多等時(shí)間。5.2 直播編碼參數(shù)的核心取舍關(guān)于 H.265 直播參數(shù)有幾個(gè)取舍值得單獨(dú)說。第一是碼率控制方式。VOD 場景用-crf恒定質(zhì)量很舒服但直播場景網(wǎng)絡(luò)帶寬是固定的我更推薦用-b:v配合-maxrate、-bufsize做限速這樣碼率波動(dòng)不會(huì)把上行帶寬打滿。如果非要 CRF建議范圍在 26 到 30 之間超過 32 畫面細(xì)節(jié)就開始明顯丟失了。第二是 GOP 和延遲的關(guān)系。關(guān)鍵幀間隔越短播放端啟播越快、拖到關(guān)鍵幀的等待時(shí)間越短但碼率開銷越大。直播場景 1 到 2 秒一個(gè)關(guān)鍵幀是比較平衡的選擇。有些人圖省事寫-g 0那在推流場景會(huì)出問題因?yàn)椴糠址?wù)端認(rèn)定關(guān)鍵幀間隔太大會(huì)主動(dòng)斷連。第三是 B 幀問題。RTMP/FLV 容器本身通過 CompositionTime 字段是支持 B 幀的但很多低延遲播放器收到帶 B 幀的流要等重排延遲直接上去。-x265-params bframes0這個(gè)參數(shù)實(shí)測對(duì)延遲幫助非常明顯而且犧牲的畫質(zhì)微乎其微。5.3 攝像頭或采集卡輸入如果你是做攝像頭接入輸入源就不是 mp4 文件而是 v4l2 設(shè)備。命令形態(tài)類似這樣sudo ffmpeg -f v4l2 -framerate 25 -video_size 1920x1080 \ -input_format yuyv422 -i /dev/video0 \ -c:v libx265 -preset veryfast -b:v 2500k \ -f flv rtmp://你的服務(wù)器地址/live/camera01這里-video_size和-input_format要按攝像頭的實(shí)際輸出格式調(diào)整不少 USB 攝像頭直接出 MJPEG 格式這時(shí)把-input_format換成mjpeg能讓 CPU 負(fù)擔(dān)小很多。注意 v4l2 設(shè)備通常需要 root 權(quán)限或者把自己的用戶加進(jìn) video 組。5.4 播放端和服務(wù)端的配合驗(yàn)證推流命令起來了畫面能不能播取決于接收端是不是認(rèn)這套格式。如果服務(wù)端不支持 codec id 12推流可能表現(xiàn)為連接建立后沒有報(bào)錯(cuò)但服務(wù)器端日志能看到 FLV tag 解析異?；蛘吒纱嘣谖帐趾笾鲃?dòng)斷開。所以在正式環(huán)境上線前一定要先用一個(gè)支持 H.265 RTMP 的接收端做一次端到端驗(yàn)證。驗(yàn)證時(shí)最干凈的做法是先用支持 H.265 RTMP 的服務(wù)端收流再用自研播放器或打過對(duì)應(yīng)補(bǔ)丁的拉流播放鏈路看圖像。不要用通用桌面播放器去驗(yàn) H.265 RTMP大概率黑屏這會(huì)讓你誤以為是自己推流推錯(cuò)了。我個(gè)人的排查順序是先看推流端是否持續(xù)打印編碼日志再看服務(wù)端是否持續(xù)收到數(shù)據(jù)最后才懷疑播放端和解碼格式。6. 常見問題與排查技巧實(shí)錄6.1 問題速查表現(xiàn)象可能原因解決辦法configure 報(bào)ERROR: libx265 not foundlibx265-dev 沒裝好或 pkg-config 路徑不對(duì)重裝 libx265-dev檢查/usr/lib/pkgconfig下有沒有 x265.pcmake 后運(yùn)行 ffmpeg 報(bào)cannot open shared object fileldconfig 緩存里沒有 /usr/local/lib執(zhí)行l(wèi)dconfig或?qū)懭?etc/ld.so.conf.d/ffmpeg.conf推流直接報(bào)Could not find tag for codec hevcflv_video_codec_ids 數(shù)組沒加 HEVC 映射檢查補(bǔ)丁第二處是否生效推流能建立但播放端黑屏sequence header 沒發(fā)對(duì)或播放端不認(rèn) codec id 12檢查 HEVC 分支是否寫入 extradata換一個(gè)支持 H.265 RTMP 的播放端驗(yàn)證出現(xiàn)Non-monotonous DTS警告時(shí)間戳不連續(xù)常見于沒加-re或 B 幀引發(fā)推流加-re直播參數(shù)里加bframes0服務(wù)器連上就斷服務(wù)端不認(rèn) H.265 RTMP 擴(kuò)展換支持該約定的服務(wù)器或用 H.264 降級(jí)測試CPU 占用接近滿載preset 太慢、分辨率太高、碼率控制沒做好換-preset veryfast限制分辨率用-b:v限碼率6.2 最隱蔽的坑補(bǔ)丁沒生效但編譯也不報(bào)錯(cuò)這可能是最坑的一點(diǎn)。有些情況下你改了flv.h和flvenc.c但實(shí)際編譯的時(shí)候用的還是舊的目標(biāo)文件FFmpeg 的增量編譯偶爾會(huì)騙人。最穩(wěn)的做法是改完源碼后先make clean再重新 configure 和 make或者干脆刪掉整個(gè)源碼目錄重新解壓、重新打補(bǔ)丁。我踩過一次這個(gè)坑花了大半個(gè)晚上排查最后發(fā)現(xiàn)是增量編譯用了舊的 flv 封裝器對(duì)象文件。另外如果你的編譯過程有多個(gè)工作目錄或者用了別的構(gòu)建腳本務(wù)必確認(rèn)ffmpeg -buildconf里顯示的就是你當(dāng)前源碼目錄這次 configure 的結(jié)果。用strings去 grep 二進(jìn)制里有沒有 HEVC 相關(guān)字符串也是個(gè)快速檢查法但最直接還是看自己的補(bǔ)丁步驟有沒有真正執(zhí)行。6.3 推流端正常但服務(wù)端拒收這種情況多半不是編譯問題而是兩邊的格式約定不一致。現(xiàn)在凡是支持 H.265 RTMP 的服務(wù)端內(nèi)部實(shí)現(xiàn)也可能有細(xì)微差異有的嚴(yán)格校驗(yàn) sequence header 的格式有的只認(rèn)特定的 VPS 層級(jí)有的要求 extradata 必須是完整 HEVCDecoderConfigurationRecord少一個(gè)數(shù)組就斷流。實(shí)測中我最常遇到的就是 x265 在某些參數(shù)下輸出的 extradata 結(jié)構(gòu)和服務(wù)端解析器不兼容。遇到這種情況先用最簡單的參數(shù)組合測試-profile:v main、-pix_fmt yuv420p、bframes0把變量降到最少。H.265 RTMP 這條鏈路本身就處在“事實(shí)標(biāo)準(zhǔn)”的地帶參數(shù)越花哨踩到兼容性問題的概率越大。等基礎(chǔ)鏈路通了再慢慢往上加編碼質(zhì)量參數(shù)。6.4 低配機(jī)器編譯時(shí)的內(nèi)存問題如果你是在云服務(wù)器或者老舊的工控機(jī)上編譯內(nèi)存只有 2 到 4 G那么make -j$(nproc)很容易把內(nèi)存打滿表現(xiàn)為編譯中途進(jìn)程被內(nèi)核殺掉。解決辦法是限制并行度make -j2甚至make -j1同時(shí)關(guān)掉不必要的服務(wù)釋放內(nèi)存。編譯 FFmpeg 本身不像編譯 chromium 那么恐怖但鏈接階段的瞬間內(nèi)存確實(shí)不小別掉以輕心。6.5 關(guān)于10-bit H.265的兼容性提醒如果后續(xù)你把 x265 換成了 10-bit 版本推流前先確認(rèn)-pix_fmt是yuv420p10le并且在配置 ESP 時(shí)考慮播放端的解碼能力。很多嵌入式和網(wǎng)頁播放器只支持 8-bit 解碼10-bit 推流會(huì)導(dǎo)致花屏或者完全沒有圖像。我的建議是RTMP H.265 場景老老實(shí)實(shí)用 8-bit Main Profile10-bit 留給文件存儲(chǔ)和高畫質(zhì)點(diǎn)播場景。7. 個(gè)人實(shí)操心得與后續(xù)擴(kuò)展思路編譯這份 FFmpeg 的前前后后我最大的體會(huì)是工作量其實(shí)不在編譯本身而在理解封裝器那三層邏輯——codec tag 表、sequence header、NAL 格式轉(zhuǎn)換。一旦你把這三件事想透了以后無論是換 FFmpeg 版本、加新的編碼格式還是排查兼容性問題思路都會(huì)清晰很多。很多人卡在“編譯失敗了”這一步其實(shí)回去看看 configure 的輸出百分之八十的問題都在依賴庫沒裝全。補(bǔ)丁管理上我的建議是不要直接在源碼目錄里用 sed 或手改完就扔而是把修改整理成一個(gè)獨(dú)立的 diff 文件下次解壓新源碼后一條命令打上去。這樣既方便版本升級(jí)時(shí)復(fù)用也方便團(tuán)隊(duì)協(xié)作時(shí)讓別人 review 你到底改了哪里。我的習(xí)慣是命名成h265_rtmp.patch和源碼放在同一個(gè)目錄管理。如果未來不想維護(hù)這套老補(bǔ)丁可以關(guān)注新版 FFmpeg 主線對(duì)增強(qiáng) RTMP 的支持。它用 FourCC 的方式重新定義了 H.265 在 RTMP 里的封裝格式理論上更規(guī)范。但要注意增強(qiáng) RTMP 和本文講的 codec id 12 老格式并不等價(jià)服務(wù)端和播放端都需要升級(jí)才能兼容。所以現(xiàn)有的攝像頭、編碼器項(xiàng)目如果已經(jīng)在線上跑著老協(xié)議不要盲目升級(jí)先做兼容性測試。這個(gè)方案后續(xù)還可以做一些很實(shí)用的擴(kuò)展。比如把這套FFmpeg 集成進(jìn)推流腳本配合 shell 或服務(wù)端程序做多路攝像頭輪詢推流比如在推流的同時(shí)用-f flv落一份本地備份方便事后回看再比如把目標(biāo)碼率、GOP、分辨率做成配置文件按場景動(dòng)態(tài)切換參數(shù)。H.265 over RTMP 這個(gè)鏈路目前看還會(huì)在生產(chǎn)環(huán)境存在很長一段時(shí)間自己掌握編譯能力比每次都去網(wǎng)上找一個(gè)別人編譯好的二進(jìn)制要靠譜得多。