一個聚合播放器的技術觀察 —— Cinetry 為什麼能同時對付五種媒體源

Cinetry 是什麼

Cinetry 是一款跑在 Android 上的聚合播放器，目前版本 0.5.2，安裝包 63.26M。它不自己提供任何影片資源，而是把别人已經搭好的媒體服務接進來，在同一個介面裡播放。具體來說，它能同時對付 Jellyfin、Emby、Webdav、Alist、IPTV、蘋果 CMS，以及任何能通過 Webdav 協議暴露的网盘目錄。

這聽起來沒什麼稀奇——市面上聚合播放器不少。Cinetry文檔 裡對每個接入的媒體源都有詳細的設定說明。但我真正在意的問題是：這些服務的 API 形態、媒體結構、播放協議完全不同，Cinetry 是怎麼把它們揉進同一個播放體驗裡的？ 為什麼它接 Jellyfin 時有播放進度同步，接 Webdav 時又能自動識別 .nfo 刮削文件和字幕，但接 IPTV 時卻只有單純的頻道列表？這三種連接模式背后對應著三種截然不同的架構選擇，而 Cinetry 在這個維度上的取捨，基本決定了它的優勢與邊界。

安裝

Cinetry下載 只有 Android APK 一個發行渠道，安裝包 63.26M，相比同類播放器體積偏大，原因是它把三個不同的硬解內核（MDK、EXO、AVP）都打包了進去。首次安裝允許時，系統會彈出「未知來源」放行提示——這是 Android APK 的標準流程，沒有額外坑。

安裝完打開之後，有兩件事是必須在初次進入播放頁之前做完的：第一，進入播放器設定，在「解碼器內核」裡選一個適合自己手機的硬解核心。三個內核裡，MDK 兼容性最好但在低端機上容易卡 4K HDR；EXO 是 Google 自家的 ExoPlayer，新裝置支援好；AVP 針對特定品牌優化。這個選擇直接決定了你後面看高碼率影片時會不會掉幀花屏——裝完先試跑一段 4K HEVC，卡了就換內核，總比看完半小時才發現內核選錯好。

第二，如果你手機裡有舊版 Cinetry 殘留，建議先在系統設定裡清掉應用資料再裝。舊版本（0.4.x 以前）的資源庫快取格式與 0.5.x 不兼容，直接覆蓋安裝可能導致已接入的資源庫全部遺失，而且無法從備份恢復——這個坑在論壇上出現過不止一次。

三層連接架構：API、文件、直播

Cinetry 對不同媒體源的處理方式，歸根結底是三層互相獨立的連接邏輯。每一層都有自己的資料結構假設、播放流程和元數據來源，層與層之間互不依賴——這是它能同時支援那麼多協議的核心原因。

第一層：API 驅動的結構化媒體庫

Jellyfin 和 Emby 走的是這一層。這兩個服務都提供完整的 REST API，可以查詢媒體庫的電影列表、劇集季節、每集元數據，甚至包括海報、評分、簡介。Cinetry 對它們的接入參數只有四個：資源庫名稱、連接地址（IP + 端口）、賬號和密碼。連接成功後，Cinetry 會通過 API 拉取完整的媒體庫結構，然後在本地渲染成分類頁面。

這一層最聰明的設計是播放進度的雙向同步。Cinetry 在每次播放暫停或結束時，會自動調用 Jellyfin/Emby 的 Session API，把當前進度回寫到服務器。這意味著你在手機上看到第 3 集第 15 分鐘，換到電腦上打開官方客戶端，會從第 16 分鐘接著放——反過來也一樣。這不是什麼新技術，但 Cinetry 的實現乾淨：它不緩存進度、不做衝突合併，完全信任服務器端的狀態。代價是每次暫停都會產生一次 HTTP 請求，網絡不好時會有延遲，但在家庭區域網裡幾乎感覺不到。

第二層：文件系統掃描與刮削文件識別

Webdav、Alist、OpenList 走的是這一層——這些服務沒有媒體庫 API，只暴露文件和目錄。Cinetry 的做法是：通過 Webdav 協議遞歸掃描目錄，把所有視頻文件收集起來，然後在每個視頻文件所在目錄裡尋找刮削產物：.nfo 元數據文件、poster.jpg、fanart.jpg、.srt 字幕等等。

