🎬 video 視訊位元率計算機

這款影片位元率計算機可依據解析度、影格率、片長以及你設定的壓縮比，估算出影片的位元率（碼率）與最終檔案大小。對於內容創作者、攝影師、實況主與剪輯師來說，它是一個快速的前置規劃工具——在匯出或上傳之前，就能先掌握這段影片大概需要多少儲存空間與頻寬。

• 影片解析度——可選擇 1920×1080（1080p）、1280×720（720p）或 3840×2160（4K）。計算機會將解析度拆解為寬度與高度，藉此算出每一影格的總像素數。
• 影格率（fps）——每秒顯示的影格數，例如 24、30 或 60。
• 影片片長（分鐘）——影片的長度，用來換算整體檔案大小。
• 壓縮比——代表影片被壓縮的程度。數值越高表示壓縮越強、位元率越低，檔案也越小。

位元率的計算方式如下：

公式中的 24 代表假設的色彩深度（24 位元色彩，也就是紅、綠、藍三個通道各 8 位元）。寬度 × 高度可得到每影格的像素數，再乘以 24 即為每影格的位元數，接著乘上影格率便是未壓縮狀態下每秒的位元數。最後除以壓縮比，就反映出編碼器（codec）將原始資料壓縮後的結果。

檔案大小則由此延伸計算：每秒位元數 × 60 × 片長（分鐘）即為總位元數，再除以 8 × 1024 × 1024 換算成 MB（百萬位元組），若要換算成 GB（十億位元組）則再除以 1024。

假設你有一段 1080p、30 fps 的影片，片長 10 分鐘，壓縮比設定為 100。

• 每影格像素數：1920 × 1080 = 2,073,600
• 每秒位元數：(2,073,600 × 24 × 30) ÷ 100 = 14,929,920 bps ≈ 14,930 Kbps ≈ 14.93 Mbps
• 10 分鐘的總位元數：14,929,920 × 60 × 10 = 8,957,952,000 位元
• 檔案大小：8,957,952,000 ÷ (8 × 1024 × 1024) ≈ 1,067 MB ≈ 1.04 GB

此計算機產生的比特率是一個理論數字，源自原始像素吞吐量除以壓縮比。真實世界的傳遞平台發布自己建議的上傳和串流比特率，這些經過調整以適應其編碼器和觀看者頻寬。以下的值取自平台發布的指導（YouTube 幫助文檔中的建議上傳編碼設置，以及 Twitch 的播放指南）— 這些不是此計算機的輸出，您應該將其視為與您計算的比特率進行比較的目標。

YouTube 建議的上傳比特率 (SDR, H.264)

YouTube 發布的 HDR 和 4K 圖像位於這些範圍的上端；平台無論如何都會重新編碼每次上傳，因此上傳遠高於建議主要是保護免受代數損失，而不是改善傳遞的串流。

直播範圍

編碼效率：H.264 vs HEVC vs AV1

上面的表格假設 H.264 (AVC)。較新的編碼器以明顯較低的比特率達到可比較的感知品質。作為規劃經驗法則，廣泛報告的比較將 HEVC/H.265 和 AV1 大致置於比 H.264 低 30–50%（相同主觀品質），較大的節省出現在較高的解析度：

HEVC 和 AV1 欄位是 H.264 基準的說明性縮放，不是單獨發布的數字 — 實際節省取決於編碼器實現、預設速度和內容複雜性。平台建議和上面的比特率上限也隨時間變化並按帳戶層級和區域而異，因此在最終確定編碼預設之前請檢查平台的最新文檔。

此表中的每個數字都由計算機自身公式產生，因此數字與工具完全相符：

然後檔案大小是比特率在片段時長內保持的，從位元轉換為百萬位元組 (此處 1 MB = 1024^2 位元組)：

工作示例：1080p，30 fps，比率 100

從像素計數開始，乘以假設的每像素 24 位，然後乘以幀率，然後除以壓縮比：

現在在 10 分鐘 (600 秒) 內保持該比特率：

讀表

1. 幀率和壓縮比是對稱的。加倍幀率 (1080p30 → 1080p60) 和減半比率 (100 → 50) 都會加倍比特率。注意第三和第四行由於這個原因在比特率中完全相同。
2. 4K 是 1080p 的四倍。3840×2160 包含的像素數恰好是 1920×1080 的 4 倍，因此以相同的幀率和比率，它花費 4 倍的位元。
3. 這些是模型估計，不是編碼器輸出。使用 4:2:0 色度子採樣和幀間預測的真實 H.264 或 AV1 編碼器通常產生比此 24 位/像素模型對相同視覺品質建議的更小檔案 — 將結果用作儲存和頻寬的規劃上限。
4. 不包括音訊。為立體聲 AAC 或 Opus 音軌添加大約 0.128–0.320 Mbps，與上面的視頻數字相比可以忽略不計，但對於非常低比特率目標很重要。

