開源影片翻譯配音工具 EasyVideoTrans，官網熄燈後只剩自架一條路

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2026 年 10 月在瀏覽器輸入 easyvideotrans.com，等到的不是影片翻譯工具，而是一個 301 轉址：目的地 gruz-odpady.pl，落地頁的標題是波蘭文的 Vavada 賭場行銷文案。這個曾經把「最快的英文影片轉中文方案」掛在官網首頁的開源專案，線上服務與開發都已經落幕，連域名都被行銷產業回收再利用了。

先給結論：EasyVideoTrans 的前後端兩個儲存庫在 2026 年 6 月 7 日被開發者封存為唯讀，不會再有修復與更新；Docker Hub 上的四個官方映像到今天仍然拉得到，程式碼也在。想再用它，只剩把整套 GPU 管線自己架起來這一條路，而這條路的硬體與維護門檻，跟它當年標榜人人都能上手的定位，距離相當遠。一個在 GitHub 上累積近 500 顆星的專案，就這樣在半年內走完了從故障到消失的全程，中間沒有留下任何告別公告。

Pin

五個時間點，還原一個開源服務的落幕

時間往回撥到 2025 年 11 月 5 日與 6 日。後端儲存庫在 11 月 5 日合併了最後一個功能：ARM 架構支援，前端在隔天跟進，Docker Hub 的映像也在同一天完成最後更新。從提交紀錄看，這不像苟延殘喘的專案。再往前攤開整條開發史，節奏是波段式的：2024 年 4 月開張，2025 年 2 月完成微服務化改造並附上 Kubernetes 部署文件，沉潛半年後，8 月回來補了套件管理現代化與 OpenAI 語音選項，10 月與 11 月各有一輪修補。每一段都有實質產出，直到 2026 年 1 月那聲基礎設施故障為止。

2025 年 12 月 30 日，有使用者在 issue 回報背景音訊分離開始固定失敗，以前都正常；2026 年 1 月 7 日，維護者留下他在此專案的最後一次公開回覆，大意是自己架設的基礎設施大概掛了，週末再看看。那個週末之後，issue 區再也沒有出現維護者的任何發言。

2026 年 4 月 13 日，網頁存檔服務最後一次捕捉到這個官網的正常內容，首頁仍是那套行銷文案：GPU 加速轉換、所見即所得的網頁介面。值得一提的是，從 2025 年 11 月到這一天，歷次快照的頁面大小與結構幾乎一致，多個月份的快照內容彼此相同，網站本身早已停止實質更新。4 月 13 日之後，存檔紀錄歸零。

Pin

2026 年 6 月 7 日，前後端儲存庫同一天被擁有者封存，GitHub 頁面掛上唯讀橫幅。最後一個時間點就是現在：域名轉手給波蘭文的賭場行銷頁，精確的接手日期無從查起，只能框在 2026 年 4 月 13 日之後、10 月上旬之前。

Pin

這條時間線對三種人有不同意義。曾經用過線上版的人，服務是在無預警狀態下消失的，沒有公告、也沒有留給使用者匯出資料的緩衝期；按舊教學文連往官網的人，現在點進去會撞上賭場頁，任何還連向 easyvideotrans.com 的文章與書籤都已失效；至於本來就自架的人，儲存庫變唯讀的影響最小，程式碼可以 fork，只是從此要自己扛全部維護。

它原本做什麼：一條五站式的影片翻譯產線

EasyVideoTrans 處理的任務很明確：把一段英文影片，變成保留背景音、配上中文旁白的影片。攤開原始碼，整條產線是五個站點串起來的。入口用 pytubefix 下載 YouTube 影片或讀入自備檔案；接著交給 faster-whisper 把英文語音轉成字幕；翻譯這一站的量產配置走 pygtrans，也就是 Google 翻譯的免費端點，程式裡另外備有 DeepL 與 GPT 的翻譯實作；配音靠 edge-tts 這個微軟語音端點的免費套件，原始碼裡的預設聲音是 zh-CN-XiaoyiNeural，簡體中文的曉伊；最後由 vocal-remover 把人聲與背景音分離，配音後重新混音渲染輸出。選型理由作者也留了紀錄：語音轉錄試過 OpenAI 官方的 Whisper 與 stable-ts，以效果不如 faster-whisper 為由淘汰，量產配置從此固定。

