做音視頻相關(guān)的工作被問得最多的一類問題就是我只是想把 MP4 換個容器、把音軌重新挑一條、把文件切成分片去做點(diǎn)播為什么一動手就是十幾分鐘的轉(zhuǎn)碼畫質(zhì)還肉眼可見掉了一檔答案往往很簡單——絕大多數(shù)人把“封裝”和“轉(zhuǎn)碼”當(dāng)成了同一件事。FFmpeg 這套多媒體處理框架里視音頻流封裝是獨(dú)立于編碼之外的一層能力它只負(fù)責(zé)把已經(jīng)壓縮好的碼流按某種容器規(guī)則重新組織不碰像素、不碰采樣點(diǎn)。用對了一個幾 GB 的文件換容器通常只需要幾十秒CPU 占用低到可以忽略用錯了就是白白燒電還掉畫質(zhì)。這篇內(nèi)容面向的讀者范圍比較寬剛接觸 FFmpeg、只會復(fù)制粘貼命令的同學(xué)可以從容器與編碼的區(qū)別、-c copy的語義開始跟已經(jīng)能跑通基礎(chǔ)命令、但在多軌道、時間戳、HLS 切片上反復(fù)踩坑的朋友可以直接跳到參數(shù)計(jì)算和問題排查那幾節(jié)。我會把封裝這條鏈路上的關(guān)鍵概念、命令寫法、參數(shù)背后的算術(shù)、以及用 libavformat 寫封裝器時的骨架代碼全部拆開講中間穿插一些常規(guī)文檔里不會寫的教訓(xùn)。所有結(jié)論都來自命令行和代碼兩條路徑上的反復(fù)實(shí)測涉及具體數(shù)值的地方我會把計(jì)算過程擺出來方便你按自己的場景替換。1. 先把封裝這件事講透容器、編碼、封裝到底誰管誰1.1 容器格式與編碼格式的分工邊界很多人對 FFmpeg 的第一層誤解是以為.mp4、.mkv、.ts這些后綴代表“視頻格式”。準(zhǔn)確說法是容器格式container format在 FFmpeg 里對應(yīng) muxer/demuxer它管的是“怎么把若干條碼流、時間戳、元數(shù)據(jù)、索引表組織進(jìn)一個文件”真正決定畫面和聲音怎么壓縮的是編碼格式codec比如視頻側(cè)的 H.264、H.265、AV1音頻側(cè)的 AAC、Opus、MP3。打個裝箱的比方編碼相當(dāng)于把貨物真空壓縮、抽掉空氣決定體積能壓到多小容器相當(dāng)于集裝箱的規(guī)格和裝箱清單決定這批貨怎么碼放、清單寫在箱門內(nèi)側(cè)還是箱底、中途能不能開箱取某一件。同一批壓縮好的貨可以裝進(jìn)標(biāo)準(zhǔn)箱MP4也可以裝進(jìn)散貨船MKV貨本身一點(diǎn)沒變。這就是-c copy的物理含義解復(fù)用demux→ 復(fù)用mux中間沒有解碼器也沒有編碼器參與。理解了這個分層很多困惑會自動消失。比如“為什么 MKV 轉(zhuǎn) MP4 之后文件小了”——大概率不是畫質(zhì)變了而是 MKV 里塞了封面圖、章節(jié)信息、多條字幕軌MP4 裝不下或者被默認(rèn)丟棄了“為什么 FLV 里放不了 H.265”——不是 FFmpeg 不行是 FLV 這個容器的規(guī)范里就沒給 H.265 留位置。容器對編碼是有兼容性白名單的這是硬約束命令寫得再花也繞不過去。我把日常會碰到的幾種容器做個橫向?qū)φ者@張表建議存下來選容器的時候直接查容器典型編碼支持索引/元數(shù)據(jù)特點(diǎn)適合場景主要限制MP4H.264/H.265/AV1 AAC/MP3moov 索引可前置支持 faststart點(diǎn)播、移動端、Web對部分編碼和字幕格式挑剔中斷錄制易損壞MKV幾乎不挑H.265/AV1/Opus/FLAC/ASS 全收EBML 結(jié)構(gòu)章節(jié)、多字幕友好本地歸檔、多軌素材瀏覽器原生支持差部分播放器兼容一般TSH.264/H.265 AAC/MP3/AC-3定長 188 字節(jié)包自帶 PAT/PMT直播、HLS 分片、錄制流體積開銷大無全局索引拖動定位差FLVH.264 AAC/MP3標(biāo)簽式結(jié)構(gòu)頭部極簡低延遲直播推流編碼白名單窄H.265 基本無緣MOV與 MP4 同源擴(kuò)展更多支持時間碼軌、ProRes后期剪輯中間格式通用播放器兼容性不如 MP4WebMVP8/VP9/AV1 Vorbis/Opus基于 MKV 的子集Web 端免插件播放編碼組合受限轉(zhuǎn)封裝前要確認(rèn)編碼表格里最值得強(qiáng)調(diào)的一行是 TS。它的 188 字節(jié)定長包設(shè)計(jì)是為了抗丟包和隨機(jī)接入代價就是包頭開銷。一個 188 字節(jié)的包里固定有 4 字節(jié)包頭再加上周期性插入的 PAT/PMT 表實(shí)際有效載荷比例通常在 92% 到 95% 之間。這就是為什么同一個片源從 MP4 轉(zhuǎn)到 TS文件會莫名其妙大出 5% 到 8%這不是編碼器變差了是集裝箱的隔板變厚了。1.2 一次封裝的完整鏈路與時間戳的核心地位把封裝鏈路畫清楚后面所有的坑都能對號入座。以命令行ffmpeg -i in.mp4 -c copy out.mkv為例內(nèi)部大致走這么幾步打開輸入 → 讀取容器頭解析出若干條 stream每條 stream 帶一份AVCodecParameters編碼類型、分辨率、采樣率、extradata 等→ 循環(huán)av_read_frame拿到一個個 packetpacket 上掛著pts、dts、duration、stream_index→ 把 packet 交給輸出側(cè)的 muxer按輸出容器的時間基重新?lián)Q算時間戳 →av_interleaved_write_frame寫盤 → 結(jié)束時av_write_trailer回填索引。這條鏈路里唯一容易出問題的就是時間戳換算。容器換一種時間基time_base往往跟著換。MP4 的視頻軌常見時間基是 1/15360 或 1/90000TS 是 1/90000MKV 干脆用毫秒即 1/1000。換算公式很樸素目標(biāo)時間戳 源時間戳 × 源 time_base / 目標(biāo) time_base但樸素公式架不住源文件的坑。真實(shí)素材里經(jīng)常遇到start_time不為 0 的情況尤其從直播錄制下來的 TS、手機(jī)拍攝的 MOV、以及被剪輯軟件二次導(dǎo)出過的文件。如果源視頻軌從 1.4 秒開始、音頻軌從 0 秒開始直接流拷貝封進(jìn) MP4播放器按各自的第一幀對齊觀感就是聲音早了一秒多。這類問題不會報錯只會讓你的用戶覺得“這視頻怪怪的”排查起來極其費(fèi)神。還有一層是 PTS 與 DTS 的區(qū)別。PTS 是呈現(xiàn)時間DTS 是解碼時間。B 幀存在的時候解碼順序和顯示順序不一致DTS 會小于 PTS。流拷貝時這兩個值原樣搬運(yùn)但不同容器對“DTS 必須單調(diào)遞增”的嚴(yán)格程度不一樣。MP4 和 FLV 的 muxer 相對嚴(yán)格遇到時間戳回退會直接甩出Non-monotonous DTS in output stream的警告繼續(xù)寫下去可能得到一個音畫錯亂的文件。這就是后面排查章節(jié)要重點(diǎn)處理的一類問題。提示判斷一個文件能不能安全地做流拷貝先跑一遍ffprobe看每條流的codec_name、start_time、time_base三個字段。這三個值決定了你后面會不會遇到偏移、抖動和寫入拒絕。2. 環(huán)境與工具準(zhǔn)備別急著敲第一條命令2.1 FFmpeg 構(gòu)建版本的選擇與能力核驗(yàn)FFmpeg 的版本差異比很多人想象的大。同樣一條-c copy命令在 4.x 和 6.x 上行為基本一致但涉及-bsf比特流過濾器、HLS 的默認(rèn)分片行為、以及某些容器的 codec_tag 自動推斷時差別就出來了。我踩過最典型的一次是 AAC 從 TS 轉(zhuǎn) MP4 時老版本必須顯式加-bsf:a aac_adtstoasc才能把 ADTS 頭剝掉新版本 muxer 會自動處理如果你習(xí)慣性加上反而在某些輸入下報沖突。第一步永遠(yuǎn)是核驗(yàn)ffmpeg -version ffmpeg -hide_banner -muxers | grep -E mp4|matroska|mpegts|flv ffmpeg -hide_banner -encoders | grep -E libx264|libx265|aac第一條看版本和編譯配置重點(diǎn)確認(rèn)有沒有--enable-libx264、--enable-libx265、--enable-gpl這類標(biāo)記——如果后面某天你需要臨時轉(zhuǎn)一段碼缺了這些庫就只能用內(nèi)置的mpeg4編碼器畫質(zhì)會讓你懷疑人生。第二條確認(rèn) muxer 存在正常發(fā)行版都會全量編進(jìn)去但自己裁過的定制構(gòu)建有可能砍掉mpegts。第三條看編碼器雖然封裝本身不需要編碼器但排查問題時經(jīng)常要順手轉(zhuǎn)一下碼做對照實(shí)驗(yàn)。有個細(xì)節(jié)值得說ffmpeg -formats的輸出里D表示支持解復(fù)用E表示支持復(fù)用DE才是雙向都行。某些容器只讀不寫比如一些冷門的專業(yè)格式寫的時候會直接告訴你 “Requested output format is not a suitable output format”。提前確認(rèn)能省下十分鐘的困惑。至于用哪個版本我的建議是跟隨主流發(fā)行版或官方靜態(tài)構(gòu)建的次新版本不必追最新也別用五六年前的老古董。新版本對時間戳異常的容忍策略更成熟很多過去要手動加-fflags genpts的場景現(xiàn)在自動就處理了。2.2 封裝前必做的媒體信息體檢封裝是一個“搬運(yùn)”動作搬之前得先知道箱子里有什么。ffprobe就是那個開箱檢查的工具我習(xí)慣用 JSON 輸出方便肉眼掃也方便腳本解析ffprobe -v error -show_format -show_streams -of json input.mp4輸出里我會重點(diǎn)盯這幾項(xiàng)format.start_time和format.duration整體起點(diǎn)和時長起點(diǎn)不為 0 就要警覺。每條 stream 的codec_name、codec_type確認(rèn)視頻到底是 h264 還是 hevc音頻是 aac 還是 ac3。width、height、pix_fmt像素格式如果是yuv444p或yuv422p某些硬解播放器和移動端會有兼容問題雖然封裝不改它但你得知道這是隱患。r_frame_rate與avg_frame_rate兩者不一致說明是可變幀率VFRVFR 素材封裝后容易出現(xiàn)時間戳抖動。sample_rate、channels、channel_layout音頻參數(shù)涉及后面能不能直接塞進(jìn)目標(biāo)容器。bit_rate碼率用來估體積。nb_frames和TAG:...幀數(shù)與元數(shù)據(jù)標(biāo)簽順手看看有沒有封面、語言標(biāo)記。一趟體檢做完能不能流拷貝基本就有答案了。判斷邏輯很簡單目標(biāo)容器的編碼白名單里是否包含源文件的每條流的編碼。都包含放心-c copy有一條不包含就必須對那條流單獨(dú)轉(zhuǎn)碼其他流依然可以拷貝這就是常說的“混合模式”。舉個真實(shí)場景。某監(jiān)控項(xiàng)目導(dǎo)出的錄像里有三條流H.264 視頻、PCM 音頻、以及一條私有的數(shù)據(jù)流。想封進(jìn) MP4 給業(yè)務(wù)系統(tǒng)播放PCM 在 MP4 里兼容性差那條數(shù)據(jù)流 MP4 根本不認(rèn)。正確做法是視頻流拷貝、音頻流轉(zhuǎn) AAC、數(shù)據(jù)流丟棄ffmpeg -i camera.mp4 \ -map 0:v:0 -map 0:a:0 \ -c:v copy -c:a aac -b:a 128k \ -movflags faststart \ output.mp4注意-map里我明確寫了0:v:0和0:a:0沒有用默認(rèn)的自動選擇。自動選擇在多軌道文件上經(jīng)常選錯尤其是帶封面圖的音頻文件FFmpeg 可能把封面當(dāng)成視頻流選走。這個習(xí)慣建議從一開始就養(yǎng)成只要文件里軌道數(shù)大于 2就手動 map。注意-map 0表示全選配合-map -0:d可以排除數(shù)據(jù)流。但更穩(wěn)妥的寫法是正向列舉你要的軌道而不是全選再減因?yàn)椤叭x”在新版本里會連帶把一些隱藏的元數(shù)據(jù)軌也拉進(jìn)來。3. 命令行封裝實(shí)戰(zhàn)從零拷貝到參數(shù)精調(diào)3.1 最核心的一條命令流拷貝換容器所有封裝命令的母版就是這一條ffmpeg -i input.mp4 -c copy output.mkv-c copy等價于-c:v copy -c:a copy -c:s copy即所有流都不重新編碼。執(zhí)行速度取決于磁盤讀寫一個 2 GB 的文件在普通 SSD 上通常十秒內(nèi)完成CPU 占用常年低于 5%。這個命令我一年要用上千次。但母版不能無腦套。有幾個補(bǔ)充參數(shù)屬于“默認(rèn)就該帶上”的級別ffmpeg -hide_banner -y -i input.mp4 \ -map 0 -c copy \ -avoid_negative_ts make_zero \ output.mkv-hide_banner只是讓輸出干凈點(diǎn)不參與邏輯。-y覆蓋輸出腳本里必帶交互式使用時看情況。-avoid_negative_ts make_zero是關(guān)鍵補(bǔ)丁當(dāng)源文件存在負(fù)時間戳B 幀導(dǎo)致的常見現(xiàn)象muxer 在寫入時可能拒絕或者產(chǎn)生偏移這個參數(shù)讓 FFmpeg 統(tǒng)一把時間軸平移到 0 起點(diǎn)。加不加的實(shí)際差別在一個有 40 毫秒負(fù) DTS 的素材上非常明顯——不加的話某些播放器開頭會有輕微卡頓或者首幀黑屏。還有一個我強(qiáng)烈建議在批量腳本里加上的-max_muxing_queue_size 4096默認(rèn)隊(duì)列在某些碼率極高、關(guān)鍵幀極稀疏的素材上會不夠用報Too many packets buffered for output stream。默認(rèn)值 128 對普通點(diǎn)播夠用對 4K 高碼率或者帶 B 幀的 HEVC 就有點(diǎn)緊。調(diào)到 4096 內(nèi)存代價可以忽略能直接消滅一類偶發(fā)報錯。3.2 軌道映射與多音軌、字幕的取舍多軌道文件是封裝環(huán)節(jié)最容易翻車的地方因?yàn)?FFmpeg 的默認(rèn)軌道選擇邏輯對普通用戶來說不夠直觀視頻選分辨率最高的音頻選聲道數(shù)最多的字幕選第一個匹配的。這個策略在大部分情況下合理但在素材文件上經(jīng)常不是你想要的那條。顯式映射的完整語法是-map 輸入序號:流類型:流索引索引從 0 開始。幾個常用寫法# 只保留第一條視頻和第二條音頻 ffmpeg -i in.mkv -map 0:v:0 -map 0:a:1 -c copy out.mp4 # 全部保留但給音頻打上語言標(biāo)記 ffmpeg -i in.mkv -map 0 \ -c copy \ -metadata:s:a:0 languagechi \ -metadata:s:a:1 languageeng \ -metadata:s:a:0 title國語 \ out.mkv # 字幕單獨(dú)處理MKV 存 ASSMP4 只能用 mov_text ffmpeg -i in.mkv -map 0:v -map 0:a -map 0:s:0 \ -c:v copy -c:a copy -c:s mov_text out.mp4字幕這塊有個硬約束必須記住MP4 只支持mov_text也叫 tx3g這種位圖式之外的簡單文本字幕ASS/SSA 的特效、定位、字體全部會丟失只保留文字和時間軸。如果你需要保留 ASS 的完整樣式容器只能選 MKV。強(qiáng)行把 ASS 塞進(jìn) MP4FFmpeg 會提示不支持的編碼或者你加了-c:s mov_text之后得到一個樣式全無的字幕軌。音頻軌道還有一層是“默認(rèn)軌”標(biāo)記。MP4 和 MKV 都支持disposition用來告訴播放器優(yōu)先播哪條ffmpeg -i in.mkv -map 0 -c copy \ -disposition:a:0 default -disposition:a:1 0 \ out.mp4不加這個多音軌文件在部分播放器上會默認(rèn)選第一條哪怕那是一條導(dǎo)演評論音軌。這個細(xì)節(jié)在交付給終端用戶的場景里非常影響體驗(yàn)值得花三十秒補(bǔ)上。3.3 面向 Web 播放的 MP4 優(yōu)化與 faststartMP4 的索引表叫 moov默認(rèn)寫在文件末尾。這意味著瀏覽器要先下載完整個文件或者發(fā) Range 請求跳到尾部才能拿到索引才能開始播放。對于幾百 MB 的點(diǎn)播文件用戶感知就是“點(diǎn)了播放要轉(zhuǎn)好久”。-movflags faststart做的事情是在寫完之后把 moov 挪到文件頭。注意它是“二次寫”會多一次磁盤 IO所以大文件上耗時會略增但這是值得的ffmpeg -i in.mp4 -map 0 -c copy -movflags faststart web.mp4判斷是否生效有個土辦法用十六進(jìn)制查看器看文件前幾百字節(jié)能搜到moov就在頭部?；蛘吒∈耭fprobe -v trace -i web.mp4 21 | grep -m1 -o type:moov流媒體場景還有另一種選擇分片 MP4fMP4ffmpeg -i in.mp4 -map 0 -c copy \ -movflags frag_keyframeempty_moovdefault_base_moof \ out_frag.mp4這種結(jié)構(gòu)把文件切成一個個 moofmdat 的小單元每個關(guān)鍵幀處可獨(dú)立開始播放天生適合邊下邊播和低延遲場景。代價是兼容性略差一些老播放器和部分編輯軟件對它支持不好。我的經(jīng)驗(yàn)是給 Web 點(diǎn)播用 faststart 的普通 MP4給直播錄制或者需要快速起播的場景用 fMP4別混著用。提示faststart和frag_keyframe不要同時加。兩個 flag 的作用對象沖突同時寫的行為在不同版本上不一致容易得到一個索引位置詭異的文件。3.4 HLS 切片封裝與 TS 流轉(zhuǎn)封裝的細(xì)節(jié)HLS 本質(zhì)上是“把一條流切成若干個小 TS 分片再配一個 m3u8 播放列表”。流拷貝做切片是最省資源的方案ffmpeg -i input.mp4 -map 0 -c copy \ -f hls \ -hls_time 6 \ -hls_list_size 0 \ -hls_playlist_type vod \ -hls_segment_filename seg_%04d.ts \ index.m3u8幾個參數(shù)的含義和取舍-hls_time 6目標(biāo)分片時長單位秒。注意是“目標(biāo)”不是“精確”因?yàn)榍衅荒茉陉P(guān)鍵幀處切。如果源視頻的 GOP 是 4 秒你寫 6 會得到實(shí)際 8 秒左右的分片寫 2 會得到 4 秒。要精確控制得先轉(zhuǎn)碼時把 GOP 設(shè)成和分片時長一致。-hls_list_size 0播放列表保留全部分片。直播場景通常設(shè)成 5 到 10只保留最近幾個。-hls_playlist_type vod告訴播放器這是點(diǎn)播會寫#EXT-X-ENDLIST結(jié)束標(biāo)記。不寫的話部分播放器會一直等新分片。-hls_segment_filename分片命名模板%04d是四位補(bǔ)零序號。從 TS 轉(zhuǎn)回 MP4 是另一個高頻需求比如把 HLS 的分片合并回單文件ffmpeg -i index.m3u8 -map 0 -c copy -bsf:a aac_adtstoasc merged.mp4或者直接對單個 TS 操作ffmpeg -i segment.ts -map 0 -c copy \ -fflags genpts \ -avoid_negative_ts make_zero \ merged.mp4-fflags genpts在 TS 轉(zhuǎn) MP4 時幾乎是我的標(biāo)配。TS 的時間戳經(jīng)常從幾萬、幾十萬開始PCR 基準(zhǔn)不做重生成封進(jìn) MP4 后可能出現(xiàn)巨大的起始偏移播放器要么從中間開始播要么時長顯示成天文數(shù)字。genpts讓 FFmpeg 根據(jù)幀率和時長重新生成一套從 0 開始的 PTS代價是它依賴解碼順序推斷極少數(shù) B 幀結(jié)構(gòu)復(fù)雜的素材可能推斷得不夠準(zhǔn)那就得加-vsync 0關(guān)掉幀同步干預(yù)讓它老老實(shí)實(shí)按原時間戳搬。這里有個反直覺的點(diǎn)值得展開很多人以為-c copy就完全不涉及解碼實(shí)際上genpts會觸發(fā) packet 層面的時間戳分析雖然不解碼像素但也不是純粹的字節(jié)搬運(yùn)。如果你的目標(biāo)是極限速度就不要加genpts改用-copyts -start_at_zero的組合前者保留原始時間戳后者把起點(diǎn)平移到 0。4. 參數(shù)背后的計(jì)算碼率、時間基與封裝開銷4.1 文件體積的估算與碼率預(yù)算封裝不改碼流所以輸出文件的體積基本等于所有流的數(shù)據(jù)量之和加上容器開銷。估算公式文件大小(Byte) ≈ (視頻碼率 音頻碼率 其他流碼率) × 時長(秒) ÷ 8 × (1 開銷系數(shù))開銷系數(shù)按容器取MP4 大約 0.5% 到 1%MKV 1% 左右章節(jié)、附件多的話更高TS 5% 到 8%FLV 1% 到 2%。舉個具體例子。一段 45 分鐘的課程視頻視頻碼率 2.5 Mbps音頻 AAC 128 kbps目標(biāo)容器 MP4總碼率 2500 128 2628 kbps 時長 45 × 60 2700 秒 數(shù)據(jù)量 2628 × 2700 ÷ 8 887,175 KB ≈ 866 MB 加 1% 開銷 ≈ 875 MB這個估算在實(shí)測里誤差通常在 2% 以內(nèi)足夠用來做存儲規(guī)劃。反過來用也很有價值如果業(yè)務(wù)要求單個文件不超過 500 MB時長固定 45 分鐘那總碼率上限就是500 MB 500 × 1024 × 8 4,096,000 kbit 4,096,000 ÷ 2700 ≈ 1517 kbps 音頻占 128視頻可用約 1389 kbps這就是碼率預(yù)算的基本算法。注意這個式子只對恒定碼率CBR或接近 CBR 的素材準(zhǔn)確VBR 素材的實(shí)際體積跟畫面復(fù)雜度強(qiáng)相關(guān)估算偏差能到 20% 以上。要精確只能先轉(zhuǎn)一小段采樣測。封裝環(huán)節(jié)本身還有一個容易被忽略的體積因素元數(shù)據(jù)與附件。MKV 里如果帶了字體附件、封面圖、多個章節(jié)體積可能憑空多出幾十 MB。做批量轉(zhuǎn)換時如果不需要這些用-map_chapters -1去掉章節(jié)、-vn之外的-map -0:t排除附件能省下不少空間。4.2 時間基換算與 PTS/DTS 的實(shí)際影響時間基time_base是一個分?jǐn)?shù)表示“一個時間戳單位代表多少秒”。1/90000 意味著時間戳每加 1時間前進(jìn) 1/90000 秒精度約 11 微秒。MKV 的 1/1000 精度是 1 毫秒對 60 幀視頻每幀 16.67 毫秒夠用但對高幀率素材就有點(diǎn)粗糙。換算的實(shí)操價值在于當(dāng)你手寫代碼封裝或者用setpts、-itsoffset做時間軸微調(diào)時腦子里必須有這個換算。舉個真實(shí)例子某次需要把一條音頻整體延后 250 毫秒對齊畫面音頻流時間基是 1/48000那么偏移量就是250 毫秒 0.25 秒 0.25 × 48000 12000 個時間戳單位對應(yīng)命令是-itsoffset 0.25這個參數(shù)吃的是秒FFmpeg 內(nèi)部自己換算但如果是代碼里直接改 packet 的 pts/dts就得自己乘。算錯一個數(shù)量級結(jié)果就是聲音跑到幾分鐘之后或者干脆被 muxer 拒絕。還有一個高頻誤區(qū)以為-r能改幀率。在流拷貝模式下-r是無效的幀率信息寫在碼流和容器頭里不改編碼就改不了。你看到的“改了幀率”其實(shí)是 muxer 在寫頭信息時覆蓋了字段播放器按新幀率解釋舊數(shù)據(jù)結(jié)果是播放速度整體變快或變慢音畫直接錯位。要真正改幀率必須重新編碼。DTS 單調(diào)性是另一個必須在腦子里過的檢查項(xiàng)。B 幀的存在使得 DTS 順序和 PTS 順序不同但 DTS 本身必須嚴(yán)格遞增。當(dāng)源文件經(jīng)過剪輯、拼接、或者從多個片段合并而來時DTS 很容易出現(xiàn)回退。表現(xiàn)是 muxer 刷警告或者輸出文件在某些播放器上花屏、跳幀。處理手段按順序試-fflags genpts重新生成時間戳。-vsync 0或新版寫法-fps_mode passthrough禁止幀率同步干預(yù)。-avoid_negative_ts make_zero處理負(fù)值。實(shí)在不行對視頻流重新編碼一次用-x264-params bframes0關(guān)掉 B 幀從根上消滅 DTS 回退。4.3 關(guān)鍵幀間隔與封裝后的可拖動性流拷貝不會改變關(guān)鍵幀I 幀的分布這一點(diǎn)必須清楚。源文件的關(guān)鍵幀間隔是 10 秒封出來的文件拖動精度就是 10 秒——用戶拖進(jìn)度條畫面會跳到最近的關(guān)鍵幀。這個特性在 HLS 場景下影響被放大。播放器切換碼率、跳轉(zhuǎn)分片都依賴關(guān)鍵幀對齊。如果源素材的 GOP 忽長忽短VFR 錄制常見切片出來的分片時長會非常不均勻某些分片可能長達(dá)十幾秒起播延遲明顯。解決辦法只有一個轉(zhuǎn)碼時固定 GOP。常用參數(shù)ffmpeg -i in.mp4 -c:v libx264 -preset medium -crf 20 \ -g 120 -keyint_min 120 -sc_threshold 0 \ -c:a copy out.mp4-g 120在 30 幀下等于 4 秒一個關(guān)鍵幀。-keyint_min設(shè)成和-g相同禁止場景切換時插入額外關(guān)鍵幀-sc_threshold 0關(guān)掉場景切換檢測。這三個參數(shù)配合才能得到嚴(yán)格等距的 I 幀切片時長才會均勻。只寫-g是不夠的場景切換依然會插 I 幀這是很多人切片不均勻的真正原因。5. 用代碼調(diào) libavformat 完成封裝5.1 封裝器的最小骨架與關(guān)鍵調(diào)用順序命令行覆蓋不了所有場景。當(dāng)封裝要嵌進(jìn)服務(wù)端流水線、要在封裝過程中做自定義的包過濾、或者要把多個源拼成一條輸出時就得直接調(diào) libavformat。最小可用的流程是固定的順序錯了會得到各種奇怪的錯誤碼avformat_open_input打開輸入avformat_find_stream_info填充流信息。avformat_alloc_output_context2按輸出文件名或顯式指定的 muxer 名創(chuàng)建輸出上下文。遍歷輸入流對每條要保留的流avformat_new_stream建輸出流然后avcodec_parameters_copy拷貝編碼參數(shù)務(wù)必把out_stream-codecpar-codec_tag置 0。設(shè)置out_stream-time_base一般直接沿用輸入流的 time_base。avio_open打開輸出 IOavformat_write_header寫容器頭。循環(huán)av_read_frame→av_packet_rescale_ts→av_interleaved_write_frame。av_write_trailer收尾avio_closep、avformat_free_context釋放。第 3 步那個codec_tag 0是我見過最多人栽跟頭的地方。avcodec_parameters_copy會把源容器的 codec_tag 一起拷過來比如從 MP4 拷到 MKV 時帶著avc1這個 tagMKV 的 muxer 不認(rèn)直接返回Could not find tag for codec。置 0 之后讓 muxer 自己按目標(biāo)容器選合適的 tag問題消失。這個細(xì)節(jié)在任何入門教程里都不會寫但不寫就跑不通。核心代碼大致長這樣AVFormatContext *in_fmt NULL, *out_fmt NULL; avformat_open_input(in_fmt, input_path, NULL, NULL); avformat_find_stream_info(in_fmt, NULL); avformat_alloc_output_context2(out_fmt, NULL, NULL, output_path); int *stream_map av_malloc_array(in_fmt-nb_streams, sizeof(int)); for (int i 0; i in_fmt-nb_streams; i) { AVStream *in_st in_fmt-streams[i]; if (in_st-codecpar-codec_type ! AVMEDIA_TYPE_VIDEO in_st-codecpar-codec_type ! AVMEDIA_TYPE_AUDIO) { stream_map[i] -1; continue; } AVStream *out_st avformat_new_stream(out_fmt, NULL); avcodec_parameters_copy(out_st-codecpar, in_st-codecpar); out_st-codecpar-codec_tag 0; out_st-time_base in_st-time_base; stream_map[i] out_st-index; } avio_open(out_fmt-pb, output_path, AVIO_FLAG_WRITE); avformat_write_header(out_fmt, NULL); AVPacket *pkt av_packet_alloc(); while (av_read_frame(in_fmt, pkt) 0) { if (stream_map[pkt-stream_index] 0) { av_packet_unref(pkt); continue; } AVStream *in_st in_fmt-streams[pkt-stream_index]; AVStream *out_st out_fmt-streams[stream_map[pkt-stream_index]]; av_packet_rescale_ts(pkt, in_st-time_base, out_st-time_base); pkt-stream_index out_st-index; av_interleaved_write_frame(out_fmt, pkt); av_packet_unref(pkt); } av_write_trailer(out_fmt);這段代碼能跑通 90% 的換容器需求。剩下 10% 的坑集中在兩處一是avformat_write_header之前必須確保所有輸出流的codecpar都已填好某些容器MP4 尤其在寫頭時就要算好整體結(jié)構(gòu)二是av_interleaved_write_frame內(nèi)部會做包的排序和緩沖它接管了 packet 的所有權(quán)調(diào)用后不要再去 unref 或者復(fù)用同一個 packet 的 data。5.2 交錯寫入、緩沖與自定義包處理av_interleaved_write_frame和av_write_frame的區(qū)別值得單獨(dú)說。前者會按 DTS 對多條流做交錯排序保證輸出的音視頻包交替出現(xiàn)播放器讀起來才順暢后者是原樣寫入不做排序需要調(diào)用方自己保證順序。封裝場景一律用前者除非你在做非常底層的特殊實(shí)驗(yàn)。交錯帶來的副作用是緩沖。當(dāng)一條流跑得太快、另一條流落后太多時muxer 會把先到的包攢在內(nèi)存里等另一條流追上來。這個緩沖有上限就是前面提到的max_muxing_queue_size。代碼里對應(yīng)的是out_fmt-max_interleave_delta和內(nèi)部的 packet buffer。如果源文件的兩條流時間戳差距極大比如音頻從 0 開始視頻從 300 秒開始緩沖區(qū)會迅速撐爆。這時候的正確做法不是無限加大緩沖而是先用-itsoffset或者手工修正起始時間戳把兩條流的起點(diǎn)拉到同一量級。自定義包處理是代碼路徑相對命令行的最大優(yōu)勢。常見的兩種需求一是按時間窗口裁掉開頭結(jié)尾只搬中間一段二是按 keyframe 切分文件。前者的實(shí)現(xiàn)是在循環(huán)里判斷pkt-pts換算成秒是否落在窗口內(nèi)超出就跳過后者更簡單遇到pkt-flags AV_PKT_FLAG_KEY且是視頻流時關(guān)閉當(dāng)前輸出、開一個新的。這兩種模式在服務(wù)端做切片、做點(diǎn)播轉(zhuǎn)碼的前置處理時非常常用用命令行雖然也能做但控制粒度遠(yuǎn)不如代碼。注意流拷貝模式下不要試圖修改pkt-data的內(nèi)容。包里的數(shù)據(jù)是編碼后的碼流你改了任何一個字節(jié)解碼器就會花屏或者直接報錯。要改內(nèi)容必須先解碼。6. 常見問題與排查實(shí)錄6.1 典型報錯與異常現(xiàn)象速查表封裝環(huán)節(jié)的報錯大多有固定套路我把這些年高頻遇到的整理成一張表遇到問題先對號入座能省掉大量試錯時間報錯或現(xiàn)象根因處理方式Non-monotonous DTS in output stream源文件 DTS 回退多見于剪輯拼接產(chǎn)物加-fflags genpts仍報錯則-vsync 0再不行關(guān) B 幀重編Could not find tag for codec ... in stream #0codec_tag 與目標(biāo)容器不匹配命令行換容器重試代碼里codecpar-codec_tag 0moov atom not foundMP4 錄制中斷索引未寫入用-err_detect ignore_err嘗試讀取能讀出流就用流拷貝搶救輸出文件 0 字節(jié)或無法播放編碼不被目標(biāo)容器支持寫頭即失敗先ffprobe核對編碼必要時單獨(dú)轉(zhuǎn)碼那條流音畫不同步整體偏移固定值兩條流start_time不一致-avoid_negative_ts make_zero或按差值加-itsoffset播放器顯示時長異常幾萬小時/負(fù)數(shù)TS 的 PCR 基準(zhǔn)時間戳未歸一化-fflags genpts或-copyts -start_at_zeroToo many packets buffered for output stream交錯緩沖不足-max_muxing_queue_size 4096HLS 分片時長忽長忽短源 GOP 不均勻轉(zhuǎn)碼時固定-g、-keyint_min、-sc_threshold 0MP4 拖動進(jìn)度條卡頓、起播慢moov 在文件尾部-movflags faststart封裝后字幕消失MP4 不支持 ASS/SSA轉(zhuǎn)mov_text或改用 MKV 容器音頻有雜音、播放器報解碼錯誤TS 的 AAC 帶 ADTS 頭被塞進(jìn) MP4-bsf:a aac_adtstoasc內(nèi)存占用隨文件增大持續(xù)上漲未及時 unref packet或交錯緩沖堆積檢查循環(huán)里的av_packet_unref限制隊(duì)列大小這張表里最需要展開的是moov atom not found。這個報錯意味著文件結(jié)構(gòu)已經(jīng)損壞moov 索引根本沒寫進(jìn)去常見于錄制軟件異常退出、斷電、或者網(wǎng)絡(luò)流中斷。搶救思路是讓 FFmpeg 忽略錯誤繼續(xù)解析把能讀出來的碼流用流拷貝搬到一個新容器里ffmpeg -err_detect ignore_err -i broken.mp4 -map 0 -c copy repaired.mkv成功率跟損壞程度強(qiáng)相關(guān)。如果文件頭就爛了基本沒救如果只是尾部索引缺失通常能救回絕大部分?jǐn)?shù)據(jù)。我處理過的一個案例是一個 8 GB 的錄制文件救回來 7.6 GB丟掉的是最后幾秒。這類操作一定要輸出到新文件別覆蓋原件。6.2 音畫不同步的分層定位方法音畫不同步是封裝里最讓人頭疼的問題因?yàn)樗粓箦e只能靠耳朵和眼睛發(fā)現(xiàn)。我的定位方法是分三層查從外到內(nèi)第一層看封裝前后各條流的 start_time。用ffprobe對比輸入和輸出。如果輸入視頻 start_time 是 0.000、音頻是 1.400輸出變成了兩者都是 0但內(nèi)容偏移還在那就是封裝沒有做歸一化加-avoid_negative_ts make_zero重來。第二層看時長是否匹配。視頻流時長 600.0 秒、音頻 599.2 秒差 0.8 秒屬于正常范圍音頻編碼的幀對齊導(dǎo)致但如果差到幾秒說明有一路流被截斷或者丟包了問題在源文件而不在封裝。第三層看時間基換算是否有精度損失。從高精度時間基1/90000封進(jìn)低精度容器MKV 的 1/1000每幀會做一次四舍五入誤差在微秒級累積幾千幀也就幾毫秒不會造成可感知的偏移。如果偏移達(dá)到幾百毫秒那就不是精度問題而是某一路流的時間戳被錯誤地整體平移了。實(shí)際操作里我還遇到過一個隱蔽情況源文件是多段錄制拼接而成每段之間的時間戳有跳躍。流拷貝會把這些跳躍原樣保留播放時表現(xiàn)為“每隔幾分鐘音畫錯位一次然后自己又對上”。這種素材必須先做時間戳重寫-fflags genpts對這種場景效果有限更可靠的做法是解碼后按幀重新打時間戳再編碼成本高但結(jié)果干凈。ffmpeg -i jumpy.mp4 -map 0 \ -c:v libx264 -crf 18 -g 60 \ -c:a aac -b:a 192k \ -fflags genpts -vsync cfr \ smooth.mp4-vsync cfr新版是-fps_mode cfr強(qiáng)制恒定幀率輸出配合重新編碼能把時間戳徹底理順。這是“放棄速度換正確性”的方案只在源文件確實(shí)有問題時才用。6.3 批量封裝的腳本化與實(shí)測心得單文件操作可以手敲一旦上量就必須腳本化。我維護(hù)的一套批量封裝腳本里有幾條規(guī)則都是從事故里總結(jié)出來的第一條先探測再決定。腳本里對每個文件先跑ffprobe拿 JSON判斷所有流的編碼是否都在目標(biāo)容器的白名單里。全部兼容才走純拷貝有一條不兼容就走混合模式對不兼容的那條單獨(dú)轉(zhuǎn)碼。不做這個判斷批量跑一千個文件中間幾十個失敗你得一個個回頭找。第二條失敗要能定位到具體文件。for循環(huán)里用ffmpeg -v error -y把 stderr 重定向到以文件名命名的日志。不要用-v quiet出了問題什么都看不到。我用的是for f in *.mp4; do base${f%.*} ffmpeg -hide_banner -v error -y -i $f \ -map 0 -c copy -movflags faststart \ -max_muxing_queue_size 4096 \ ${base}_web.mp4 2 ${base}.log if [ $? -ne 0 ]; then echo FAILED: $f failed.txt fi done第三條并發(fā)數(shù)要壓住。封裝是 IO 密集型磁盤跑滿之后并發(fā)再高也沒收益反而會因?yàn)榇蓬^來回尋道拖慢整體。機(jī)械盤上我一般并發(fā) 2 到 4SSD 上可以到 8。用xargs -P控制就行別寫一把梭。第四條輸出目錄和輸入目錄分開而且先寫臨時文件名成功之后再改名。這條規(guī)則救過我一次腳本跑到一半機(jī)器重啟如果直接寫目標(biāo)文件名會留下一堆看起來正常但實(shí)際截斷的文件混在成品里根本發(fā)現(xiàn)不了。寫成.tmp后綴最后統(tǒng)一 rename一眼就能看出哪些沒完成。還有個實(shí)測出來的小結(jié)論分享給大家同一個素材用-c copy從 MP4 轉(zhuǎn) MKV 再轉(zhuǎn)回 MP4往返十次文件大小每次會有幾百字節(jié)的波動但碼流內(nèi)容完全一致用md5sum校驗(yàn)視頻流的數(shù)據(jù)能對上。這說明容器切換是無損的。反過來任何一次不小心漏寫了-c copy轉(zhuǎn)碼就會帶來不可逆的畫質(zhì)損失。所以我在所有腳本的 ffmpeg 調(diào)用里都把-c copy放在命令的最前面就是為了讓它顯眼防止被后面的參數(shù)覆蓋或者遺漏。最后說一個關(guān)于批處理的現(xiàn)實(shí)判斷不是所有封裝都值得做。一個 200 MB 的小文件流拷貝耗時 2 秒轉(zhuǎn)碼耗時 40 秒為了省這 38 秒去做復(fù)雜的兼容性判斷性價比不高直接轉(zhuǎn)碼反而更省心。真正值得上流拷貝的是那些幾百 MB 到幾 GB、CPU 轉(zhuǎn)碼要跑幾分鐘甚至幾十分鐘的大文件以及那些必須保持原始畫質(zhì)的歸檔素材。判斷標(biāo)準(zhǔn)很簡單轉(zhuǎn)碼耗時超過了寫腳本調(diào)試的成本才值得為它做兼容性分支。這個賬我算過很多次每次都能避免過度工程。