第 24 章：SeaMeet 的運作原理（技術篇）

簡介

您是否曾好奇，當您按下「錄製」按鈕後，幕後究竟發生了什麼事？SeaMeet 如何捕獲螢幕畫面、編碼影片、儲存檔案，並在不讓電腦過熱的情況下即時完成這一切？本章將揭開這些技術魔法的神秘面紗。

別擔心——您不需要電腦科學學位才能理解這些內容。我們將用淺顯易懂的語言、類比說明和視覺範例來解釋一切。讀完本章後，您將對整個錄製管線有紮實的理解，從點擊「錄製」的那一刻，到檔案出現在您的資料庫為止。

本章目標

閱讀完本章後，您將能夠：

理解從頭到尾的完整錄製管線
了解音訊和影片捕獲在技術層面的運作方式
理解編碼、壓縮與檔案格式
學習 Flashback 的循環緩衝區如何運作
了解自動偵測如何監控您的系統
理解某些技術限制存在的原因
根據技術知識做出明智的設定決策

第一部分：錄製管線概覽

錄製的旅程

讓我們追蹤當您點擊「開始錄製」後發生的事情：

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   捕獲      │ →  │   處理      │ →  │   編碼      │ →  │   儲存      │
│             │    │             │    │             │    │             │
│ 螢幕 +      │    │ 原始資料    │    │ 壓縮        │    │ 寫入        │
│ 音訊        │    │ 緩衝        │    │ 影片/音訊   │    │ 磁碟        │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
     ↓                  ↓                  ↓                  ↓
  30-60 fps         記憶體緩衝區      H.264/MP3         MP4/WebM
  44.1-48kHz        暫存             壓縮              最終檔案

時間尺度： 這一切在您錄製期間持續發生，每秒 30 到 60 次。

第二部分：影片捕獲

螢幕捕獲的運作方式

概念： 您的電腦螢幕就像一幅不斷變化的畫作。SeaMeet 以極快的速度為這幅畫拍照，以創造影片。

技術流程：

畫面擷取

作業系統提供：
┌─────────────────────────────┐
│  螢幕緩衝區（畫面）         │
│  1920×1080 像素             │
│  每秒 60 次                 │
└─────────────────────────────┘
         ↓
SeaMeet 捕獲此緩衝區

畫面緩衝區

捕獲的畫面進入：
┌─────────────────────────────┐
│  RAM 緩衝區                 │
│  暫存區域                   │
│  等待編碼的佇列             │
└─────────────────────────────┘

三種捕獲模式：

全螢幕捕獲：

捕獲整個螢幕緩衝區
大小：1920×1080 × 每像素 4 位元組 = 每幀約 8 MB
以 30 fps 計算：每秒 240 MB 原始資料

視窗捕獲：

作業系統告知 SeaMeet：「視窗位於座標 (x, y, 寬, 高)」
SeaMeet 僅捕獲該矩形區域
尺寸較小 = 資料量較少

區域捕獲：

您定義矩形：(起始_x, 起始_y, 寬, 高)
SeaMeet 精確捕獲該區域
最高效率（最少資料）

幀率的數學

30fps 實際代表什麼：

每秒 30 幀 =
• 每秒 30 次螢幕捕獲
• 每 33.3 毫秒 1 幀
• 每分鐘 1,800 幀
• 每小時 108,000 幀（30fps）

在 1080p 解析度下：
• 1 幀 = 1920 × 1080 像素
• 1 幀 = 2,073,600 像素
• 1 幀 = 未壓縮約 6 MB
• 30 幀 = 每秒約 180 MB 未壓縮
• 1 小時 = 未壓縮約 650 GB！

這就是壓縮不可或缺的原因！

第三部分：音訊捕獲

音訊錄製的運作方式

概念： 聲音是波。您的電腦以極快的速度將這些波轉換為數字。

技術流程：

麥克風輸入

聲波 → 麥克風 → 類比訊號
                         ↓
類比轉數位轉換器 (ADC)

取樣

取樣率：每秒 44,100 或 48,000 個取樣點

想像成對波形拍照：
• 每秒 48,000 張照片
• 每張照片捕獲該瞬間的波形高度
• 取樣點越多 = 波形重現越精確

