Web 影片編解碼器指南

以下影片編解碼器是 Web 上最常用的編解碼器。對於每個編解碼器，還列出了可以支援它們的容器（檔案型別）。每個編解碼器都提供指向下面一個部分的連結，該部分提供了有關編解碼器的其他詳細資訊，包括您可能需要注意的特定功能和相容性問題。

與任何編碼器一樣，有兩個基本因素會影響編碼影片的大小和質量：有關源影片格式和內容的詳細資訊，以及編碼影片時使用的編解碼器的特性和配置。

最簡單的指導原則是：任何使編碼影片看起來更像原始未壓縮影片的內容通常也會使生成的資料更大。因此，它始終是大小與質量之間的權衡。在某些情況下，為了降低資料大小而犧牲更大的質量是值得的；在其他情況下，質量損失是不可接受的，因此有必要接受導致相應更大檔案的編解碼器配置。

源影片格式影響輸出的程度取決於編解碼器及其工作方式。如果編解碼器將媒體轉換為內部畫素格式，或以其他方式使用除簡單畫素之外的方法表示影像，則原始影像的格式沒有任何區別。但是，幀速率和解析度等內容始終會對媒體的輸出大小產生影響。

此外，所有編解碼器都有其優點和缺點。有些編解碼器難以處理特定型別的形狀和圖案，或者不擅長複製銳利邊緣，或者傾向於在黑暗區域丟失細節，或者還有許多其他可能性。這一切都取決於底層的演算法和數學。

這些因素影響最終編碼影片的程度將根據具體情況而有所不同，包括您使用的編碼器及其配置方式。除了通用編解碼器選項外，還可以配置編碼器以降低幀速率、清理噪聲和/或在編碼過程中降低影片的整體解析度。

用於影片編碼的演算法通常會使用一種或多種通用技術來執行編碼。一般來說，任何旨在減小影片輸出大小的配置選項都可能會對影片的整體質量產生負面影響，或者會在影片中引入某些型別的偽像。也可以選擇無損編碼形式，這將導致編碼檔案的大小大大增加，但在解碼時可以完美地再現原始影片。

此外，每個編碼工具在處理源影片的方式上可能會有所不同，從而導致輸出質量和/或大小的差異。

編碼影片時可用的選項以及要分配給這些選項的值，不僅因編解碼器而異，還取決於您使用的編碼軟體。編碼軟體附帶的文件將幫助您瞭解這些選項對編碼影片的具體影響。

偽像是有損編碼過程的副作用，其中丟失或重新排列的資料會導致明顯的負面影響。一旦出現偽像，它可能會持續一段時間，因為影片的顯示方式。影片的每一幀都是透過對當前可見幀應用一組更改來呈現的。這意味著任何錯誤或偽像都會隨著時間的推移而累積，從而導致影像中出現持續一段時間的小故障或其他奇怪或意外的偏差。

為了解決這個問題，並提高對影片資料的查詢時間，會定期將關鍵幀（也稱為幀內幀或I幀）放置到影片檔案中。關鍵幀是完整的幀，用於修復當前可見的任何損壞或偽像殘留。

混疊是用於描述任何從編碼資料重建後看起來與壓縮前不同的內容的通用術語。混疊有很多形式；您可能會看到的常見形式包括

莫爾紋 莫爾紋是一種大尺度的空間干涉圖案，當源影像中的圖案和編碼器的工作方式在空間上略微錯位時產生。編碼器生成的偽像在解碼時會在源影像的圖案中引入奇怪的漩渦效果。
階梯效應 階梯效應是一種空間偽像，當應該平滑的對角直線或曲線邊緣呈現鋸齒狀外觀時發生，看起來有點像一組臺階。這就是“抗鋸齒”濾鏡所減少的效果。
馬車輪效應 馬車輪效應（或頻閃效應）是電影中常見的視覺效果，其中旋轉的輪子似乎以錯誤的速度旋轉，甚至反向旋轉，這是由於幀率和壓縮演算法之間的相互作用。任何重複移動的圖案都可能出現相同的效果，例如鐵軌上的鐵軌、路邊的柱子等等。這是一個時間（基於時間）的混疊問題；旋轉速度會干擾壓縮或編碼期間執行的取樣頻率。

顏色邊緣是一種視覺偽像，表現為在場景中彩色物體邊緣引入的雜色。這些顏色與幀內容之間沒有任何有意的顏色關係。

