Cosrod 本地影片壓縮工具實測：不上傳是真的，無損不是

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

打開 tools.cosrod.com，頁面只有一句話的承諾：把影片拖進來，壓縮全程在你的裝置上進行，不會把任何資料送到伺服器，而且是無損壓縮。我實際丟了兩支測試影片進去跑完整流程，把輸出檔案抓回來逐影格比對，順便側錄了全程的網路連線。結果可以用一句話總結：它的兩個招牌宣稱，一個站得住，一個站不住。影片不出你的瀏覽器這件事，在連線紀錄、頁面程式碼、引擎檔案來源三個層面都查得到證據；「無損」兩個字則被它自己寫死的壓縮指令推翻，那條指令用的是有損編碼，品質參數固定在中庸的出廠預設值。

還有一個頁面上沒寫的線索：壓出來的檔案，檔名尾巴會被加上 _rotato 後綴。我原本輸入的檔案叫 input-highbitrate.mp4，下載回來變成 input-highbitrate_rotato.mp4。這六個字母對應到另一個英文工具 Rotato 的線上影片壓縮器，對照之後會發現一件有意思的事：原版工具的文案寫的是「無明顯可見的畫質損失」，精簡成中文單頁的這一版，措辭升級成了「無損」。這一升級正是你使用任何壓縮工具前該學會自己校準的文案距離。

它在瀏覽器裡跑一條寫死的 FFmpeg 指令

Cosrod 的做法屬於近幾年常見的「瀏覽器本地工具」路線：把開源的影片處理引擎 FFmpeg 編譯成 WebAssembly，讓它直接在你的瀏覽器分頁裡執行，影片從頭到尾不離開本機。它的引擎檔案放在自己網域的根目錄，我實際抓下來的完整副本是 32,718,323 位元組，約 33MB，並且確認這個檔案能在瀏覽器裡正常跑起壓縮。這也表示第一次使用有個固定成本：引擎下載完成前，頁面上的選檔按鈕會停在載入狀態，而這個檔案的下載速度隨時段浮動很大，急用的話要預留時間。

Pin

真正決定輸出品質的，是頁面程式碼裡寫死的那條壓縮指令。把它從 JavaScript 裡還原出來是這樣：

ffmpeg -i 輸入檔 -threads 2 -c:v libx264 -tag:v avc1 -c:a copy
       -movflags faststart -crf 23 -preset veryfast -progress - -v "" -y 輸出檔

幾個參數翻成白話。libx264 是 H.264 編碼器，在這條指令裡跑的是有損模式，丟掉畫面資訊換取體積，這是整條指令的核心。crf 23 是品質旋鈕的位置，數字越小畫質越好、檔案越大，23 正好是 x264 的出廠預設值，中庸但不頂級。preset veryfast 用偏快的編碼路徑換速度，代價是同樣 CRF 值之下檔案會比慢速 preset 更大一些。-c:a copy 把音訊軌原封不動複製過去，這部分才是真正的無損。faststart 把檔案開頭資訊搬到前面，方便網頁邊下載邊播放。-progress - 把輸出大小即時報給介面，結果卡上那個 0.8MB 就是這樣來的；-v "" 關掉編碼器的雜訊輸出。-threads 2 固定用兩條執行緒。

對使用者影響最大的一點：這條指令完全沒有暴露任何調整空間。頁面上沒有畫質選項、沒有目標大小、沒有編碼器選擇，你能做的只有拖檔案進去、等進度條、按下載。所有影片走同一條配方，無論你是要傳訊息的隨手拍，還是想幫成品影片瘦身。

兩支測試影片的實測結果：縮小是真的，逐影格比對有損也是真的

我準備了兩支 8 秒、640×360 的測試影片，畫面用 FFmpeg 的測試圖樣產生，聲音是固定的 440Hz 音。兩支的差別在肥瘦：一支用 CRF 12 編碼，刻意保留高位元率，模擬錄影軟體直出的肥檔；另一支用 CRF 22 加 medium 速度編碼，模擬已經被壓縮得比較有效率的檔案。兩支都完整跑過 Cosrod 的流程，結果如下：

縮小是真實的：肥檔砍掉超過一半體積，對「這支影片太大傳不出去」的情境就是最直接的解法。而畫質損失也是真實的：我把輸出和原片丟回 FFmpeg 做逐影格的 PSNR 比對，兩次結果都在 42dB 上下。PSNR 衡量的是兩個影格之間的像素差異，如果壓縮真的無損，輸出解碼後應該與原片完全相同，比對結果會是無限大；42dB 是「肉眼通常看不出差別、儀器看得出」的量級，與 CRF 23 的預期表現吻合。音訊軌則在兩次測試中都與原檔位元組級相同，驗證了 -c:a copy 的行為：畫面被重壓一輪，聲音原封不動。