位元深度

16 位元 = 65,536 個可能值
24 位元 = 16,777,216 個可能值

就像照片中的像素：
• 位元越多 = 聲音的「顏色」越多
• 動態範圍更好（安靜與嘈雜的對比）

數學計算：

CD 品質音訊：
• 取樣率 44.1 kHz
• 16 位元深度
• 2 聲道（立體聲）
• 每秒：44,100 × 16 × 2 = 1,411,200 位元 = 176 KB/s
• 每分鐘：未壓縮約 10.5 MB

高品質音訊：
• 取樣率 48 kHz
• 24 位元深度
• 2 聲道
• 每秒：48,000 × 24 × 2 = 2,304,000 位元 = 288 KB/s
• 每分鐘：未壓縮約 17 MB

系統音訊捕獲

運作方式：

系統音訊不是從喇叭「捕獲」的——而是在到達喇叭之前被攔截：

應用程式 → 系統音訊混音器 → 喇叭
                  ↓
               SeaMeet
                  ↓
               錄製

在 Windows 上：

使用「立體聲混音」或迴路錄製
在驅動程式層面攔截音訊串流
無品質損失

在 macOS 上：

需要螢幕錄製權限
使用 CoreAudio 框架
建立虛擬音訊裝置

第四部分：編碼與壓縮

為何需要壓縮

問題所在：

1080p 30fps 原始影片：
• 每秒 180 MB
• 每分鐘 10.8 GB
• 每小時 650 GB！

CD 原始音訊：
• 每分鐘 10.5 MB
• 每小時 630 MB

沒有電腦能以那麼快的速度寫入那麼多資料！

解決方案： 壓縮

影片壓縮（編解碼器）

影片壓縮的運作方式：

幀類型：

I 幀（關鍵幀）：完整影像
• 就像一張完整的照片
• 檔案較大
• 參考點

P 幀（預測幀）：相對前一幀的變化
• 只儲存變化的部分
• 檔案小得多
• 「人物的嘴巴移動了」

B 幀（雙向幀）：過去和未來幀的變化
• 最高效率
• 參考前後幀
• 編碼較複雜

範例：

影片序列：I P P B P B P I P P B P

I 幀：完整影像（較大）
P 幀：僅移動部分（較小）
B 幀：智慧預測（最小）

H.264 壓縮流程：

將幀分割為宏塊（16×16 像素的方塊）
與前一幀比較
尋找相符的區塊
只儲存差異
套用數學變換（DCT）
量化（降低精度）
熵編碼（高效位元打包）

壓縮比：

未壓縮：每小時 650 GB
H.264 壓縮後：每小時 4-8 GB
壓縮比：約 100:1

影片看起來幾乎一模一樣！
品質損失幾乎察覺不到。

音訊壓縮

無損與有損：

無損（WAV、FLAC）：

保留每一位元的音訊
就像音訊的 ZIP 壓縮
縮減 50% 大小
完美品質

有損（MP3、AAC）：

移除「無法聽見」的聲音
檔案小得多
縮減 90% 大小
品質損失（但通常難以察覺）

MP3 壓縮流程：

心理聲學模型
- 識別人類無法聽見的聲音
- 將其移除
頻率分析
- 將音訊分解為頻率頻帶
- 對每個頻帶進行不同程度的壓縮
位元分配
- 為可聽見的聲音分配更多位元
- 為被遮蔽的聲音分配較少位元
霍夫曼編碼
- 高效位元打包

壓縮比：

未壓縮 WAV：每小時 630 MB
MP3 128 kbps：每小時約 60 MB（縮減 90%）
MP3 320 kbps：每小時約 150 MB（縮減 75%）

第五部分：Flashback 系統

循環緩衝區架構

概念： 想像一條循環運轉的輸送帶。物品在帶上停留固定的時間，然後從末端掉落。

技術實現：

Flashback 緩衝區結構：

