AVIF 檔案格式
AV1 Image File Format，以 AV1 視訊編碼為基礎的現代靜態影像格式。
- MIME 類型
- image/avif
- 副檔名
- .avif
- 分類
- 圖片
Magic number（檔案簽章）
| 0x00000004 | 66747970 | ftyp | ISO-BMFF 'ftyp' box |
| 0x00000008 | 61766966 | avif | brand 'avif' |
關於 AVIF 格式
AVIF 把 AV1 視訊編碼用在靜態影像上，在支援 HDR 與廣色域的同時提供極佳的壓縮率。它和 MP4 一樣是 ISO-BMFF 檔案：位移 4 處的 'ftyp' box 帶著品牌識別 'avif'。除了第一個 box 之外，ISO-BMFF 檔案裡沒有任何東西的位置是固定的，因為這個格式是一棵 box 樹，每個 box 都以自己的大小和四字元類型開頭。AVIF 的圖是以 item 的形式存在 'meta' box 裡，而不是存成一條軌 — 這正是靜態影像和共用同一個容器的影片檔之間的分水嶺。
檔頭結構，一個位元組一個位元組看
| 位移 | 長度 | 欄位 | 意義 |
|---|---|---|---|
| 0 | 4 | ftyp box size | 檔案類型 box 的長度，大端序，含這四個位元組本身；一個品牌識別加兩個相容品牌識別的情況下，常見值是 00 00 00 18 — 二十四。ISO-BMFF 的每個數字都是大端序，和那些 RIFF 格式相反。大小是 1 代表類型後面跟著一個 64 位元長度，大小是 0 代表這個 box 一路延伸到檔案結尾。 |
| 4 | 4 | Box type | 66 74 79 70，ASCII 的 ftyp 四個字母。規格要求檔案類型 box 必須排第一，這就是為什麼即使格式裡沒有別的東西位置固定，位移 4 仍然是個可靠的觀察點。AVIF、HEIC、HEIF、MP4、MOV 和 3GP 共用的就是這段位元組。 |
| 8 | 4 | Major brand | 靜態影像是 61 76 69 66。影像序列與動畫 AVIF 用的是 61 76 69 73 — avis — 所以動畫和靜態圖在這裡只差一個位元組，解碼方式卻差很多。 |
| 12 | 4 | Minor version | 純資訊性的數字，對剖析毫無影響，幾乎一律是 00 00 00 00。它不是品牌識別的版本，讀取端也不准因為它而拒收檔案。 |
| 16 | variable | Compatible brands | 每個四個位元組，把 box 剩下的空間填滿，所以 24 位元組的 ftyp 剛好放兩個。macOS 產出的檔案會列 avif 和 mif1；網頁編碼器產的常常再加上 miaf 和 MA1B 這類編碼限制品牌識別。讀取端只要認得這串清單裡任何一個品牌識別就可以打開檔案 — 這也是為什麼光看主要品牌識別並不算數。 |
| 24 | 4 | Next box size | 緊接在 24 位元組的 ftyp 之後，下一個 box 的標頭就開始了。走訪 box 的方式是把每個大小加到目前位置上，所以這裡有一個大小寫錯，後面整個檔案就找不回來 — ISO-BMFF 裡任何地方都沒有重新同步的機制。 |
| 28 | 4 | Next box type | 通常是 6D 65 74 61 — meta — 也就是裝著 item 清單、item 屬性和 item 位置的那個 box，正是它們讓這個檔案成為靜態影像檔。如果找到的是 trak box，那不管副檔名寫什麼，這其實是一段影片。 |
怎麼跟長得像的格式分開
| 容易搞混的 | 怎麼分 |
|---|---|
| HEIC | 同一個容器、同樣的前八個位元組，全部由位移 8 那四個位元組決定：61 76 69 66 是 AV1 編的，68 65 69 63 是 HEVC 編的。實際後果與其說是結構問題不如說是授權問題 — 現在的瀏覽器全都解得開 AVIF，除了 Safari 沒有一個解得開 HEIC — 而且怎麼重新封裝都不可能把一個變成另一個，因為壓縮後的影像資料本身就是不同的編碼。 |
| HEIF | 比看起來難，因為 AVIF 檔案會把 mif1 列進自己的相容品牌識別裡。macOS 產出的 AVIF 在位移 8 是 avif、位移 20 是 mif1，所以只要在 ftyp box 裡任何位置比對到 mif1 就下判斷的偵測器，會把它叫成 HEIF。只有位移 8 的主要品牌識別，才決定這個檔案主要宣稱自己是什麼格式。 |
| MP4 | 位移 4 一模一樣，唯一不同的是位移 8 的品牌識別：影片是 isom、mp42、avc1 或 dash，影像是 avif 或 avis。更深一層的判別是結構性的 — 靜態影像把圖存成 meta box 底下的 item，影片則存成由 trak box 描述的樣本 — 而 avis 序列是故意把這條線弄模糊的。 |
| WebP | 52 49 46 46 對上一個四位元組的 box 長度，位元組層級不可能搞混。它們爭的是 picture 元素裡的同一個位置，取捨也很一致：同畫質下 AVIF 通常比 WebP 小兩成到五成，編碼時間則多一個數量級。 |
常見的壞法
- 截斷。帶著尺寸與 item 屬性的 meta box 通常坐在檔案前段，所以解碼器會很順利地報出影像尺寸，然後找不到任何像素 — 或者對分塊的影像來說只找得到第一塊 — 因為 mdat box 被切掉了。完好的 AVIF，最後一個 box 會剛好結束在檔案結尾，這就是要檢查的地方。
- box 大小寫錯。走訪 box 靠的是把大小一路相加，所以一個長度錯了，剖析器就落在另一個 box 的酬載中間，把四個任意位元組當成類型讀。損壞點之後的每個 box 都沒了，即使位元組其實全都在；而這種問題報出來的錯誤，看起來會像某個毫不相干的 box 格式有問題。
- 影像序列被當成靜態圖存下來。品牌識別是 avis 的檔案裡有多個影格，而只實作了靜態 AVIF 的軟體會畫出第一格然後回報成功。沒有任何東西壞掉；其他影格就是永遠不會出現，而檔案大小相對於你看到的那張圖大得莫名其妙。
- 色彩屬性遺失或寫錯。AVIF 把色彩原色、轉換函式和矩陣當成 item 屬性帶著走，轉檔工具把它們丟掉，解碼器就只能用猜的。一張 HDR 影像於是被算繪成褪色或過飽和的 SDR，而結構上完全合法 — 這就是為什麼同一個 AVIF 在某個瀏覽器裡看起來不對、在另一個裡卻是對的。
- 軟體太舊，吃不下這個檔案。AVIF 在 2020 到 2022 年間才陸續進入瀏覽器，而大量桌面與伺服器軟體至今仍然解不開。一個在 Chrome 裡打得開、在其他地方全部失敗的檔案，通常根本沒壞 — 確認位移 4 讀到 ftyp、位移 8 讀到 avif，就足以排除損壞了。
這個格式現在還在用嗎
AVIF 是目前壓縮效果最好、而且瀏覽器支援真的夠廣的影像格式：Chrome 從 2020 年、Firefox 從 2021 年、Safari 從 2022 年開始支援。網站如果本來就用 picture 元素配 fallback，照片內容拿它當預設就對了。跟 JPEG 比，同畫質下通常省一半的位元組；跟 WebP 比省兩成到五成。它還帶來舊格式根本沒有的能力：每通道 10 與 12 位元、HDR 轉換函式、廣色域、底片顆粒合成、alpha 和動畫，全部裝在同一個容器裡。代價是編碼時間，比 JPEG 高上一到兩個數量級，所以它是 build 步驟或 CDN 用的格式，不是手機或瀏覽器上傳路徑上能即時產出的東西。瀏覽器之外的支援還很零散 — 一堆桌面編輯器、郵件軟體和舊版 Android 都打不開 — 所以現在還不能安心把它當成一個檔案直接交給別人。合理的安排、也是多數大站現在的做法，是 picture 元素裡 AVIF 排第一、WebP 第二、JPEG 墊底。
在這個站上打開 AVIF 檔
這些全部在你的瀏覽器裡跑，檔案不會離開你的電腦。
相關格式
容易和 AVIF 搞混的格式，可以比對它們的開頭位元組。