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