┌──────────────────────────────────────────────────────────┐
│  循環緩衝區（RAM）                                       │
│                                                          │
│  ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐      │
│  │F1  │→│F2  │→│F3  │→│F4  │→│F5  │→│F6  │→│F7  │      │
│  └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘      │
│    ↑                                         ↓           │
│    └─────────────────────────────────────────┘           │
│                   （循環回繞）                           │
│                                                          │
│  每個「F」= 1 秒的影片                                   │
│  緩衝區大小：60 秒 = 儲存 60 幀                          │
└──────────────────────────────────────────────────────────┘

寫入流程（持續進行）：
1. 將幀寫入當前位置
2. 移動到下一個位置
3. 若到達末尾，回到開頭（覆寫）
4. 每秒重複 30-60 次

儲存流程（觸發時）：
1. 將當前位置標記為「結尾」
2. 向後讀取緩衝區持續時間
3. 複製所有標記的幀
4. 編碼為最終影片檔案
5. 緩衝區持續不中斷運作

記憶體管理：

緩衝區大小計算：

以 1080p 30fps 的 60 秒緩衝區為例：
• 原始：180 MB/s × 60s = 10.8 GB（太多了！）
• 緩衝區中的壓縮資料：約 3 MB/s × 60s = 180 MB
• 含額外開銷的實際使用量：約 200-250 MB

為何有效：

記憶體速度快（RAM 可以處理）
持續覆寫 = 恆定的記憶體使用量
即時儲存 = 只需將緩衝區複製到磁碟
緩衝區滿載後無效能影響

第六部分：自動偵測系統

偵測的運作方式

監控迴圈：

每 500 毫秒（每秒 2 次）：

1. 檢查視窗標題
   ├─ 取得所有開啟視窗的清單
   ├─ 檢查每個標題中的關鍵字：
   │  • "Zoom Meeting"
   │  • "Microsoft Teams"
   │  • "Google Meet"
   │  • 等等
   └─ 分數：找到符合 = +50 分

2. 檢查執行中的程序
   ├─ 取得作用中程序清單
   ├─ 檢查是否有：
   │  • zoom.exe
   │  • Teams.exe
   │  • chrome.exe（含會議 URL）
   └─ 分數：找到程序 = +30 分

3. 檢查音訊串流
   ├─ 監控作用中的音訊頻道
   ├─ 偵測：
   │  • 麥克風是否啟用？
   │  • 喇叭是否啟用？
   │  • 兩者同時啟用？（可能是會議）
   └─ 分數：符合會議模式 = +40 分

4. 檢查視窗幾何
   ├─ 分析視窗形狀
   ├─ 尋找：
   │  • 全螢幕影片
   │  • 九宮格檢視佈局
   │  • 會議控制列
   └─ 分數：符合 = +20 分

5. 評估分數
   ├─ 總分 = 所有訊號的加總
   ├─ 偵測閾值：80 分
   ├─ 高可信度：120+ 分
   └─ 根據分數觸發動作

6. 等待 500ms
   └─ 重複

採用此方法的原因：

多重訊號 = 準確性
加權評分 = 靈活性
快速迴圈（每秒 2 次）= 反應迅速
低資源使用 = 高效率

第七部分：檔案格式與容器

什麼是容器？

類比： 容器就像一個裝有不同物品的盒子：

影片軌道（動態畫面）
音訊軌道（聲音）
元資料（關於影片的資訊）
字幕（如有）

容器與編解碼器的區別：

容器 = 盒子（MP4、WebM、AVI）
編解碼器 = 壓縮方法（H.264、VP8）

想像成：
容器 = 檔案資料夾
編解碼器 = 裡面文件的書寫方式

MP4 容器結構

MP4 檔案結構：

┌──────────────────────────────────────┐
│  ftyp（檔案類型）                    │
│  「這是一個 MP4 檔案」               │
├──────────────────────────────────────┤
│  moov（影片標頭）                    │
│  - 時長：3600 秒                     │
│  - 軌道：2（影片 + 音訊）            │
│  - 時間刻度資訊                      │
├──────────────────────────────────────┤
│  mdat（媒體資料）                    │
│  ┌────────────────────────────────┐  │
│  │ 影片軌道（H.264）              │  │
│  │ 幀 1、幀 2、幀 3...            │  │
│  └────────────────────────────────┘  │
│  ┌────────────────────────────────┐  │
│  │ 音訊軌道（AAC）                │  │
│  │ 取樣 1、取樣 2、取樣 3...      │  │
│  └────────────────────────────────┘  │
└──────────────────────────────────────┘