兩支測試檔的對照還給了一個實用讀數：輸入檔愈肥，省得愈多；輸入檔本來就壓得有效率，省幅會收斂到兩成上下。這不是 Cosrod 特有的行為，是固定配方有損重壓的普遍數學：它的 CRF 23 目標是「畫質看起來差不多」，你的檔案如果本來就低於這條線，重壓一次能擠出的空間有限。判斷自己檔案屬於哪一邊有個粗略參考：手機夜拍、錄影軟體直出、高幀率螢幕錄影通常偏肥；從社群平台下載回來的影片通常已經很瘦，再壓一次的意義不大。

Pin

8 秒的 640×360 小檔不等於長影片或高解析度的表現，兩支測試檔也都被壓小了，輸出反而變大的情境沒有被觸發。不過程式碼裡確實沒有「輸出比輸入大就保留原檔」的防護，縮小百分比直接用兩個檔案大小相除計算，檔案已經很有效率時數字會自己說話，下載前看一眼再決定。

「無損」與 CRF 23 之間的距離，就是行銷與參數表的距離

無損壓縮在技術上有明確定義：解開之後要能還原出與原始資料完全相同的每一位元，例如 ZIP 壓縮文件那樣。影片世界裡真正的無損轉檔存在，但輸出檔案通常不會小多少，因為影片本來就靠有損編碼才壓得動。所有把影片縮小一半以上的工具，走的有損路線都一樣：拿人眼不敏感的細節換體積。差別只在換掉多少、換得多聰明。

CRF 正是那個「換掉多少」的旋鈕。x264 的常用範圍在 18 到 28 之間，18 接近視覺上難以分辨、28 明顯可感；Cosrod 選的 23 是官方預設值，搭配追求速度的 veryfast，這是一條「多數人看不出問題」的安全配方。對它的目標情境，傳訊息、上傳社群、清出硬碟空間，這個選擇其實合理，因為那些管道多半還會再壓一次，你壓得再講究也會被平台重壓蓋掉。真正該介意的是兩種人：手上是唯一母帶或婚禮影片這種要長期保存的檔案，以及之後還要再剪輯的素材。有損重編碼的損失會世代累積，同一支影片每轉一次手就掉一階，剪輯軟匯出、上傳平台轉碼、再被工具壓一次，三輪之後的畫質與原始檔的距離，比任何單次 42dB 都遠。要保存母帶，正確做法是保留原始檔不動，只另外產出一份傳閱用的壓縮版，Cosrod 這類工具適合扮演後者。

所以比較誠實的讀法是：把頁面上的「無損壓縮」翻譯成「多數情況下看不出差別的壓縮」。它做得到後者，做不到前者。順帶一提，輸出檔會保留原本的副檔名，IMG_1234.mp4 進去、IMG_1234_rotato.mp4 出來，副檔名照舊，影像軌已經換過一輪。

「不上傳」這半邊：三個層面都查得到乾淨證據

隱私宣稱的驗證我做了三層。把頁面載入的全部七個 JavaScript 檔案抓下來掃描，沒有任何上傳端點、沒有第三方分析追蹤器的蹤跡，壓縮流程相關的程式碼裡連一個對外請求都沒有。實際跑壓縮時側錄全程連線，兩次完整流程發出的請求只有載入頁面本身、同網域的靜態資源，以及一個瀏覽器內部的 blob 讀取，影片資料沒有任何一刻離開本機。引擎檔案也自架在 tools.cosrod.com 自己的網域下，而非第三方 CDN 上的現成副本，這個安排讓「處理發生在哪裡」的答案更單純。

行為層還有一個技術佐證：伺服器回應帶著 cross-origin-embedder-policy: require-corp 和 cross-origin-opener-policy: same-origin 這兩個特殊的跨源隔離標頭。它們是多執行緒 WebAssembly 需要的環境條件，一般網站不會沒事加這兩個；頁面程式裡也找得到多執行緒載入失敗時自動退回單執行緒的提示文案，兩邊互相印證了「引擎真的在你的瀏覽器裡跑」這件事，並且用上了多執行緒加速。

閉源網頁工具能驗證的是今天的行為，今天的連線乾淨、今天的程式碼沒有上傳端點，不等於未來版本保持一樣。頁面甚至沒有隱私政策可以對帳，這點下一節會講。就現況而言，這個工具在隱私這一側的誠實度，高於多數掛著類似標語的線上工具。

檔名裡的 _rotato：這套程式碼的另一個主人

回到開頭那個線索。輸出檔名固定加上 _rotato 後綴這件事，在 Cosrod 的頁面程式裡是寫死的邏輯，而同樣的檔名產生器、同一族群的指令骨架，出現在 Rotato 線上影片工具目前的生產程式碼裡。Rotato 是一款做 3D 裝置模型展示的應用，它的線上工具站提供壓縮、轉檔、加速、剪輯、裁切、字幕等十幾種影片功能，壓縮器只是其中之一。這個中文單頁用上的，是與 Rotato 壓縮器同一套檔名產生器與同一族的指令骨架，界面精簡到只剩拖放和下載。

