1. 為什么非要自己編譯一份FFmpeg如果你只是想推 H.264 的 RTMP 流Ubuntu 18.04 上通過(guò) apt 直接安裝的 FFmpeg 完全夠用系統(tǒng)源里那個(gè) 3.4 版本雖然老但推流 H.264 一點(diǎn)問(wèn)題沒(méi)有?？尚枨笠坏┳兂伞鞍?H.265 畫(huà)面推成 RTMP”自帶版本立刻翻臉報(bào)錯(cuò)非常直接[flv 0x...] Could not find tag for codec hevc in stream #0, codec not currently supported in container這句話翻譯過(guò)來(lái)就是FLV 封裝器muxer的編碼格式表里根本沒(méi)有 HEVC 這個(gè)條目它不知道該怎么把 H.265 的數(shù)據(jù)包塞進(jìn) FLV/RTMP 的流里。這不是你的參數(shù)寫(xiě)錯(cuò)了也不是 FFmpeg 不認(rèn)識(shí) H.265而是 RTMP 的老協(xié)議規(guī)范在設(shè)計(jì)時(shí)只認(rèn) H.264、VP6 那一批老編碼格式。要解決這個(gè)問(wèn)題本質(zhì)上就兩條路要么換用新版 FFmpeg 內(nèi)建的增強(qiáng) RTMP 能力要么自己改源碼、讓 FLV 封裝器支持 HEVC。目前生產(chǎn)環(huán)境里大量攝像頭方案、直播服務(wù)端和自研播放器沿用的還是“HEVC codec id 12”這套老約定所以自己編譯一份打過(guò)補(bǔ)丁的 FFmpeg反而是最通用、最好控制的做法。這篇文章就完整記錄我在 Ubuntu 18.04 下從零編譯、打補(bǔ)丁、推流驗(yàn)證的全過(guò)程所有步驟都按可復(fù)現(xiàn)的粒度寫(xiě)清楚了。1.1 系統(tǒng)自帶FFmpeg到底缺了什么Ubuntu 18.04 的 apt 源里的 FFmpeg默認(rèn)沒(méi)有開(kāi)啟 libx265 編碼器也沒(méi)有完整的 RTMP 推流能力。更重要的是它作為一份“原版”代碼遵循的是 RTMP/FLV 的原始規(guī)范而原始規(guī)范里沒(méi)有 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 沒(méi)有對(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)場(chǎng)在libavformat/flvenc.c和libavformat/flv.h。1.2 這套補(bǔ)丁方案的來(lái)龍去脈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ī)范里根本沒(méi)有官方 ID。后來(lái)為了在 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就知道接下來(lái)按 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 畫(huà)面推成 RTMP 流了。1.3 誰(shuí)需要、誰(shuí)不需要這套方案先潑點(diǎn)冷水。H.265 推 RTMP 不是“推出去誰(shuí)都能播”的通用能力它需要服務(wù)器端和播放端都認(rèn)這套約定。如果你只是本地錄文件、推 H.264、或者播放端完全不受控比如只能用通用桌面播放器那就沒(méi)必要折騰編譯。很多桌面播放器至今只認(rèn) RTMP 里的 H.264你推 H.265 過(guò)去就是黑屏或花屏這不是你編碼參數(shù)的問(wèn)題是播放端壓根不認(rèn)這個(gè)格式。反過(guò)來(lái)如果你在做直播采集、攝像頭/NVR 上云、低帶寬直播、或者自研播放器那這套方案就非常值。H.265 在同等畫(huà)質(zhì)下碼率通常比 H.264 省 30% 到 50%同樣是 1080p 畫(huà)面H.264 可能要 4 到 6 MbpsH.265 壓到 2.5 到 3.5 Mbps 就能達(dá)到差不多的觀感。帶寬成本下來(lái)之后服務(wù)器壓力、存儲(chǔ)成本都會(huì)跟著降。下文所有操作都默認(rèn)你是“自己控制服務(wù)端和播放端”的場(chǎng)景。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)前還能用的鏡像源具體切換方式每家公司鏡像都有說(shuō)明這里不展開(kāi)。裝好之后確認(rèn)一下gcc --version能正常輸出別在編譯中途才想起編譯器沒(méi)裝。這里有一個(gè)實(shí)際經(jīng)驗(yàn)不要圖省事用 Ubuntu 20.04 或更新系統(tǒng)的 apt 包去湊合。標(biāo)題既然限定在 18.04就按 18.04 的依賴情況來(lái)因?yàn)椴煌到y(tǒng)版本里 x265 庫(kù)的版本、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 來(lái)說(shuō)完全夠用。值得多提一句的是yasm 和 nasm 的語(yǔ)法體系不同不能互相替代。FFmpeg 內(nèi)部大量?jī)?nèi)聯(lián)匯編用的是 nasm/yasm 兩套都能處理的格式但 x264 編譯時(shí)需要 nasmlibvpx 也需要。所以別偷懶兩個(gè)都裝上一勞永逸。2.3 編解碼依賴庫(kù)清單推流 H.265 到 RTMP音頻那邊通常還需要 AAC所以除了 x265 之外建議把常用編解碼庫(kù)一次裝齊。下面是我實(shí)測(cè)可用的安裝命令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提示找不到包說(shuō)明系統(tǒng)沒(méi)開(kāi) multiverse 軟件源。Ubuntu 18.04 的 fdk-aac 在 multiverse 里開(kāi)一下源再裝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 推流的后路萬(wàn)一目標(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í)再說(shuō)。2.4 關(guān)于libx265版本的一句話提醒Ubuntu 18.04 自帶的 libx265-dev 是 2.x 老版本只有 8-bit 編碼能力。對(duì)直播場(chǎng)景來(lái)說(shuō)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)過(guò)大量生產(chǎn)驗(yàn)證。5.x、6.x 分支也能改但代碼位置有差異網(wǎng)上找到的很多補(bǔ)丁也是按 4.x 寫(xiě)的。另外一個(gè)現(xiàn)實(shí)問(wèn)題新版 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先打開(kāi)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 而約定出來(lái)的擴(kuò)展值。你熟悉的 H.264 對(duì)應(yīng) 7所以你在網(wǎng)上看到的視頻 tag 首字節(jié) 0x17、0x27 就是“幀類(lèi)型 codec id 7”拼出來(lái)的。H.265 對(duì)應(yīng) 12首字節(jié)就是 0x2C關(guān)鍵幀、0x3C非關(guān)鍵幀這類(lèi)組合。3.3 補(bǔ)丁第二處flvenc.c 的 codec tag 表接著打開(kāi)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在寫(xiě)頭的時(shí)候會(huì)查這張表查不到就直接報(bào)Could not find tag for codec hevc。加了這行報(bào)錯(cuò)自然消失。3.4 補(bǔ)丁第三處寫(xiě) sequence header這是最關(guān)鍵的一處也是難度最高的一處。H.264 在 FLV 里的封裝套路是第一個(gè)視頻 tag 不攜帶圖像數(shù)據(jù)而是攜帶 AVCDecoderConfigurationRecord里面是 SPS、PPS 等解碼參數(shù)這個(gè) tag 的第二個(gè)字節(jié)是 0表示“sequence header”。之后每個(gè)真正的幀用四字節(jié)長(zhǎng)度前綴把 NAL 單元串起來(lái)。H.265 要照葫蘆畫(huà)瓢把它的 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開(kāi)頭的 Annex B 起始碼flvenc.c 會(huì)調(diào)用ff_avc_parse_nal_units之類(lèi)的函數(shù)把它轉(zhuǎn)成四字節(jié)長(zhǎng)度前綴形式。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 配置記錄的處理?yè)Q成 hevc 配置記錄的處理再在 codec id 的位置用 12實(shí)測(cè)就能跑通。這里我強(qiáng)調(diào)一句這部分修改因?yàn)?FFmpeg 版本不同、x265 版本不同代碼細(xì)節(jié)會(huì)有差異不要指望一個(gè) diff 拷遍天下。補(bǔ)丁的核心思想就三點(diǎn)——登記 codec id、發(fā)配置記錄、轉(zhuǎn) NAL 長(zhǎng)度前綴。弄懂這三點(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í)操建議是把推流和拉流分開(kāi)先用支持 H.265 RTMP 的服務(wù)端和播放器驗(yàn)證封裝格式正確再用這份 FFmpeg 做推流端。不要一上來(lái)就指望同一個(gè)二進(jìn)制把拉流播放也全包了那樣排錯(cuò)時(shí)變量太多。4. configure、編譯與安裝4.1 configure參數(shù)逐項(xiàng)解讀打完全部補(bǔ)丁之后開(kāi)始配置。下面是我在 Ubuntu 18.04 上驗(yàn)證過(guò)的一段完整 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ù)要說(shuō)明白--enable-gplx264、x265 這些庫(kù)基于 GPLFFmpeg 要鏈接它們必須打開(kāi)這個(gè)開(kāi)關(guān)。--enable-nonfreelibfdk-aac 的許可證和 GPL 不兼容必須配合--enable-nonfree才能一起編。如果前面 fdk-aac 沒(méi)裝成功那這里就把--enable-libfdk-aac和--enable-nonfree一起去掉音頻用 FFmpeg 自帶的原生aac編碼器也能用只是質(zhì)量略遜。--enable-libx265這就是我們這次的主角H.265 編碼能力來(lái)自它。--enable-libx264保留 H.264 推流能力萬(wàn)一服務(wù)器不支持 H.265 還能降級(jí)。--enable-pthreads多線程編碼x265 本身的多線程能力也需要它。配置完成后注意看輸出末尾的 configuration 匯總應(yīng)該有x265 yes之類(lèi)的字樣。如果沒(méi)有多半是 pkg-config 找不到 x265 庫(kù)回頭檢查 libx265-dev 是否真的裝上了。4.2 編譯與安裝make -j$(nproc)這里有個(gè)實(shí)際教訓(xùn)-j$(nproc)在核心多的機(jī)器上會(huì)把內(nèi)存吃滿。FFmpeg 鏈接階段很吃內(nèi)存如果你只有 4G 內(nèi)存還開(kāi) 16 核并行很容易 OOM。保守起見(jiàn)內(nèi)存不夠就手動(dòng)限制make -j4編譯完成后sudo make install sudo ldconfigldconfig這步很多人會(huì)漏。FFmpeg 默認(rèn)裝到/usr/local/lib如果系統(tǒng) ldconfig 緩存里沒(méi)有這個(gè)路徑運(yùn)行時(shí)就會(huì)報(bào)error while loading shared libraries: libavcodec.so.58。穩(wěn)妥的做法是把路徑寫(xiě)進(jìn) ld 配置echo /usr/local/lib | sudo tee /etc/ld.so.conf.d/ffmpeg.conf sudo ldconfig4.3 驗(yàn)證編譯結(jié)果裝完之后先確認(rèn)用的是不是剛編譯出來(lái)的那份which ffmpeg ffmpeg -version | head -n 5如果which ffmpeg顯示的還是/usr/bin/ffmpeg說(shuō)明 shell 的路徑緩存或 PATH 順序有問(wèn)題先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就說(shuō)明這份二進(jìn)制確實(shí)帶 H.265 編碼能力補(bǔ)丁也在這個(gè)二進(jìn)制里生效了。5. 推流實(shí)操H.265編碼 RTMP5.1 一條能跑的推流命令編譯和補(bǔ)丁都正常后推流命令反而不復(fù)雜。從一個(gè)本地文件推流最簡(jiǎn)單的形態(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表示按原視頻的幀率來(lái)讀文件模擬實(shí)時(shí)推流不加這個(gè)參數(shù) FFmpeg 會(huì)以最快速度讀完文件然后瞬間推完直播場(chǎng)景必須加。-c:v libx265指定 H.265 編碼器。-b:v 3000k是目標(biāo)碼率1080p H.265 直播一般 2.5 到 4 Mbps 之間就能達(dá)到可用畫(huà)質(zhì)這個(gè)值需要根據(jù)內(nèi)容動(dòng)態(tài)微調(diào)。-preset veryfast是編碼速度和壓縮率的折中直播場(chǎng)景推薦 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ì)直播延遲和首開(kāi)速度影響很大。-x265-params bframes0是關(guān)掉 B 幀直播場(chǎng)景強(qiáng)烈建議關(guān)能讓播放端不用為了重排幀序多等時(shí)間。5.2 直播編碼參數(shù)的核心取舍關(guān)于 H.265 直播參數(shù)有幾個(gè)取舍值得單獨(dú)說(shuō)。第一是碼率控制方式。VOD 場(chǎng)景用-crf恒定質(zhì)量很舒服但直播場(chǎng)景網(wǎng)絡(luò)帶寬是固定的我更推薦用-b:v配合-maxrate、-bufsize做限速這樣碼率波動(dòng)不會(huì)把上行帶寬打滿。如果非要 CRF建議范圍在 26 到 30 之間超過(guò) 32 畫(huà)面細(xì)節(jié)就開(kāi)始明顯丟失了。第二是 GOP 和延遲的關(guān)系。關(guān)鍵幀間隔越短播放端啟播越快、拖到關(guān)鍵幀的等待時(shí)間越短但碼率開(kāi)銷(xiāo)越大。直播場(chǎng)景 1 到 2 秒一個(gè)關(guān)鍵幀是比較平衡的選擇。有些人圖省事寫(xiě)-g 0那在推流場(chǎng)景會(huì)出問(wèn)題因?yàn)椴糠址?wù)端認(rèn)定關(guān)鍵幀間隔太大會(huì)主動(dòng)斷連。第三是 B 幀問(wèn)題。RTMP/FLV 容器本身通過(guò) CompositionTime 字段是支持 B 幀的但很多低延遲播放器收到帶 B 幀的流要等重排延遲直接上去。-x265-params bframes0這個(gè)參數(shù)實(shí)測(cè)對(duì)延遲幫助非常明顯而且犧牲的畫(huà)質(zhì)微乎其微。5.3 攝像頭或采集卡輸入如果你是做攝像頭接入輸入源就不是 mp4 文件而是 v4l2 設(shè)備。命令形態(tài)類(lè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)證推流命令起來(lái)了畫(huà)面能不能播取決于接收端是不是認(rèn)這套格式。如果服務(wù)端不支持 codec id 12推流可能表現(xiàn)為連接建立后沒(méi)有報(bào)錯(cuò)但服務(wù)器端日志能看到 FLV tag 解析異?；蛘吒纱嘣谖帐趾笾鲃?dòng)斷開(kāi)。所以在正式環(huán)境上線前一定要先用一個(gè)支持 H.265 RTMP 的接收端做一次端到端驗(yàn)證。驗(yàn)證時(shí)最干凈的做法是先用支持 H.265 RTMP 的服務(wù)端收流再用自研播放器或打過(guò)對(duì)應(yīng)補(bǔ)丁的拉流播放鏈路看圖像。不要用通用桌面播放器去驗(yàn) H.265 RTMP大概率黑屏這會(huì)讓你誤以為是自己推流推錯(cuò)了。我個(gè)人的排查順序是先看推流端是否持續(xù)打印編碼日志再看服務(wù)端是否持續(xù)收到數(shù)據(jù)最后才懷疑播放端和解碼格式。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄6.1 問(wèn)題速查表現(xiàn)象可能原因解決辦法configure 報(bào)ERROR: libx265 not foundlibx265-dev 沒(méi)裝好或 pkg-config 路徑不對(duì)重裝 libx265-dev檢查/usr/lib/pkgconfig下有沒(méi)有 x265.pcmake 后運(yùn)行 ffmpeg 報(bào)cannot open shared object fileldconfig 緩存里沒(méi)有 /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ù)組沒(méi)加 HEVC 映射檢查補(bǔ)丁第二處是否生效推流能建立但播放端黑屏sequence header 沒(méi)發(fā)對(duì)或播放端不認(rèn) codec id 12檢查 HEVC 分支是否寫(xiě)入 extradata換一個(gè)支持 H.265 RTMP 的播放端驗(yàn)證出現(xiàn)Non-monotonous DTS警告時(shí)間戳不連續(xù)常見(jiàn)于沒(méi)加-re或 B 幀引發(fā)推流加-re直播參數(shù)里加bframes0服務(wù)器連上就斷服務(wù)端不認(rèn) H.265 RTMP 擴(kuò)展換支持該約定的服務(wù)器或用 H.264 降級(jí)測(cè)試CPU 占用接近滿載preset 太慢、分辨率太高、碼率控制沒(méi)做好換-preset veryfast限制分辨率用-b:v限碼率6.2 最隱蔽的坑補(bǔ)丁沒(méi)生效但編譯也不報(bào)錯(cuò)這可能是最坑的一點(diǎn)。有些情況下你改了flv.h和flvenc.c但實(shí)際編譯的時(shí)候用的還是舊的目標(biāo)文件FFmpeg 的增量編譯偶爾會(huì)騙人。最穩(wěn)的做法是改完源碼后先make clean再重新 configure 和 make或者干脆刪掉整個(gè)源碼目錄重新解壓、重新打補(bǔ)丁。我踩過(guò)一次這個(gè)坑花了大半個(gè)晚上排查最后發(fā)現(xiàn)是增量編譯用了舊的 flv 封裝器對(duì)象文件。另外如果你的編譯過(guò)程有多個(gè)工作目錄或者用了別的構(gòu)建腳本務(wù)必確認(rèn)ffmpeg -buildconf里顯示的就是你當(dāng)前源碼目錄這次 configure 的結(jié)果。用strings去 grep 二進(jìn)制里有沒(méi)有 HEVC 相關(guān)字符串也是個(gè)快速檢查法但最直接還是看自己的補(bǔ)丁步驟有沒(méi)有真正執(zhí)行。6.3 推流端正常但服務(wù)端拒收這種情況多半不是編譯問(wèn)題而是兩邊的格式約定不一致?，F(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í)測(cè)中我最常遇到的就是 x265 在某些參數(shù)下輸出的 extradata 結(jié)構(gòu)和服務(wù)端解析器不兼容。遇到這種情況先用最簡(jiǎn)單的參數(shù)組合測(cè)試-profile:v main、-pix_fmt yuv420p、bframes0把變量降到最少。H.265 RTMP 這條鏈路本身就處在“事實(shí)標(biāo)準(zhǔn)”的地帶參數(shù)越花哨踩到兼容性問(wèn)題的概率越大。等基礎(chǔ)鏈路通了再慢慢往上加編碼質(zhì)量參數(shù)。6.4 低配機(jī)器編譯時(shí)的內(nèi)存問(wèn)題如果你是在云服務(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)頁(yè)播放器只支持 8-bit 解碼10-bit 推流會(huì)導(dǎo)致花屏或者完全沒(méi)有圖像。我的建議是RTMP H.265 場(chǎng)景老老實(shí)實(shí)用 8-bit Main Profile10-bit 留給文件存儲(chǔ)和高畫(huà)質(zhì)點(diǎn)播場(chǎng)景。7. 個(gè)人實(shí)操心得與后續(xù)擴(kuò)展思路編譯這份 FFmpeg 的前前后后我最大的體會(huì)是工作量其實(shí)不在編譯本身而在理解封裝器那三層邏輯——codec tag 表、sequence header、NAL 格式轉(zhuǎn)換。一旦你把這三件事想透了以后無(wú)論是換 FFmpeg 版本、加新的編碼格式還是排查兼容性問(wèn)題思路都會(huì)清晰很多。很多人卡在“編譯失敗了”這一步其實(shí)回去看看 configure 的輸出百分之八十的問(wèn)題都在依賴庫(kù)沒(méi)裝全。補(bǔ)丁管理上我的建議是不要直接在源碼目錄里用 sed 或手改完就扔而是把修改整理成一個(gè)獨(dú)立的 diff 文件下次解壓新源碼后一條命令打上去。這樣既方便版本升級(jí)時(shí)復(fù)用也方便團(tuán)隊(duì)協(xié)作時(shí)讓別人 review 你到底改了哪里。我的習(xí)慣是命名成h265_rtmp.patch和源碼放在同一個(gè)目錄管理。如果未來(lái)不想維護(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í)先做兼容性測(cè)試。這個(gè)方案后續(xù)還可以做一些很實(shí)用的擴(kuò)展。比如把這套FFmpeg 集成進(jìn)推流腳本配合 shell 或服務(wù)端程序做多路攝像頭輪詢推流比如在推流的同時(shí)用-f flv落一份本地備份方便事后回看再比如把目標(biāo)碼率、GOP、分辨率做成配置文件按場(chǎng)景動(dòng)態(tài)切換參數(shù)。H.265 over RTMP 這個(gè)鏈路目前看還會(huì)在生產(chǎn)環(huán)境存在很長(zhǎng)一段時(shí)間自己掌握編譯能力比每次都去網(wǎng)上找一個(gè)別人編譯好的二進(jìn)制要靠譜得多。