在影片編碼過程中刪除資料需要丟失一些細節。如果應用了足夠的壓縮，影像的一部分或全部可能會失去清晰度，導致出現略微模糊或朦朧的外觀。

清晰度下降會使影像中的文字難以閱讀，因為文字——尤其是小文字——是注重細節的內容，其中微小的改動會顯著影響可讀性。

有失真壓縮演算法可能會引入振鈴，這是一種效果，其中物體外部的區域被壓縮演算法生成的彩色畫素汙染。當使用跨越物體與其背景之間銳利邊界的塊的演算法時，就會發生這種情況。這在較高的壓縮級別尤其常見。

請注意上面星星邊緣周圍的藍色和粉紅色邊緣（以及階梯和其他明顯的壓縮偽像）。這些邊緣是振鈴效應。振鈴在某些方面類似於蚊式噪聲，但振鈴效應或多或少是穩定且不變的，而蚊式噪聲則閃爍和移動。

振鈴是另一種型別的偽像，它會使閱讀影像中包含的文字變得特別困難。

色帶化發生在壓縮導致漸變顏色細節丟失時。影像不是透過某個區域的各種顏色平滑過渡，而是變得塊狀，顏色塊近似於影像的原始外觀。

請注意上面照片中禿鷹羽毛（以及背景中的雪鴞）的顏色塊狀。由於這些色帶化偽像，羽毛的細節大部分都丟失了。

輪廓或色帶是色帶化的一種特定形式，其中顏色塊在影像中形成帶或條紋。當影片以過粗的量化配置進行編碼時，就會發生這種情況。結果，影片內容呈現出“分層”的外觀，其中顏色到顏色的過渡是突然的，而不是平滑的漸變和過渡，導致出現顏色條紋。

在上圖示例中，請注意天空是如何具有不同深淺的藍色條帶，而不是像天空顏色朝地平線變化那樣保持一致的漸變。這就是輪廓效應。

蚊式噪聲是一種時間偽像，表現為噪聲或邊緣忙碌，表現為閃爍的朦朧或閃爍，大致沿著具有硬邊緣的物體或前景物體與背景之間急劇過渡的外部邊緣出現。這種效果在外觀上可能類似於振鈴。

上圖顯示了多個地方的蚊式噪聲，包括橋周圍的天空。在右上角，一個插圖顯示了影像的一部分特寫，該部分表現出蚊式噪聲。

蚊式噪聲偽像最常見於 MPEG 影片中，但只要使用離散餘弦變換 (DCT) 演算法，就會發生；例如，包括 JPEG 靜止影像。

影片壓縮通常透過比較兩幀並記錄它們之間的差異來工作，一幀接一幀，直到影片結束。當相機固定在適當位置或幀中的物體相對靜止時，此技術效果很好，但如果幀中存在大量運動，則幀之間的差異數量可能非常大，以至於壓縮沒有任何好處。

運動補償是一種技術，它尋找運動（相機或視野中的物體），並確定運動物體在每個方向上移動了多少畫素。然後儲存該位移，以及對無法僅透過該位移描述的已移動畫素的描述。本質上，編碼器找到運動物體，然後構建一個內部幀，該幀看起來像原始幀，但所有物體都平移到它們的新位置。理論上，這近似於新幀的外觀。然後，為了完成工作，找到剩餘的差異，然後將物件偏移集和畫素差異集儲存在表示新幀的資料中。描述偏移和畫素差異的物件稱為殘差幀。

原始幀	幀間差異	運動補償後的差異
檢視者看到的第一個完整幀。	在這裡，僅看到第一幀和下一幀之間的差異。其他所有內容都是黑色。仔細觀察，我們可以看到這些差異的大部分來自水平相機移動，這使得它成為運動補償的良好候選物件。	為了最大程度地減少不同的畫素數量，我們首先透過將第一幀向右移動兩個畫素來考慮相機的平移，然後取差值。這補償了相機的平移，允許兩幀之間有更多重疊。
來自維基百科的影像

運動補償主要有兩種型別：全域性運動補償和塊運動補償。全域性運動補償通常調整相機運動，例如跟蹤、推拉、平移、傾斜、滾動以及上下移動。塊運動補償處理區域性變化，查詢可以使用運動補償編碼的影像的較小部分。這些塊通常具有固定大小，位於網格中，但存在允許可變塊大小甚至允許塊重疊的運動補償形式。