它的免費，建立在三層非官方端點上：YouTube 的影片抓取、Google 翻譯的免費介面、微軟 Edge 的語音合成。這三層都是各家官方服務周邊的灰色通道，不改程式碼就不花錢，但也隨時可能因為上游改版而斷線。README 裡的技術選型表格很有意思，作者評估過 GPT-SoVITS、ChatTTS 這批開源語音模型，結論都是輸出不穩定、暫時觀望；OpenAI 的付費語音合成則在 2025 年 8 月才正式整合進來。也就是說，這條產線最倚賴的配音環節，長期以來就是靠微軟的免費通道在撐。

模組化的設計倒是留了人工介入的空間。當年官網主打的使用彈性，是每個步驟都會產出檔案、串接執行，想先人工校對字幕再進配音，隨時可以插手，README 還建議使用者自備一套字幕編輯器備用。對翻譯品質有要求的人來說，這種打開蓋子給你調的設計，比純黑箱的一鍵轉換實際得多，也是這個專案在工程態度上最值得肯定的地方。

至於當年 README 與官網宣稱的線上版可處理最長 60 分鐘影片、全流程一鍵完成，這些是開發者自己的說法，服務已經關閉，效果無從覆核，讀者參考它的架構圖就好。

開源三個字的實際範圍：後端有授權，前端沒有

把它當成開源工具之前，值得先看清授權的實際分布。後端儲存庫 486 顆星，根目錄放著 GPL-3.0 的授權檔，自架、修改、再發佈都有明確依據。前端儲存庫 70 顆星，根目錄沒有任何授權檔，GitHub 的授權欄位是空的；原始碼公開與授權是兩回事，沒有授權檔的法律預設是著作權人保留所有權利。官網頁尾也明寫著版權所有、保留一切權利。

往前追溯還有一段族譜。這個專案的前身是離線命令列工具 pytvzhen，362 顆星，同樣沒有授權檔，2024 年 7 月之後就停止更新。整個產品家族對授權的態度是連貫的：程式大方公開，授權一直沒有補齊。儲存庫裡還有個角落的細節，變更紀錄檔從開張到封存都停在 V0.0.1 初始版本那一行字，版本管理沒有跟上實際的開發能量，這種不拘小節，跟授權檔的缺席是同一種氣味。

對讀者的實際影響：拿後端自架或 fork 改作，GPL-3.0 的義務清楚，衍生作品要沿用相同授權；想拿前端原始碼做二次開發，嚴格說處於未經授權的狀態，商業使用前需要先找到著作權人談，而這個專案已經封存。

自架還可行嗎：原料都在，管線會咬人

儲存庫封存不等於原料消失。Docker Hub 上四個官方映像至今都可下載：主服務 easyvideotrans 累積 581 次拉取、GPU 工作負載 765 次、前端兩個版本合計接近 1,800 次；其中三個映像的最後更新停在 2025 年 11 月，另一個前端舊版更早，停在 2025 年 1 月。程式碼完整、映像在架上，帳面上這條路是通的。

帳面之下有幾個會咬人的地方。硬體門檻先不談哲學，看數字：README 明言作者沒有做 CPU 方案，想跑完整流程必須選 GPU 版；官方的 Kubernetes 部署文件要求叢集裡至少有一個帶 nvidia.com/gpu 資源的節點；GPU 工作容器的記憶體上限設到 25GB，整套系統還需要 RabbitMQ 訊息佇列與 Celery 任務佇列在旁邊陪跑。這是小型機房的規格，跟官方行銷裡那種開瀏覽器就能用的想像，中間隔著一整個機架。