MP4 為何廣受歡迎：

通用相容性
高效串流
支援多種編解碼器
良好的元資料支援
適用於所有裝置

第八部分：硬體加速

CPU 與 GPU 編碼

CPU 編碼（軟體）：

優點：
• 最高品質
• 最廣相容性
• 適用於所有電腦

缺點：
• 非常慢／CPU 密集
• 消耗電池
• 可能導致系統變慢

GPU 編碼（硬體）：

優點：
• 非常快
• CPU 使用率低
• 專用硬體
• 省電

缺點：
• 品質稍低（幾乎察覺不到）
• 需要相容的 GPU
• 設定彈性較少

硬體加速的運作方式

NVIDIA NVENC：

流程：
1. 原始影片幀傳送至 GPU
2. GPU 的編碼器晶片進行處理
3. 專用硬體執行 H.264 編碼
4. 編碼後的資料傳回
5. CPU 幾乎不介入

結果：CPU 使用率從 50-70% 降至 10-20%

Intel Quick Sync：

內建於 Intel 處理器
專用媒體編碼硬體
對筆記型電腦非常高效
低功耗

AMD VCE：

類似 NVENC，但適用於 AMD GPU
顯示卡上的硬體編碼區塊
品質良好，編碼速度快

第九部分：持續寫入磁碟——零資料遺失

架構

SeaMeet 的錄製引擎建立在串流寫入磁碟模型之上。影片和音訊資料在錄製過程中持續寫入輸出檔案，而非等到使用者停止錄製才一次性寫入記憶體。

傳統錄製器：
┌──────────────────────────────────────────────────────────┐
│  RAM 緩衝區（在整個錄製過程中持續增長）                  │
│  幀 1 → 幀 2 → ... → 幀 216,000（2 小時 @ 30fps）        │
│                                          ↓               │
│                                   [點擊停止]             │
│                                          ↓               │
│                                   寫入磁碟               │
│                                   （單一大型寫入）       │
└──────────────────────────────────────────────────────────┘

SeaMeet 串流模型：
┌──────────────────────────────────────────────────────────┐
│  幀 1-90   → 編碼 → 寫入資料塊 → 磁碟 ✅               │
│  幀 91-180 → 編碼 → 寫入資料塊 → 磁碟 ✅               │
│  幀 181-270→ 編碼 → 寫入資料塊 → 磁碟 ✅               │
│  ...                                                     │
│  [點擊停止] → 完成容器 → 完成 ✅                        │
└──────────────────────────────────────────────────────────┘

關鍵差異： 在 SeaMeet 中，錄製檔案從最初幾秒鐘就已存在於磁碟上並持續增長。如果錄製在任何時間點中斷，所有已寫入磁碟的資料塊均可恢復。

技術實現

影片（WebM/MP4 容器串流）：

VideoRecordingEngine 以串流模式將編碼後的封包直接寫入
開啟的檔案句柄：

編碼封包 → 多工進容器 → flush() 至作業系統檔案快取
                                    ↓
                           在資料塊邊界執行 fsync
                                    ↓
                           資料提交至磁碟

音訊：

PCM 取樣 → 編碼（MP3/AAC/WebM Opus）→ 寫入檔案句柄
                                              ↓
                                     定期 flush + sync

資料塊邊界：

影片：在關鍵幀間隔處每隔幾秒寫入一次
音訊：隨音訊封包持續寫入
兩者：作業系統層級的 fsync 確保資料在程序終止後仍可存活

為何重要

崩潰復原對比表：

事件	僅記憶體錄製器	SeaMeet
應用程式崩潰	100% 資料遺失	最多遺失幾秒（最後未寫入的資料塊）
作業系統崩潰 / BSOD / 核心恐慌	100% 資料遺失	所有已寫入的資料塊均可存活
電源中斷	100% 資料遺失	所有已寫入的資料塊均可存活
強制終止（kill -9）	100% 資料遺失	所有已寫入的資料塊均可存活
正常停止	完整檔案已儲存	完整檔案已儲存