但是，由於運動補償可能會出現偽像。這些偽像出現在塊邊界處，以產生虛假振鈴和其他邊緣效應的銳利邊緣的形式出現。這些是由於殘差幀編碼中涉及的數學運算造成的，並且在被下一個關鍵幀修復之前很容易被注意到。

在某些情況下，減少影片的尺寸以改善影片檔案的最終大小可能很有用。雖然播放的立即尺寸或平滑度損失可能是負面因素，但仔細的決策可以帶來良好的最終結果。如果在編碼之前將 1080p 影片縮小到 720p，則生成的影片可以小得多，同時具有更高的視覺質量；即使在播放過程中按比例放大後，結果也可能比以全尺寸編碼原始影片並接受滿足您的尺寸要求所需的質量損失要好。

類似地，您可以完全從影片中刪除幀，並降低幀率以進行補償。這有兩個好處：它使整個影片更小，並且更小的尺寸允許運動補償為您完成更多工作。例如，由於幀間運動，您可能需要計算兩個相隔兩個畫素的幀的運動差異，但跳過每隔一幀可能會導致計算出四畫素運動的差異。這樣，攝像機的整體運動就可以用更少的殘差幀來表示。

影片在內容不再被人眼感知為運動之前的絕對最低幀率約為每秒 12 幀。低於此幀率，影片就會變成一系列靜止影像。電影膠片通常為每秒 24 幀，而標準清晰度電視約為每秒 30 幀（略少，但足夠接近），高畫質電視則在每秒 24 到 60 幀之間。任何高於 24 FPS 的幀率通常都會被視為令人滿意地流暢；30 或 60 FPS 是理想的目標，具體取決於您的需求。

最終，關於您可以做出哪些犧牲的決定完全取決於您和/或您的設計團隊。

AOMedia 影片 1 (AV1) 編解碼器是一種開放格式，由開放媒體聯盟專門為網際網路影片設計。它實現了比VP9和H.265/HEVC更高的資料壓縮率，並且比AVC高出多達 50% 的壓縮率。AV1 完全免版稅，設計用於<video>元素和WebRTC。

AV1 目前提供三種配置檔案：主要、高階和專業，它們對顏色深度和色度子取樣的支援不斷增強。此外，還指定了一系列級別，每個級別都定義了影片一系列屬性的限制。這些屬性包括幀尺寸、影像區域（以畫素為單位）、顯示和解碼速率、平均和最大位元率以及編碼/解碼過程中使用的圖塊和圖塊列數量的限制。

例如，AV1 2.0 級別提供的最大幀寬度為 2048 畫素，最大高度為 1152 畫素，但其最大幀尺寸（以畫素為單位）為 147,456，因此您實際上無法在 2.0 級別獲得 2048x1152 的影片。不過，值得注意的是，至少對於 Firefox 和 Chrome 而言，在執行軟體解碼時，這些級別實際上會被忽略，解碼器會盡其所能根據提供的設定播放影片。但是，為了將來保持相容性，您應該保持在所選級別的限制範圍內。

目前 AV1 的主要缺點是它非常新，並且支援仍在逐步整合到大多數瀏覽器中。此外，編碼器和解碼器仍在最佳化效能，硬體編碼器和解碼器也大多仍處於開發階段，而不是生產階段。因此，將影片編碼為 AV1 格式需要很長時間，因為所有工作都在軟體中完成。

目前，由於這些因素，AV1 尚未準備好成為您的首選影片編解碼器，但您應該注意它將來是否可以投入使用。

MPEG-4 規範套件的高階影片編碼 (AVC) 標準由相同的 ITU H.264 規範和 MPEG-4 第 10 部分規範指定。它是一種基於運動補償的編解碼器，目前廣泛用於各種媒體，包括廣播電視、RTP 視訊會議以及藍光光碟的影片編解碼器。

AVC 非常靈活，具有許多功能各異的配置檔案；例如，約束基線配置檔案旨在用於視訊會議和移動場景，使用的頻寬低於主配置檔案（在某些地區用於標準清晰度數字電視）或高階配置檔案（用於藍光光碟影片）。大多數配置檔案使用 8 位顏色分量和 4:2:0 色度子取樣；高階 10 配置檔案增加了對 10 位顏色的支援，而高階形式的高階 10 則增加了 4:2:2 和 4:4:4 色度子取樣。