依賴鏈的年紀是另一個會咬人的地方。pyproject.toml 裡 YouTube 下載器 pytubefix 鎖在開發者自己 fork 的 main 分支，沒有跟著社群主流版走，那個 fork 的最後一次推送停在 2025 年 1 月 26 日。YouTube 的抓取介面是出了名的常改常斷，官方版 pytubefix 靠社群持續追著修，凍結的 fork 沒有人追。issue 區的尾聲也印證這件事：2025 年底使用者回報背景音訊分離固定失敗，維護者說自己的基礎設施掛了要週末看看，然後就沒有然後了。翻譯與配音那兩層 Google、微軟免費端點，同樣是上游一改版就可能失效的結構，而修復這件事，已經不會再發生。

部署形狀本身倒是乾淨的。前端是 Next.js 應用，後端位址透過環境變數注入，等於官方前端可以直接指向你自己架的後端；Docker Compose 與 Kubernetes 兩種部署文件都齊備，映像也依角色分成三種。問題從來不是文件或打包，是底下墊著的硬體需求與依賴年紀。

所以答案分兩半。技術上，映像與程式碼都在，有 NVIDIA GPU、願意接手依賴維護的人，今天仍能把產線架起來；由於每個步驟的產出都落地成檔案，半成品的字幕與音軌救得回來，失敗不至於全毀。投資報酬上，這等於認養一條斷了保固的產線：入場免費，後續每一段的維修都算你的。除非你本來就有 GPU 叢集閒著，否則把時間花在還有人維護的方案上，幾乎一定是更好的選擇。

想把英文影片變中文配音，現在可以走哪些路

這個需求本身不會因為一個專案熄燈而消失，拆開看每個環節都還有活著的選擇。要的是完整配音管線的，我們先前整理過的 Linly Dubbing 開源 AI 影片配音 走的是類似的字幕翻譯加語音合成路線，專案仍在活動狀態；只需要把影片轉成逐字稿再自己處理的，YouTube 影片轉文字工具 這類 Whisper 介面最省事；語音合成端，LibreTTS 用的正是與 EasyVideoTrans 同源的微軟免費語音端點，偏好正式管道的可以參考 Azure 語音服務的自架筆記，台灣聲音的呼叫方式整理得很完整；翻譯端要自建的，DeepLX 自架方案 是同一個時代的另一種解法。

差別在於整合度。EasyVideoTrans 的價值是把五個站點接成一條龍，現在這條龍的龍頭已經封存；上述方案多數是單環節的工具，要自己串。願意串的人換到了控制權與可維護性，不願意串的人，可能要等下一個整合型專案出現。也要提醒一件事：依賴免費端點的脆弱性並非 EasyVideoTrans 獨有，任何把 Google 翻譯、微軟語音掛在管線中段的開源專案，都繼承了同樣的單點風險，挑替代品時把這層算進維護成本裡。

授權與專案現況

把目前的狀態逐項整理如下。後端 sutro-planet/easyvideotrans：GPL-3.0 授權，486 顆星，2026 年 6 月 7 日封存為唯讀，issue 區還留著無人回應的故障回報，不會再被處理。前端 sutro-planet/easyvideotrans-frontend：無授權檔，70 顆星，同日封存。前身 pytvzhen：無授權檔，2024 年 7 月後停更。Docker Hub 的 hanfa 命名空間下四個映像仍可拉取，資料截至 2026 年 10 月 7 日。

兩個提醒收尾。網路上凡是出現打著 EasyVideoTrans 名號的新下載頁、新安裝包，都值得先起疑心，正牌官網的域名已經被賭場行銷頁接收，仿冒者缺的只是一個夠像的門面。另外這類封存專案的映像與 fork 狀態都會浮動，幾個月後要引用本文的數字，先回 GitHub 與 Docker Hub 各看一眼再說。