比特率

每秒視頻使用的位元數，寫作 bit/s (bps)。因為原始視頻數字很大，它們被縮放：1 Kbps = 1,000 bps 和 1 Mbps = 1,000,000 bps。更高的比特率意味著更多數據可用於描述每一幀，這通常意味著更少的壓縮人工製品 — 直到編碼器沒有什麼可改進的地步。

原始/未壓縮比特率

完全沒有壓縮的視頻的比特率：W × H × 每像素位元 × fps。對於 1080p30，每像素 24 位，這大約是 1,493 Mbps — 大約 1.5 Gbps。這是計算機公式的分子，在壓縮比除以它之前。

壓縮比

編碼流比原始流小多少倍。比率 100 意味著編碼器每 100 原始位元保留 1 位元。較大的比率 = 較小的檔案和較低的比特率 = 更多可見的人工製品。值在 50 左右適合高質量主檔案，在 100 左右適合典型網頁傳遞，200 或更多是積極壓縮。

色深度 (24位元)

用於描述一個像素顏色的位元數。24 位意味著跨紅、綠和藍的每個通道 8 位 (8 × 3 = 24)，提供 1,670 萬種顏色。專業和 HDR 管道通常使用每個通道 10 位 (30 位)，這會使原始比特率提高約 25%。

編碼器

壓縮和解壓縮視頻的演算法。H.264/AVC 是近普遍兼容性基準；HEVC/H.265 和 AV1 是較新的，通常以大約 30–50% 更低的比特率達到相同的感知品質，代價是更多編碼時間和更窄的設備支持。AV1 是免版稅的；H.264 和 HEVC 是專利許可的。

CBR vs VBR

恆定比特率 (CBR) 每秒花費相同的位元 — 對於實時串流和固定頻寬鏈路是可預測的，但在靜止場景上浪費，在複雜場景上挨餓。可變比特率 (VBR) 將位元轉向困難場景，為相同檔案大小提供更好的平均品質；它是隨選檔案的正常選擇。

恆定品質 / CRF

一種速率控制模式，您設置目標品質級別而不是比特率，編碼器花費該級別所需的任何位元。在 x264 和 x265 中，這是 CRF 值：更低的 CRF = 更高的品質和更大的檔案。對於不需要達到確切大小或頻寬上限的檔案，它通常提供最佳的每位元組品質。

色度子採樣 (4:2:0 vs 4:2:2)

人類視覺對亮度比對色彩細節敏感得多，因此大多數編碼器以降低的解析度儲存色彩信息。4:4:4 保持每個像素的完整色彩；4:2:2 將水平色彩解析度減半；4:2:0 將其在水平和垂直方向上都減半。4:2:0 — 幾乎所有串流和消費者傳遞使用的格式 — 每像素平均攜帶約 12 位而不是 24，這是真實編碼比計算機的每像素 24 位假設更小的主要原因之一。幀間預測（重複使用相鄰幀的信息）佔大部分其餘的。

容器 vs 編碼器

編碼器是圖片如何被壓縮的；容器 (MP4、MKV、MOV、WebM) 是保存壓縮視頻、音軌、字幕和定時元數據的檔案包裝器。相同的 H.264 流可以在 MP4、MKV 或 MOV 中 — 檔案擴展名告訴您容器，而不是編碼器。

位元 vs 位元組，以及 MB vs MB

比特率以位元報價，檔案大小以位元組報價，8 位元 = 1 位元組 — 因此 16 Mbps 流每秒儲存 2 百萬位元組，而不是 16。兩種不同的「百萬位元組」定義也在流通中：二進制定義，1 MB = 1024^2 = 1,048,576 位元組（嚴格來說是一個 mebibyte，MiB），由大多數操作系統在報告檔案大小時使用；以及十進制定義，1 MB = 10^6 = 1,000,000 位元組，由驅動器製造商和網絡工程師使用。差距在百萬位元組規模為約 4.9%，在十億位元組規模為 7.4%。本文中的檔案大小使用二進制 1024^2 約定。