AVC 還具有特殊功能，例如支援同一場景的多個檢視（多檢視影片編碼），這使得能夠製作立體影片等內容。

然而，AVC 是一種專有格式，並且多方擁有其技術的眾多專利。AVC 媒體的商業使用需要許可，儘管 Via LA 專利池不要求對以 AVC 格式流式傳輸的網際網路影片收取許可費，只要該影片對終端使用者免費即可。

WebRTC 的非網路瀏覽器實現（任何不包含 JavaScript API 的實現）都需要支援 AVC 作為 WebRTC 呼叫中的編解碼器。雖然網路瀏覽器不需要這樣做，但有些瀏覽器確實支援。

在 Web 瀏覽器的 HTML 內容中，AVC 具有廣泛的相容性，並且許多平臺支援 AVC 媒體的硬體編碼和解碼。但是，在選擇在您的專案中使用 AVC 之前，請注意其許可要求！

ITU 的H.263編解碼器主要設計用於低頻寬情況。特別是，它專注於 PSTN（公用交換電話網路）、RTSP 和 SIP（基於 IP 的視訊會議）系統上的視訊會議。儘管針對低頻寬網路進行了最佳化，但它在 CPU 上的佔用率相當高，在低端計算機上可能無法充分發揮效能。資料格式類似於 MPEG-4 第 2 部分。

H.263 從未在 Web 上廣泛使用。H.263 的變體已被用作其他專有格式的基礎，例如 Flash 影片或 Sorenson 編解碼器。但是，沒有主要瀏覽器預設包含 H.263 支援。某些媒體外掛啟用了對 H.263 媒體的支援。

與大多數編解碼器不同，H.263 以每幀（圖片）的最大位元率 (BPPmaxKb) 來定義編碼影片的基本原理。在編碼過程中，會為 BPPmaxKb 選擇一個值，然後影片每幀都不能超過此值。最終位元率將取決於此值、幀率、壓縮以及所選的解析度和塊格式。

H.263 已被 H.264 取代，因此被認為是一種遺留媒體格式，如果可以，您通常應避免使用。在新專案中使用 H.263 的唯一真正原因是，如果您需要在非常舊的裝置上提供支援，而 H.263 是您的最佳選擇。

H.263 是一種專有格式，專利由許多組織和公司持有，包括 Telenor、富士通、摩托羅拉、三星、日立、寶利通、高通等等。要使用 H.263，您有法律義務獲得相應的許可。

高效影片編碼 (HEVC) 編解碼器由 ITU 的H.265以及 MPEG-H 第 2 部分（MPEG-4 的仍在開發中的後續版本）定義。HEVC 旨在支援對包括超高畫質解析度（包括 8K 影片）在內的影片進行高效編碼和解碼，其結構專門設計為讓軟體能夠利用現代處理器。理論上，HEVC 可以實現比AVC壓縮一半的檔案大小，但影像質量相當。

例如，每個編碼樹單元 (CTU)——類似於以前編解碼器中使用的宏塊——包含每個樣本的亮度值樹以及同一編碼樹單元中使用的每個色度樣本的色度值樹，以及任何所需的語法元素。這種結構支援多核輕鬆處理。

HEVC 的一個有趣特性是，主配置檔案僅支援每個元件 8 位顏色，並使用 4:2:0 色度下采樣。另一個有趣的是，4:4:4 影片的處理方式很特殊。它不是將亮度樣本（表示影像的灰度畫素）和 Cb 和 Cr 樣本（指示如何改變灰度以建立彩色畫素）分開，而是將這三個通道視為三個單色影像，每個顏色一個，然後在渲染過程中將它們組合起來生成全綵色影像。

HEVC 是一種專有格式，受多項專利保護。許可證由Via LA 管理；費用收取於開發人員而不是內容製作方和發行方。在決定是否在您的應用或網站中使用 HEVC 之前，請務必檢視最新的許可條款和要求！

MPEG-4 影片基本流 (MP4V-ES) 格式是 MPEG-4 第 2 部分視覺標準的一部分。雖然一般來說，由於 MPEG-4 第 2 部分影片與其他編解碼器相比缺乏吸引力，因此沒有人使用它，但 MP4V-ES 在移動裝置上確實有一些應用。MP4V 本質上是 MPEG-4 容器中的 H.263 編碼。