記憶體佔用：

傳統方式：RAM 使用量隨錄製時長增長
  1 小時 1080p @ 30fps ≈ RAM 中 3.6 GB

SeaMeet 串流方式：RAM 使用量保持恆定
  1 小時 1080p @ 30fps ≈ RAM 中約 50-100 MB（僅編碼緩衝區）
  → 其餘 3.5+ GB 已在磁碟上

這也意味著 SeaMeet 可以處理任意長度的錄製，而不會遇到記憶體限制——一段數小時的錄製與 5 分鐘的錄製使用相同的峰值 RAM。

第十部分：效能最佳化

SeaMeet 為何高效

1. 串流寫入（非緩衝批次寫入）：

而非：
幀在 RAM 中累積 → [停止] → 將所有資料傾倒至磁碟

SeaMeet 的做法：
幀 → 編碼 → 將資料塊寫入磁碟（每隔幾秒）

恆定、可預測的磁碟 I/O = 錄製結束時無爆量寫入

2. 非同步編碼：

捕獲執行緒：從螢幕獲取幀
編碼執行緒：壓縮幀
磁碟執行緒：寫入檔案

三個執行緒並行工作
無等待，最高效率

3. 選擇性品質：

Flashback 使用較低品質（快速編碼）
一般錄製使用較高品質
使用者可根據需求選擇

4. 記憶體對應：

大型檔案對應至記憶體
作業系統高效處理分頁
比傳統檔案 I/O 更快

第十部分：限制與約束

為何某些事情無法做到

1. 無法錄製 DRM 內容：

Netflix、Disney+ 等使用加密
顯示卡解密以供顯示
無法捕獲解密後的串流
法律／技術層面的封鎖

SeaMeet 捕獲螢幕緩衝區
但 DRM 內容從不出現在其中
結果：錄製出黑色畫面

2. 無法捕獲受保護的應用程式：

某些銀行應用程式封鎖螢幕捕獲
作業系統層級的安全功能
保護敏感資訊
設計上無法繞過

3. 藍牙音訊延遲：

藍牙音訊具有內建延遲
典型值 100-300ms
並非 SeaMeet 的問題
硬體限制

解決方案：使用有線耳機

4. 無法錄製超過螢幕解析度的影片：

螢幕為 1080p → 錄製最高 1080p
無法憑空從 1080p 創造 4K
像素資料不存在

例外：某些 GPU 支援升頻
但那不是真正的 4K

摘要

SeaMeet 是一套精密的工程技術，它能夠：

✅ 捕獲高速的螢幕畫面與音訊

✅ 壓縮即時影片/音訊（壓縮比 100:1！）

✅ 持續寫入磁碟 — 即使崩潰也不會遺失資料

✅ 使用循環緩衝區 實現 Flashback 時光機

✅ 監控多重訊號以進行自動偵測

✅ 透過硬體加速和多執行緒最佳化

✅ 將所有內容封裝 為標準檔案格式

重點摘要：

持續寫入磁碟 — 資料從第一秒起就是安全的；崩潰最多遺失幾秒
壓縮不可或缺 — 沒有壓縮，檔案將極為龐大
硬體加速有助益 — 將工作卸載至 GPU
Flashback 使用 RAM 緩衝區 — 快速循環儲存
自動偵測是模式匹配 — 多重訊號加權
編解碼器很重要 — H.264 通用，H.265 高效
DRM 無法錄製 — 技術與法律限制

技術術語簡化：

編解碼器 = 壓縮方法
容器 = 檔案格式盒子
幀 = 影片中的單一影像
取樣 = 音訊波的快照
位元率 = 每秒資料量
緩衝區 = 暫存記憶體儲存
延遲 = 動作與錄製之間的延遲

本章檢查清單

繼續之前，您應該了解：

螢幕捕獲的運作方式（幀擷取）
為何壓縮是必要的（檔案大小的數學）
持續寫入磁碟如何保護您的錄製
Flashback 的循環緩衝區如何運作
五種自動偵測訊號
容器與編解碼器的區別
硬體加速的作用
為何某些內容無法錄製

技術知識已習得！ 🔧 您現在了解了 SeaMeet 背後的魔法。