這一層的關鍵假設是：你的目錄結構必須符合刮削規範。電影一部一個目錄，劇集一季一個子目錄，否則 Cinetry 無法把視頻文件和對應的海報、字幕關聯起來。Alist 和 OpenList 的接入還有一個專屬坑——連接地址必須在端口後面加 /dav 路徑，否則 Cinetry 會掃不到任何文件。這個細節在 Cinetry官網 的文檔裡寫了，但新手第一次接大概率會踩。

我打個比方：第一層（API 模式）像是圖書館的卡片目錄——你要什麼書，直接按編號查；第二層（文件掃描）像是自己家的書架——書怎麼放、有沒有書簽，全看你之前有沒有好好整理。

第三層：直播流與純播放

IPTV 和蘋果 CMS 走的是這一層。它們的本質是一個頻道列表或播放源列表，Cinetry 只需要拿到清單然後逐個播放。這一層沒有媒體庫概念、沒有元數據、沒有進度同步——就是打開、選頻道、看。這也是 Cinetry 架構裡最薄的一層，幾乎不做額外處理。

本地硬解引擎：三內核並行的權衡

說完連接層，再說播放本身。Cinetry 在 Android 上提供三個硬解內核：MDK、EXO、AVP，用戶可以手動切換。這個設計的底層邏輯是：沒有哪個單一內核能在所有設備上表現完美。比如 MDK 在驍龍 8 系列上對 H.265 的兼容性最好，但在聯發科天玑上反而 EXO 更穩；AVP 對某些品牌手機（比如 vivo）的自適應動態範圍（ADR）格式有專門優化。

代價是體積變大——三個內核加上各自的 so 庫，63.26M 的安裝包比只打包一個內核要大 20M 以上。但這個權衡是合理的：如果只打包一個內核，勢必有相當比例的用戶到手就遇到硬解花屏，然後不得不切回軟解，浪費了硬解存在的意義。

關於硬解還有一個常見陷阱值得專門提一句：4K HDR 10bit 以上、碼率超過 80Mbps 的影片，即使編碼格式硬解支援，GPU 也可能因為壓力過大而降頻，導致掉幀卡頓。這時候有兩條路：要麼關掉硬解讓 CPU 軟解（1080p 以下軟解完全沒壓力），要麼讓服務器（Jellyfin/Emby）端轉碼後再推流。硬解不是萬靈丹。

適合與不適合

說完架構，回答最開始的問題：Cinetry 適合誰、不適合誰？

適合的場景很明確：你已經有一套 Jellyfin 或 Emby 媒體服務器，或者你花了不少時間整理本地影片、掛了 Alist/OpenList 當後端——Cinetry 讓你在手機上用一個 App 同時接這幾套源，而且進度同步、刮削文件識別這些細節都做到位了。如果你有多台裝置（手機、平板、電視盒子），進度雙向同步尤其好用。

不太適合的場景也有：你手裡只有一堆散亂的 APK 或 BT 下載的影片文件，沒有搭服務器、沒有整理過目錄、也沒有刮削過元數據——這種情況下 Cinetry 能播，但你得到的體驗不會比任何一個普通檔案管理器好多少，它的優勢根本發揮不出來。另外，iPhone 用戶只能用瀏覽器訪問文檔站，沒有 iOS 客戶端，這也是 Android APK 獨發帶來的天然限制。

最後提一個我認為最重要的邊界：Cinetry 的資源庫導出功能目前只支援蘋果 CMS 和 IPTV 兩種類型，Jellyfin、Emby、Webdav 這三種需要賬號密碼的資源庫不能導出分享——理由很直白，安全考慮。但反過來想，這也意味著如果你換了手機，Jellyfin/Emby 類型的資源庫需要一個一個重新填參數，雖然麻煩但至少連接參數本身不複雜。

結語

聚合播放器這個品類發展到今天，能活下來的產品幾乎都在「支援多少種協議」上卷過一輪。Cinetry 沒有走「支援越多越好」的路，而是把支援的每一種都做透：API 層做進度同步、文件層做刮削識別、硬解層做三內核並行。它的優勢是深度而非廣度——如果你剛好處於它的優勢區間（有服務器、有整理過的媒體庫），用起來確實省心；如果不在這個區間，它和其他播放器相比也不會好太多。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。