其主要目的是用於透過RTP 會話流式傳輸 MPEG-4 音訊和影片。但是，MP4V-ES 也用於透過使用3GP的移動連線傳輸 MPEG-4 音訊和影片。

您幾乎肯定不想使用此格式，因為它不受任何主要瀏覽器以有意義的方式支援，並且已經過時。此類檔案應具有副檔名.mp4v，但有時會被錯誤地標記為.mp4。

MPEG-1 第 2 部分影片於 1990 年代初推出。與後來的 MPEG 影片標準不同，MPEG-1 是由 MPEG 獨自建立的，沒有ITU 的參與。

由於任何 MPEG-2 解碼器也可以播放 MPEG-1 影片，因此它與各種軟體和硬體裝置相容。與 MPEG-1 影片相關的活動專利已不存在，因此可以免費使用它，無需擔心任何許可問題。但是，很少有網路瀏覽器在沒有外掛支援的情況下支援 MPEG-1 影片，並且由於網路瀏覽器中外掛的使用已棄用，因此這些外掛通常不再可用。這使得 MPEG-1 成為在網站和 Web 應用程式中使用的糟糕選擇。

MPEG-2 第 2 部分 是 MPEG-2 規範中定義的影片格式，有時也稱為其ITU 指定，即 H.262。它與 MPEG-1 影片非常相似——事實上，任何 MPEG-2 播放器都可以自動處理 MPEG-1，而無需任何特殊操作——除了它已擴充套件為支援更高的位元率和增強的編碼技術。

目標是允許 MPEG-2 壓縮標準清晰度電視，因此也支援隔行掃描影片。標準清晰度壓縮率和所得影片的質量足以滿足需求，因此 MPEG-2 是 DVD 影片媒體中使用的主要影片編解碼器。

MPEG-2 提供了幾個具有不同功能的配置檔案。然後，每個配置檔案都提供四個級別，每個級別都會提高影片的屬性，例如幀速率、解析度、位元率等。大多數配置檔案使用帶 4:2:0 色度下采樣的 Y'CbCr，但更高級別的配置檔案也支援 4:2:2。此外，還有四個級別，每個級別都提供對更大幀尺寸和位元率的支援。例如，北美使用的電視ATSC 規範支援高畫質晰度 MPEG-2 影片，使用主配置檔案的高級別，允許 4:2:0 影片以 1920 x 1080（30 FPS）和 1280 x 720（60 FPS）兩種格式，最大位元率為 80 Mbps。

但是，很少有網路瀏覽器在沒有外掛支援的情況下支援 MPEG-2，並且由於網路瀏覽器中外掛的使用已棄用，因此這些外掛通常不再可用。這使得 MPEG-2 成為在網站和 Web 應用程式中使用的糟糕選擇。

Theora 由Xiph.org 開發，是一種開放且免費的影片編解碼器，可以使用，無需支付版稅或許可費。Theora 在質量和壓縮率方面與 MPEG-4 第 2 部分視覺和 AVC 相當，使其成為非常好的選擇，即使不是最佳選擇，也可用於影片編碼。但它免受任何許可問題的影響，並且其相對較低的 CPU 資源需求使其成為許多軟體和 Web 專案的熱門選擇。低 CPU 影響特別有用，因為 Theora 沒有可用的硬體解碼器。

Theora 最初基於 On2 Technologies 的 VC3 編解碼器。編解碼器及其規範在 LGPL 許可下發布，並委託給 Xiph.org，後者隨後將其發展為 Theora 標準。

Theora 的一個缺點是它每個顏色元件僅支援 8 位，沒有選擇使用 10 位或更多位來避免顏色帶狀現象。也就是說，每個元件 8 位仍然是當今最常用的顏色格式，因此在大多數情況下，這只是一個小的不便。此外，Theora 只能用於 Ogg 容器。然而，最大的缺點是 Safari 不支援它，這使得 Theora 不僅在 macOS 上不可用，而且在數百萬臺 iPhone 和 iPad 上都不可用。

Theora 食譜 提供了有關 Theora 以及它在其內使用的 Ogg 容器格式的更多詳細資訊。

影片處理器 8 (VP8) 編解碼器最初由 On2 Technologies 建立。在收購 On2 後，Google 將 VP8 釋出為開放且免版稅的影片格式，承諾不執行相關專利。在質量和壓縮率方面，VP8 與AVC 相當。