兩相對照，升級的是畫質宣稱：

原版對畫質的說法是「看不出損失」，這是可驗證且與 CRF 路線相符的誠實措辭；中文精簡版把它升級成「無損」，剛好跨過了技術上站不住的那條線。至於兩邊的授權關係是取得授權、改寫或另有出處，外部無從判斷，這裡只陳述指紋本身。對讀者來說，這個對照真正有用的是它示範了文案如何在轉手之間升級：工具還是那個工具，承諾變大了。下次看到「無損」「零損失」「原畫質」這類字眼，先找它有沒有公開參數，沒有的話就當形容詞讀。

33MB 引擎、中國 CDN 與不存在的條款頁

把體驗相關的事實集中列一下。第一次造訪要先下載約 33MB 的引擎檔，這段時間按鈕會顯示載入中，下載速度取決於它背後的 CDN 節點：回應標頭顯示網站架在中國的物件儲存與 CDN 上（阿里雲 OSS 的指紋加上崑崙快取節點），我實測同一條網路不同時段差異明顯，快的一次約 28 秒傳了 25MB，慢的一次兩分鐘只收到不到 1MB，就我測試當天的經驗，台灣讀者尖峰時段要有心理準備。站方身分只出現在頁尾與原始碼的 meta 標記：一家杭州公司與浙ICP備案號，加上一個微信公眾號圖片當聯絡管道，頁面上沒有服務條款、沒有隱私政策、沒有關於頁，常見的條款與聯絡頁面全部不存在。這不代表它不可信，但代表你對它的任何期待都沒有書面依據，工具好用是現狀，不是承諾；一個連隱私政策都沒有的網站，它的隱私承諾只能靠行為驗證，這也是前面花那麼多篇幅側錄連線的原因。

功能面上，檔案選擇器接受所有影片格式，程式裡留有「部分機型暫不支援手機壓縮，請至電腦上壓縮」的提示，會在引擎載入失敗時出現，多執行緒失敗時也會提示已自動切換單執行緒。沒有帳號系統、沒有廣告、沒有收費欄位，整站就是一個按鈕和一張圖，商業模式從外部完全看不到，這在免費工具裡反而少見。

肥檔直接進，母帶別讓它碰

這個工具的真實樣貌是：一個把 FFmpeg 固定配方裝進瀏覽器、隱私行為經得起檢驗、但文案借了「無損」兩個字的單頁壓縮器。手上是肥檔、用途是傳出去或清空間、不想安裝軟體的人，它值得直接用，53.7% 的實測縮幅就是它的價值。相對地，要長期保存母帶或再剪輯素材的人，別讓固定 CRF 23 的重編碼碰你的檔案，本機的 FFmpeg 或 HandBrake 這類轉檔工具可以自己指定參數，FFmpeg 還能做真正無損的封裝重排。

幾條替代路線按需求分。想要開源、能自己審計程式碼的人，compress.lol 是 Apache-2.0 授權的瀏覽器壓縮器，原始碼在 GitHub 上公開；需要壓縮以外的影片功能，Rotato 的線上工具一併提供轉檔、剪輯、字幕等十幾種；經常處理各種檔案格式的人，Filee 這類本地檔案轉換工具和線上檔案轉換器各有利弊，隱私優先就選強調本地處理的；至於壓完之後要把檔案送到別台裝置，LocalSend 的點對點傳輸同樣不經過雲端。

常見問題

它真的不會把我的影片上傳嗎？

就我側錄的兩次完整壓縮流程，連線紀錄只有載入頁面與同網域靜態資源，影片資料全程留在瀏覽器裡，頁面程式碼裡也掃不到任何上傳端點。閉源工具的保證上限就是「今天的行為乾淨」，無法涵蓋未來的版本變動。

「無損」到底損了什麼？

影像軌被 libx264 以 CRF 23 重新編碼，逐影格比對 PSNR 約 42dB，肉眼通常看不出差異但資料確實被丟掉一輪；音訊軌是位元組級複製，這部分真無損。

第一次使用為什麼等很久？

壓縮開始前瀏覽器要先下載約 33MB 的引擎檔案，這是它跑在本地而不上傳的代價，若瀏覽器快取生效，之後就快了。

手機能用嗎？

部分機型會被提示改用電腦，程式裡也留有多執行緒失敗自動退單執行緒的訊息，主要使用場景還是桌面瀏覽器。

壓縮工具的選擇題最後通常回到同一個問題：你要的是「看不出的差別」還是「每一位元都在」。Cosrod 給的是前者，並且在隱私上把該做的都做了；只是它掛在門口的招牌，寫的是後者的名字。照它的隱私宣稱放心用，照它的參數而非文案預期畫質，這個工具就會是個誠實的好用工具。