軟體螢幕錄影原理：為什麼直播串流
1.3 音訊擷取：系統音與麥克風的混音邏輯
螢幕錄影不只是畫面，聲音同樣重要。多數軟體會同時擷取「系統播放音」與「麥克風輸入」，並將兩者混音。在 Windows 上，系統音可以透過 WASAPI loopback 擷取；在 macOS 上則需要虛擬音效裝置（如 BlackHole）才能錄到系統音；Linux 則透過 PulseAudio 或 PipeWire 的 monitor source 來達成。
混音聽起來簡單，但實際上牽涉到時鐘同步問題。畫面與聲音來自不同的硬體時鐘，如果沒有做好同步，錄出來的檔案就會出現「嘴型對不上聲音」的現象。好的錄影軟體會透過時間戳記（timestamp）與緩衝隊列來校正，這也是為什麼有些免費軟體錄久了會慢慢出現影音不同步。
二、從錄影到直播：為什麼「串流」是錄影技術的極限挑戰？
如果說螢幕錄影是「把畫面存下來」，那麼直播串流就是「把畫面存下來，同時還要即時傳出去」。這多出來的一步，讓整個技術難度上升了一個檔次。錄影可以容許短暫的卡頓，因為資料最終會寫入硬碟；直播卻不能，因為觀眾端是即時播放，任何延遲、掉幀、緩衝不足都會直接被看見。
2.1 編碼器扮演的關鍵角色：H.264、H.265、AV1 與硬體加速
無論錄影或直播，畫面都必須經過壓縮，否則檔案或頻寬都無法承受。現今最常見的視訊編碼格式是 H.264（AVC），它在壓縮率與相容性之間取得不錯的平衡，幾乎所有平台與瀏覽器都支援。新一代的 H.265（HEVC） 壓縮效率更好，但專利授權複雜，瀏覽器支援度較差；AV1 則是免權利金的開放格式，壓縮效率優異，近年來在 YouTube 與 Twitch 上逐漸普及，但即時編碼的硬體支援仍在發展中。
編碼可以透過 CPU 軟體編碼（如 x264）或 GPU 硬體編碼（如 NVIDIA NVENC、AMD AMF、Intel Quick Sync）來完成。軟體編碼畫質通常較好、參數調整彈性大，但非常吃 CPU；硬體編碼則把工作丟給顯示卡上的專用電路，CPU 佔用極低，適合直播這種需要同時處理遊戲與推流的场景。
這也解釋了一個常見現象：錄影時你可以用軟體編碼慢慢壓，直播時卻必須用硬體編碼換取即時性。如果你在直播時堅持使用 x264 的 slow preset，很可能遊戲幀數暴跌、編碼器過載，最後觀眾看到的是一格一格的幻燈片。
2.2 即時性與延遲：緩衝、丟幀與自適應碼率
直播串流的第二大挑戰是「即時性」。錄影時，軟體可以先把畫面暫存在緩衝區，等 CPU 有空再慢慢編碼；直播時，畫面必須在極短時間內完成「擷取→編碼→封包→傳送」，任何一個環節變慢，都會累積成延遲。
為了應付網路波動，串流軟體會設定緩衝區（buffer）。緩衝區越大，越能吸收網路抖動，但延遲也越高；緩衝區越小，延遲越低，但網路一不穩就容易掉幀。這就是為什麼有些實況主會強調「低延遲模式」，因為他們需要在與觀眾互動時保持即時感。
此外，直播還涉及自適應碼率（adaptive bitrate）。當網路頻寬不足時，編碼器會動態降低位元率，避免畫面完全卡死；但降太多會導致畫面模糊、出現方塊。好的串流軟體會根據網路狀況與編碼器負載，自動調整解析度、幀率與位元率，這背後的演算法其實相當複雜。
2.3 推流協定：RTMP、SRT、WHIP 的取捨
畫面編碼完成後，必須透過協定推送到伺服器。長年以來，RTMP（Real-Time Messaging Protocol） 是直播界的標準，幾乎所有平台都支援。RTMP 基於 TCP，傳輸穩定，但延遲較高，且不支援現代瀏覽器直接播放（需要轉封裝為 HLS）。
SRT（Secure Reliable Transport） 則是近年崛起的協定，基於 UDP，能在不穩定網路上提供更好的容錯與更低延遲，適合遠端採訪或網路品質不佳的場景。WHIP（WebRTC-HTTP Ingestion Protocol） 則是新興標準，主打超低延遲，讓瀏覽器可以直接推流，被視為未來直播的重要方向。
對一般使用者而言，這些協定的差異可能只表現在「延遲幾秒」與「容不容易斷線」上；但對軟體開發者而言，選擇哪種協定，直接決定了整個串流架構的複雜度。這也是為什麼專業直播軟體往往同時支援多種協定，讓使用者依場景切換。
三、軟體評測：錄影軟體與直播工具的效能實測框架
理解了原理之後，我們可以用更系統化的方式評測一套螢幕錄影或直播軟體。以下幾個指標，是筆者實際測試時會特別關注的重點。
3.1 評測指標：CPU／GPU 佔用、掉幀率、畫質與延遲
第一個指標是系統資源佔用。好的軟體應該在錄製 1080p60 時，將 CPU 佔用控制在合理範圍，並盡量利用硬體編碼。你可以用工作管理員或效能監視器觀察，若 CPU 長時間滿載，代表軟體可能在使用效率較差的擷取或編碼方式。
第二個指標是掉幀率（dropped frames）。幾乎所有錄影軟體都會顯示「因編碼器過載而掉幀」或「因網路問題而掉幀」的統計。錄影時掉幀代表檔案不流暢；直播時掉幀代表觀眾看到畫面停頓。理想情況下，掉幀率應該維持在 0%。
第三個指標是畫質。這很難量化，但可以透過固定位元率錄製高動態場景（例如遊戲快速移動、簡報切換），觀察是否出現明顯方塊、模糊或色彩斷層。硬體編碼在低比特率下的畫質通常略遜於軟體編碼，但新一代 NVENC 與 AV1 已大幅改善。
第四個指標是延遲。直播延遲可以透過「對著鏡頭比手勢，觀察畫面延遲幾秒」來粗略測量。一般 RTMP 直播延遲約 2 到 10 秒，低延遲模式可壓到 1 到 3 秒，WHIP 則有機會低於 1 秒。
3.2 常見工具橫向比較：OBS、Bandicam、ScreenPal、內建工具
OBS Studio 是目前最主流的開源直播與錄影軟體。它支援多種擷取來源、場景切換、濾鏡與外掛，幾乎什麼都能做。缺點是設定項目多，新手需要花時間學習；此外，若沒有正確設定硬體編碼，很容易出現掉幀。
Bandicam 是老牌螢幕錄影工具，主打遊戲錄製與高壓縮率。它的介面直覺，支援硬體加速，錄影品質穩定。不過直播功能相對陽春，較適合以錄影為主的用戶。
ScreenPal（原 Screencast-O-Matic） 則偏向教學與簡報錄製，提供簡單的剪輯與分享功能，適合不需要複雜直播設定的使用者。它的擷取效率不如 OBS 靈活，但勝在操作簡單。
Windows 內建剪取工具與 macOS 快速鍵錄影則是最輕量的選擇。它們使用系統原生擷取介面，資源佔用低，但功能有限，不支援直播推流，也不適合長時間錄製。
整體而言，如果你要直播，OBS 幾乎是首選；如果你只偶爾錄製教學影片，內建工具或 ScreenPal 就足夠；如果你追求遊戲錄影的便利性，Bandicam 仍有其價值。
3.3 硬體與情境的匹配建議
評測軟體時，不能脫離硬體環境。以下提供幾個實務建議：
四、實務應用與常見迷思
理解原理之後，我們可以回頭解答一些常見的疑問，並提醒幾個容易被忽略的實務細節。
4.1 為什麼錄影很順、直播卻卡？
這是最常見的問題。原因通常有三個：第一，編碼器負載不同。錄影時你可以用較慢的 preset 換取畫質，直播時卻必須用即時 preset，若設定不當，編碼器就會過載。第二，網路頻寬不足。錄影只看硬碟寫入速度，直播卻要看上傳頻寬與網路穩定度。第三，緩衝策略不同。錄影可以大量緩衝，直播卻必須在延遲與穩定之間取捨。
解決方式包括：改用硬體編碼、降低直播解析度或幀率、提高位元率上限、關閉不必要的背景程式，以及確認上傳頻寬是否足夠（建議至少為直播位元率的 1.5 倍）。
4.2 版權、隱私與倫理
螢幕錄影與直播也牽涉到法律與倫理問題。錄製線上課程、電影、音樂或遊戲畫面，可能涉及著作權；直播時若不慎拍到他人肖像、聊天室內容或個人資料，也可能觸犯隱私規範。建議在錄影或直播前，先確認內容的授權狀態，並避免在畫面中露出敏感資訊。
此外，部分平台對於「重播」與「二次創作」有不同規範，創作者應詳閱平台條款，以免帳號受罰。這些雖然不是技術問題，卻是每一位內容創作者都應該具備的基本認知。
結語：錄影是基礎，直播是綜合實力的展現
從畫面擷取、記憶體搬運、編碼壓縮，到推流協定與網路傳輸，螢幕錄影與直播串流其實是一條完整的技術鏈。錄影讓我們可以把畫面保存下來，直播則要求這條鏈上的每一個環節都必須即時、穩定、高效。這也是為什麼「錄影很順、直播卻卡」不是軟體壞掉，而是直播本來就是一項對系統綜合實力的考驗。
下次當你打開 OBS 或任何錄影軟體時，不妨多留意一下它的擷取方式、編碼器設定與掉幀統計。理解原理，不只能幫你解決問題，也能讓你在選擇工具時更有判斷力。畢竟，好的內容值得被順暢地記錄與分享，而這一切，都從理解「畫面是怎麼被抓住的」開始。