如果瀏覽器支援，VP8 允許影片包含 Alpha 通道，使影片播放時背景能夠透過影片，透過程度由每個畫素的 Alpha 分量指定。

VP8 在 HTML 內容中擁有良好的瀏覽器支援，尤其是在 WebM 檔案中。這使得 VP8 成為內容的良好選擇，儘管如果可用，VP9 是更好的選擇。Web 瀏覽器**需要**支援 VP8 用於 WebRTC，但並非所有支援 WebRTC 的瀏覽器也支援 HTML 音訊和影片元素中的 VP8。

影片處理器 9（VP9）是谷歌開發的舊版 VP8 標準的繼任者。與 VP8 一樣，VP9 完全開放且免版稅。其編碼和解碼效能與 AVC 相當或略快，但質量更高。VP9 的編碼影片質量與 HEVC 在類似位元率下的質量相當。

VP9 的主要配置檔案僅支援 4:2:0 色度下采樣級別的 8 位色深，但其配置檔案包括對更深色深和全範圍色度下采樣模式的支援。它支援多種 HDR 實現，並在選擇幀率、縱橫比和幀大小方面提供了很大的自由度。

VP9 受到瀏覽器的廣泛支援，並且編解碼器的硬體實現相當普遍。VP9 是 WebM 規定的兩種影片編解碼器之一（另一種是 VP8）。但是請注意，Safari 對 WebM 和 VP9 的支援是在 14.1 版本中才引入的，因此，如果您選擇使用 VP9，請考慮為 iPhone、iPad 和 Mac 使用者提供 AVC 或 HEVC 等備用格式。

如果您能夠使用 WebM 容器（並且可以根據需要提供備用影片），那麼 VP9 是一個不錯的選擇。如果您希望使用開放編解碼器而不是專有編解碼器，尤其如此。

決定使用哪個或哪些編解碼器首先要進行一系列問題準備。

• 您希望使用開放格式，還是也要考慮專有格式？
• 您是否有資源為每個影片製作多種格式？提供備用選項的能力極大地簡化了決策過程。
• 您是否願意犧牲與某些瀏覽器的相容性？
• 您需要支援的最舊版 Web 瀏覽器的版本有多舊？例如，您需要在過去五年的每個瀏覽器版本中都執行，還是隻需要過去一年的？

在下面的部分中，我們為特定的用例提供了推薦的編解碼器選擇。對於每個用例，您最多會找到兩個建議。如果被認為最適合該用例的編解碼器是專有的或可能需要支付版稅，則會提供兩個選項：首先是開放且免版稅的選項，然後是專有選項。

如果您只能提供每個影片的一個版本，則可以選擇最適合您需求的格式。第一個建議是質量、效能和相容性的良好組合。第二個選項將是最廣泛相容的選擇，但會犧牲一定程度的質量、效能和/或大小。

首先，讓我們看看在典型網站（例如部落格、資訊網站、小型企業網站，這些網站使用影片來演示產品，但影片本身不是產品）等上展示的影片的最佳選擇。

1. 使用 WebM 容器，使用 VP9 編解碼器進行影片編碼，使用 Opus 編解碼器進行音訊編碼。這些都是開放的、免版稅的格式，通常得到很好的支援，儘管僅在最近的瀏覽器中得到支援，這就是為什麼備用格式是一個好主意。
   html

   <video controls src="filename.webm"></video>
   

2. MP4 容器和 AVC（H.264）影片編解碼器，理想情況下使用 AAC 作為音訊編解碼器。這是因為帶有 AVC 和 AAC 編解碼器的 MP4 容器是一種廣泛支援的組合——事實上，每個主要瀏覽器都支援它——並且質量通常對大多數用例來說都很好。但是，請確保您驗證自己是否符合許可證要求。
   html

   <video controls>
     <source type="video/webm" src="filename.webm" />
     <source type="video/mp4" src="filename.mp4" />
   </video>
   

如果您的目標是以儘可能高的質量呈現影片，那麼您可能受益於提供儘可能多的格式，因為能夠提供最佳質量的編解碼器往往也是最新的，因此最有可能存在瀏覽器相容性差距。

1. 使用 AV1 進行影片編碼和 Opus 進行音訊編碼的 WebM 容器。如果您能夠在編碼 AV1 時使用高或專業配置檔案，並在 6.3 等高級別上進行編碼，則可以在 4K 或 8K 解析度下獲得非常高的位元率，同時保持出色的影片質量。使用 Opus 的全頻帶配置檔案以 48 kHz 取樣率對音訊進行編碼可以最大限度地提高捕獲的音訊頻寬，捕獲幾乎所有人類聽力範圍內的頻率。
   html

   <video controls src="filename.webm"></video>
   

2. 使用 HEVC 編解碼器（使用高階主配置檔案之一，例如具有 10 或 12 位色深的 Main 4:2:2，甚至最多每個分量 16 位的 Main 4:4:4）的 MP4 容器。在高位元率下，這提供了出色的圖形質量和卓越的色彩再現。此外，您可以選擇包含 HDR 元資料以提供高動態範圍影片。對於音訊，請使用高取樣率（至少 48 kHz，但理想情況下為 96kHz）的 AAC 編解碼器，並使用複雜編碼而不是快速編碼進行編碼。
   html

   <video controls>
     <source type="video/webm" src="filename.webm" />
     <source type="video/mp4" src="filename.mp4" />
   </video>
   

目前 Web 瀏覽器中通常沒有可用的無損或接近無損的影片編解碼器。原因很簡單：影片檔案很大。無失真壓縮的效率必然低於有失真壓縮。例如，具有 4:2:0 色度下采樣的未壓縮 1080p 影片（1920 x 1080 畫素）至少需要 1.5 Gbps。使用 FFV1 等無失真壓縮（Web 瀏覽器不支援）可能會將其降低到大約 600 Mbps，具體取決於內容。這仍然是每秒需要透過連線傳輸的大量位元，目前對於任何實際應用來說都不切實際。

即使某些有損編解碼器提供了無損模式，情況也是如此；任何當前的 Web 瀏覽器都沒有實現無損模式。您能做的最好的事情是選擇一個使用有失真壓縮的高質量編解碼器，並將其配置為儘可能少地進行壓縮。一種方法是將編解碼器配置為使用“快速”壓縮，這本質上意味著實現的壓縮更少。

在外部準備影片

要從網站或應用程式外部準備用於存檔的影片，請使用一個實用程式對原始未壓縮的影片資料進行壓縮。例如，免費的 x264 實用程式可用於使用非常高的位元率以 AVC 格式編碼影片

x264 --crf 18 -preset ultrafast --output outfilename.mp4 infile

雖然其他編解碼器在對影片進行大幅壓縮時可能具有更好的最佳質量水平，但它們的編碼器往往速度慢到足以使您使用這種壓縮獲得的近乎無損的編碼在幾乎相同的整體質量水平下速度快得多。

錄製影片

考慮到您能夠獲得的接近無損程度的限制，您可能會考慮使用 AVC 或 AV1。例如，如果您使用 媒體流錄製 API 錄製影片，則在建立 MediaRecorder 物件時，可以使用以下程式碼

const kbps = 1024;
const Mbps = kbps * kbps;

const options = {
  mimeType: 'video/webm; codecs="av01.2.19H.12.0.000.09.16.09.1, flac"',
  bitsPerSecond: 800 * Mbps,
};

let recorder = new MediaRecorder(sourceStream, options);

此示例建立了一個 MediaRecorder，配置為使用 BT.2100 HDR 以 12 位顏色和 4:4:4 色度下采樣錄製 AV1 影片，並使用 FLAC 進行無損音訊錄製。結果檔案將使用影片和音訊軌道共享的位元率不超過 800 Mbps。您可能需要根據硬體效能、您的要求以及您選擇使用的特定編解碼器調整這些值。此位元率顯然不適用於網路傳輸，可能僅在本地使用。

將 codecs 引數的值分解成其點分隔的屬性，我們看到以下內容

您編解碼器選擇的文件可能會提供在構建 codecs 引數時將使用到的資訊。

• Web 音訊編解碼器指南
• 媒體容器格式（檔案型別）
• 處理 Web 內容中的媒體支援問題
• WebRTC 使用的編解碼器
• RFC 6381：“Bucket”媒體型別的“編解碼器”和“配置檔案”引數
• RFC 5334：Ogg 媒體型別
• RFC 3839：3GPP 多媒體檔案的 MIME 型別註冊
• RFC 4381：3GPP2 多媒體檔案的 MIME 型別註冊
• RFC 4337：MPEG-4 的 MIME 型別註冊
• Chrome 中的影片和音訊編解碼器