本內容來源於@什麼值得買APP，觀點僅代表作者本人 ｜作者：達文牛
大家Docker常用的jellyfin通常是官方的jellyfin/jellyfin，以及基礎庫支援更完善的Linuxsever/jellyfin，而今天我們將見到目前最強的Nyanmisaka/jellyfin。
說到nyanmisaka，如果大家訪問過github的jellyfin官網，就知道nyanmisaka是官方開發人員。傳說他跟亞塞拜然有點聯絡，也說他是自己人。目前國內各大軟硬體論壇部落格都能看到他的留言，國外論壇上也有不少，一會兒英文，一會兒國語，看得我雲裡霧裡。據我偷看了一眼，貌似此大佬專攻jellyfin硬體編解碼方面，我記得還有好幾個技術方向也看到他的專業提示，不過我最近忘了炒股，損失了好大一筆，精神不佳，導致記憶力衰退，都忘記是哪些領域了。不過，不少官方權威解答，ffmpeg除錯改進，都是此大佬。那麼大佬2個月前也悄悄說過（說這話的論壇轉型關閉了，關閉可真快...眨眼都1個多月了），要做個國內特供版本，免受官方開源限制，直接整合更新的驅動和基礎庫，國內使用者裝上就用，不用再打補丁。。。。現在，他來了。
據nyanmisaka不公開的秘密，他的docker主要強化了核顯驅動、字型檔驅動、ffmpeg最佳化引數以及10.8.0alpha3最新改進和改進還未釋出的各種東東。其實nyanmisaka是有公開宣佈的，但是他是用英文宣佈的，我看不懂。既然影片最佳化上nyanmisaka大佬做了這麼多工作，所以我也希望熱衷硬解的小夥伴們能看到並試用這個版本的jellyfin。畢竟使用的人越多，nyanmisaka就越可能天天幫我們更新，有自己人真好。
如果你擅長於重灌各種Docker版本的jellyfin，請直接跳到後面的章節去看。文章貼圖比較多，為了便於小夥伴快速跳轉，先列出章節：
- 全新安裝 nyanmisaka/jellyfin
- 牛刀小試，改進的轉碼能力與效率
- jellyfin alpha3 幾個小問題
- 新的色調對映演算法
- 最後，很快會再見
全新安裝 nyanmisaka/jellyfin
大家不要被標題全新安裝嚇到了，nyanmisaka是官方開發人員。所以據我測試，nyanmisaka/jellyfin相容以前版本的jellyfin/jellyfin，你可以直接使用jellyfin/jellyfin的配置目錄無損升級。
那麼，這個docker是不是裝上就用呢，我還是要講一講全新安裝一個nyanmisaka/jellyfin。
首先，下載docker，我們還是以群暉為背景，開工。
獲取nyanmisaka版本
如上圖，開啟docker搜尋到nyanmisaka的jellyfin，雙擊下載latest版本。如果網路卡頓的小夥伴們，可以去SSH裡面pull，我們可以複習一下pull指令。
docker pull nyanmisaka/jellyfin:latest
因為nyanmisaka大佬想提供的是即裝即用，所以以上命令列有點違背初衷，下次不再提示。
回顧SSH的閒暇功夫，映像應該下載完畢了，（如果沒有完畢，請再看看SSH.......），我們去為映象啟動一個新容器。
啟動新容器
這裡再複習一下為什麼都推薦選latest版本，因為今後有版本升級，我們直接再次拉取latest版本，等映像更新後，我們停止以前的容器->選擇重置->再啟動，就可以無損升級到最新版本了。是不是感覺很不踏實，這麼容易就升級了？？但是，很愉快吧？
進入高階設定
我們標註1位置填寫容器名稱，標註2位置勾選高許可權以便於我們可以使用硬體解碼，標註3位置啟動資源限制，可以在標註4和5位置進行一下資源限制，最後在標註6位置開啟高階設定。其中2是必須的，1,3,4,5大家隨意，如果你真的很隨意只給jellyfin分配了1MB記憶體，我很想知道結果會。。。。怎麼樣。。。
點選【高階設定】我們要進一步設定。
高階設定啟動
網路模式
儲存空間設定
高階設定裡面建議勾選自動啟動，網路模式選【使用與 Docker Host 相同的網路】，直接使用當前裝置IP和埠。儲存空間這裡，標註1位置，選擇新增資料夾，分別新增 cache，config和media目錄，nyanmisaka的配置目錄與官網的jellyfin/jellyfin相同。實際上，如果你以前有jellyfin官方的docker配置有目錄，你可以直接指向你以前的配置目錄，平滑升級無憂。這個我好像前面提過？。。。太平滑了，不得不再說一次。
標註5位置，我將media目錄設定為只讀，防止jellyfin裡面誤操作刪除媒體原始檔，安全第一。標註6位置為我在NAS裡面對應的目錄，大家目錄不同，你不要說我寫錯了。
配置完成按【應用】回到建立容器介面，點選【下一步】。
摘要顯示
這裡再次確認我們的設定，如果有問題，請不要找我。。。。點選【應用】，馬上開始多媒體之旅。
不得不說，啟動jellyfin可真快，即使我左手點【應用】，右手開網頁，都能馬上開啟jellyfin。其實好像也沒這麼快，我鍵盤上找數字按字母，還帶指甲太長按著老彆扭，先去修理一下指甲。。。。
瀏覽器開啟你的裝置IP地址加上埠號8096。
設定中文
當然選漢語了，奇怪jellyfin官方不是有自己人嗎，怎麼常見的中文這裡是漢語。。。。
配置管理員賬號
這裡需要註冊一個管理員，我就預設root使用者名稱了吧。
新增一個媒體庫
這個可以跳過，但是為了便於演示，我按要求先新增一個媒體庫。
媒體庫設定
我這裡媒體庫只做最簡單的電影類媒體庫演示，還有劇集，音樂，相簿等型別可供選擇，小夥伴可以自行研究，我們會盡快過度到後期的轉碼效果測試，所以這裡僅僅提供電影類媒體庫設定作為參考。標註1位置選電影類，標註2位置取個霸氣點的名字，比如：《最讓人不討厭的電影》，《廁所常用影院》。不過我還是覺得《經典電影》吐槽率高一點，萬一我說經典你說不經典呢，是不是。
標註3位置按【＋】選擇資料夾，就是我們前面【高階設定】裡面設定的那個，如果你忘了是哪個高階設定，那忘了就忘了吧。
媒體庫下載語言和地區，按圖設定一下，今後刮削對應刮削中文。什麼是刮削，這個你可以搜一下。本文不會深入介紹刮削，刮削可能遇到元資料下載器沒法訪問伺服器的故障，這個需要改hosts或自建DNS代理。這個是常見問題，有很多文章介紹。我的解決方案是區域網自定義DNS代理，隨時可以更新，整個內網都能同步更新刮削伺服器地址（api.themoviedb.org的IP時不時就不靈光了，常換常新吧）。但是這個方法有點安全隱患，這裡就不展開了。我預設大家刮削是沒有問題的，甚至是已經預先刮削好。
媒體庫建議選項
標註1位置是10.8.0帶來的新特性，每個媒體庫可以自動收集合集，我暫時把它關了。因為它會自己建了一個名叫合集的媒體庫，更重要的是，因為刮削元資料的原因，它統計的合集並不準確，有時候系列名也不對。想試試的小夥伴可以開啟，預設是勾選上的。元資料下載器這裡，第一個TheMovieDb，就是我們提到的會呼叫api.themoviedb.org來刮削，如果你有未刮削的電影，這個伺服器基本都能刮削出來。第二個 The Open MovieDatabase 預設是勾選的。它可以補充第一伺服器沒刮削到的資料，比如獲取爛番茄的評分。兩個伺服器的優先順序可以用旁邊的上下箭頭調整。
標註2位置是新選項。按照音樂媒體庫的同樣選項解釋，應該是指從電影檔案內嵌的附件提取封面或海報圖片。標註3位置建議取消，是刮削不了海報圖片的時候從影片中擷取畫面。
如果你的電影已經刮削好，建議圖片獲取可以全部取消。
取消圖片獲取方式
即使你的電影已經刮削好，也建議保持元資料下載器的選項，比如你關閉了TheMovieDb，那麼你的演員表頭像和演員資訊，就不會再更新了。
點選【確定】，第一個媒體庫配置完成，【下一個】。
元資料預設選項
這裡提示我們將為後期的媒體庫配置預設語言和地區。
預設遠端訪問
轉碼，當然還有個作用就是外網訪問了，預設是勾選的，點選【下一個】。
完成設定
若干個下一個後，終於有【完成】了，點選後會再次出現登入介面，登入我們的管理賬號進去。
左上角點選進入控制檯
我們觀看電影之前還有點事情要做，那就是設定硬體編解碼。點選左上角，進入控制檯。
控制檯
開啟硬體解碼
我們直接配置個目前官方10.8.0alpha3都不能幹活的配置，如上圖。注意標註5的下方、標註8和標註9這幾個地方出現了新選項。標註2、標註7、標註8這個位置，我們會不同選擇來進行一組簡單的效能對比。這裡先暫時不管，按圖配置就能愉快的轉碼了。
對了，我們先回到媒體庫看看。
已經預設支援中文字型檔
完美，我們沒做任何補丁，媒體庫字型檔已經支援中文，不會顯示框框框框了。如果你的媒體庫沒有出現圖片，請耐心等待它自己自動更新，如果已經更新完成還是沒有顯示圖片和標題，那麼可以選擇手動重新整理，來一波：
手動重新整理媒體庫封面
按照標註順序，執行三步等待重新整理完成。這次出現圖片和中文了吧。
到此，一個全新的jellyfin安裝完畢，這個即裝即用的硬解jellyfin究竟如何呢，接下來我們來試試。
牛刀小試，改進的轉碼能力與效率
大戲出場，我們選一部4K電影，先看看該影片元資料。
影片引數
這部4K電影是63Mbps位元速率的HDR影片，需要HDR轉SDR、帶燒錄PGS字幕，轉碼目標解析度為1080，位元速率限制15Mbps。分別在QSV和VAAPI解碼方式下，採用VPP和openCL色調對映方式，檢視在同一段場景穩定後的轉換幀率。
編解碼速度對比
5組資料分別是，1.QSV轉碼 openCL對映 108 fps，2.QSV轉碼 VPP對映 77 fps，3.VAAPI轉碼 openCL對映 48 fps，4.VAAPI轉碼 VPP對映 61 fps，5.對比10.7.7版本VAPI轉碼 VPP對映 46 fps。
再拿一部60fps的電影測試一下。
60fps 4K 測試
同樣的選QSV轉碼 openCL對映 穩定在110 fps 左右。
以上資料測試硬體環境 intel 8代i5，intel UHD核顯655，軟體系統為黑裙DSM6.2.3。測試的影片需要HDR轉SDR，燒錄PGS，缺少一項，轉碼速度都可能起飛達到3xx fps以上。
對比資料可以看到，nyanmisaka自帶的驅動和ffmpeg，加上jellyfin功能支援，轉碼提升非常明顯。
轉碼功能：如nyanmisaka大佬所說，無腦安裝完成，無須自己打補丁，即可支援完整硬體功能。以前版本存在的QSV解碼沒有openCL色調對映選項，現在有了；QSV解碼燒錄PGS卡在19fps的問題解決了；VAAPI以前openCL無法燒錄PGS字幕問題也解決了。
轉碼能力：QSV整體轉碼能力優於VAAPI。與以前的版本相比，VAAPI轉碼VPP對映（以前版本只有這個模式支援PGS燒錄）幀率由46fps提高到61fps，提升33%。QSV轉碼與VAAPI轉碼在對映方式上效率相反，QSV在openCL對映方式下效率最高，而VAAPI轉碼在VPP對映方式下效率高於openCL對映。實際上，經過幾天的連續轉碼試用，我更推薦大家用QSV轉碼配合openCL色調對映來日常工作，畢竟這個轉碼幀率能達到110fps左右，比以前的能用的模式（模式不一樣哦）46fps，如果直接對比的話提升135%，稱為吊打也不過分。
畫質提升：以前VAAPI轉碼的時候，如果大家仔細看畫面，可以看到畫面被切分為好幾個矩形塊，而相鄰兩個塊交接線會看到輕微色差和亮度差。新的驅動和ffmpeg更新，已經消除了這個問題。
結論：Nyanmisaka/jellyfin真的是裝完就用，玩硬解的小夥伴們可以愉快的過度到這個版本來，nyanmisaka大佬這幾天也是火力全開，各大論壇都看到他在互動，docker也在頻繁更新，什麼，好像剛剛又更新了。。。。
番外，nyanmisaka帶來的核心提升暫時測試結束，非常難得nyanmisaka大佬本人也來到zdm留言跟大家互動，所以下面附加一些jellyfin設定和使用方面的討論，希望nyanmisaka大佬幫大家科普一下。
jellyfin alpha3 幾個小問題
QSV模式TV客戶端底部色條
在QSV轉碼燒錄PGS字幕的時候，TV客戶端預設exoPlayer播放畫面底部出現明顯的彩色橫條，而且隨著影象變換。肉眼看上去大概就是有幾行。其實不燒錄PGS字幕的時候也有。只是行數更少不容易發現而已。
看上去像是記憶體複製資料的時候錯位了幾行，底部幾行沒填滿。而VAAPI轉碼就沒有，或稱為很輕微，仔細看好像有1、2行。
而同樣模式在PC的web客戶端、手機客戶端web/exoPlayer方式都沒發現問題。
低功率編碼
新版本帶來兩個低功率編碼器選項
新的選項
啟動後並沒有發現轉碼速度有提升，而且只能工作在VAAPI模式下，選QSV模式直接報錯。
ASS字幕口口口口問題
敲黑板，10.8.0似乎已經支援Web端、exoplayer客戶端顯示ASS字幕和PGS字幕，無需伺服器端轉碼燒錄。在做web端測試的時候，預設為自動的方式下ASS字幕將不會轉碼燒錄。這時候web客戶端直接顯示ASS字幕，中文字幕還是會因為缺字型而顯示口口口口。解決的方法是，啟用備用字型。
啟用備用字型
我們要進入控制檯播放轉碼設定裡面去標註4位置指定字型路徑，勾選標註5位置啟用備用字型。當然，我們自己要先找好支援中日韓文的.woff2字型，如上圖，我是放到config下woff2目錄下的。
啟用效果
標註1是預設交給客戶端顯示ASS字幕因為缺字型檔仍然出現口口口口，標註2是啟用備用字型檔後，客戶端ASS字幕顯示正常。
ASS字幕也可以強制燒錄，透過使用者設定頁面來啟動。
啟用ASS燒錄
進入使用者設定選單（注意不是進入控制檯），燒錄字幕選 所有複雜格式字幕 或 全部 都可以啟用ASS字幕伺服器端燒錄。這樣nyanmisaka大佬內嵌的中文字型檔支援就能派上用場了。
這裡敲黑板2次 我推薦把ASS檔案轉為PGS字幕除了所見即所得之外，也在jellyfin中遇到很棘手的問題。每次伺服器端轉碼燒錄ASS字幕，都會瘋狂讀取影片檔案，好像是全部讀取才能獲取ASS檔案一樣，有的長達幾十秒客戶端才開始播放（想想一部4K高碼電影可有幾十個G），我一度以為jellyfin掛了。我測試了好多影片檔案，都是如此。而PGS字幕就很正常。理解不了ASS和PGS轉碼預讀差別為何這麼巨大。如果說ASS檔案需要全部讀完才能獲取所有特效，即使MKV封裝將ASS檔案封裝到檔案的最後，讀取檔案不是可以SEEK直接讀取後段檔案嗎，一個ASS檔案幾百K而已。而一個PGS檔案，一言不合就是幾十M，雖然PGS是按時間順序一段一段的不需要首尾適應。但是作為預讀的話，PGS也可能在MKV封裝的最後，讀取量更大，為什麼PGS不影響轉碼預讀時間呢。。。唉，說得我都糊塗了。。。。。
總之，如果遇到ASS檔案燒錄播放不出畫面的情況，jellyfin並沒有掛掉，它正在忙著呢，請耐心等待幾十秒，奇蹟會出現的。有句歌詞：我等到花兒都謝了~~~
也許是我遇到的個別情況，不知道nyanmisaka大佬遇到過沒有。
新的色調對映演算法
10.8.0版本帶來了BT.2390色調對映演算法，全新安裝已經預設啟用該演算法。如果手上有同一部電影的SDR和HDR版本的小夥伴，歡迎加入一起來測試。這裡我就先貼圖為敬了。
選擇對映演算法
在控制檯選擇播放轉碼設定，標註1位置選中啟動色調對映，這個是openCL模式，啟用VPP模式是沒有引數可調的。
openCL 預設演算法是BT.2390，以前這裡預設是Hable。
引數一覽
除了演算法選擇，下面還有不少引數選項，以上引數有中文介紹，我們先保持建議值。上圖最下面一個色調對映引數，預設是空著的，就是預設引數或不需要引數的意思，如果我們選不同的演算法，如果有引數的話，在這裡設定。先來一組預設引數效果貼圖，第一張是作為參考的SDR影片畫面。
SDR
必須承認，SDR色彩亮度看上去是很舒服的，這部電影有點典型，就是我找到的HDR版本轉換SDR都比較暗（預設引數，如果想調整，看後面），以下效果只代表一部分類似HDR電影，有很多電影的HDR也做得很好，預設引數轉出來效果就不錯。對比猛烈一點，大家也能看到差距，主要就是大家研究研究，不要認真就好，不要扔我磚頭就好。。。。。
HDR-VPP
這個是用VPP轉出來的效果，沒什麼引數可調，就是這樣，為什麼黑，可能VPP就喜歡黑吧。。。。但是它的飽和度，說人話就是色彩看上去還是很豐富的，就是亮度不準，不知道如果HDR描述的亮度峰值不準的話，哪裡可以強制100nits就好了，或許VPP演算法預設400或1000沒法改。。。。。以下openCL我也沒找到這個設定，如果我們調整亮度，只有改該演算法的引數來實現。如果有小夥伴找到可以設定VPP對映引數的地方，記得@我。
HDR-openCL-BT.2390
BT.2390 色調對映，nyanmisaka大佬推薦演算法。ffmpeg官網我沒查到具體說明，可能是最最最新支援，都沒來得及寫介紹。只知道是一種“基於直接對映的轉換方法”。這是我網上抄的，具體什麼意思，好像很神秘，不過該方法飽和度（顏色）不錯，，，以下不再解釋飽和度，亮度沒有引數可調，預設裡面算不錯的。
HDR-openCL-Hable
演算法Hable，是原版本預設的轉換方法，官方介紹是比Reinhard更好地展現深色和高亮度細節，但代價是會稍微使所有內容變暗。真的有點暗，難怪剛開始用jellyfin的時候，發現我的HDR影片怎麼這麼黑，我還拿著電筒對著電視照了半天，也亮不起來，唉。。。對了，Hable演算法沒有引數可調，殘念。。。。
HDR-openCL-None
演算法None，這個簡單粗暴，就是直接對高亮度區域做去飽和。大概就是不要顏色，白色一片。好歹看得清楚衣服上的扣子了，不過也不支援引數調整。
HDR-openCL-Clip
演算法Clip，粗暴x2，對於超出的部分硬剪輯。可以支援引數，預設為1.0，調整1.5就是線性增加50%亮度的意思，反正你弄的太亮的地方，白就是了。不過，總算有個可以調整亮度的方法了。
HDR-openCL-Linear
演算法Linear，將整個參考色域拉伸為顯示終端支援的線性倍數。好像就是最大和最小，拉根直線的意思。於是，這種有很亮場景的畫面，我們看到比上面兩個方法更暴力的出現了，這完全是黑啊，大哥。線性引數預設也是1.0，要調到多少合適呢。
HDR-openCL-Gamma
演算法Gamma，調過顯示器Gamma的小夥伴應該熟悉，可調的對數曲線來進行轉換。可以調整引數，預設值為 1.8。數學學得好的小夥伴們應該最愛了吧，來試兩手？
HDR-openCL-Reinhard
演算法Reinhard，使用非線性對比度，透過簡單的曲線保留整體影象亮度，從而實現細節變平和色彩精度下降。這個官方定義有點拗口，就是儘量保證亮度但是犧牲了細小的輪廓和顏色的平滑度。可以調整引數，預設0.5，對應指色域內值的亮度大約是剪下時的一半同，如果調整到0.75或0.8，亮度感官明顯提升，同比顏色恢復也算不錯，但是比SDR還是差一些。
HDR-openCL-Mobius
演算法Mobius，平滑地對映超出範圍的值，同時儘可能保留範圍內的對比度和顏色。如果你覺得色彩準確性比細節保留更重要時，推薦使用。預設引數0.3，是指線性到mobius變換過度點，數學小能手又能看看這組引數怎麼調了。
總之，以上方法大部分都對應一個轉換曲線，有的可以用引數調整曲線的形狀，比如簡單的有斜線型、兩頭平滑中間傾斜類似足型，等等。然後以這個曲線為基礎進行轉換。。。。算了，我們還是看圖吧。
預設對映對比
我們對比一下，1.標準SDR，2.無引數可調的VPP對映，3.沒找到引數可調的BT.2390對映，4.沒引數可調的Hable對映。可以看到nyanmisaka大佬推薦的BT.2390方法確實不錯。
再看看下面這組
全部方法對比
這組也全部採用預設引數，1.標準SDR，2.演算法None，3.演算法Clip，4.演算法Linear，5.演算法Gamma，6.演算法Reinhard，7.演算法Hable，8.演算法Mobius，9.演算法BT.2390。
可以看到，預設引數下，None，Clip，Reinhard，Mobius，BT.2390至少亮度上勝出。看了官方廣告，我決定再試一組Reinhard和BT.2390的。其實也不是全看廣告，我也看療效的。能改引數的我都試了。Reinhard引數直觀，亮度和色彩還原綜合也算不錯，所以。。。還是看圖吧。
BT.2390對映對比
這組1 標準SDR，2 演算法Reinhard 採用引數0.8，3 演算法Reinhard 採用預設引數，4 標準SDR，5 演算法Reinhard 引數0.8，6 演算法Reinhard 預設引數，7 演算法Reinhard 引數0.8, 8 演算法Reinhard 預設引數，9 演算法BT.2390無引數。
這組測試主要展示了方法Reinhard引數設定到0.8，見標註2，可以獲取比SDR更好的亮度效果，缺點是對比度稍差，顏色略清淡，可以【色調對映範圍】強制改為TV模式，可以稍微提升一點色澤。為什麼能提升，因為TV模式有負訊號，相當於拉昇了顏色的飽和度和亮度的對比度。。不過這個屬於作弊吧，算了。
演算法Reinhard同樣的引數，在另一部影片對比中，亮度就有點過了，見標註5。這說明不是所有HDR影片轉換都需要提升亮度，如果有部分HDR轉換偏暗無法忍受的話，建議小夥伴用演算法Reinhard，引數使用0.75-0.8。
同時，在預設引數下，演算法BT.2390直觀感受比方法Reinhard轉換效果還是好一點。見標註9和標註8。
我們再次對比一下BT.2390和Reinhard
推薦BT.2390
如上圖，1 標準SDR，2 演算法BT.2390無引數可調 3 演算法Reinhard 引數0.8，4 演算法Reinhard 預設引數。可以看到還是SDR效果最好。。。我們還是去找SDR吧。。。。。。。這樣的，小夥伴們能不能放大圖看呢，標註2演算法BT.2390轉換的亮度跟標註4演算法Reinhard預設引數的亮度差別不大，但是色彩豐富度要好一些。
貼了這麼多圖，我也不知道怎麼建議，數學好的小夥伴們早就自己開始計算引數了吧。我只能說我覺得亮度不夠的話，我就用演算法Reinhard設定引數0.8，免得我黑燈瞎火的找電筒。簡單點，就跟著nyanmisaka大佬的用BT.2390吧，過幾天說不定又有新演算法。
不知道nyanmisaka大佬是不是在開發一種像相機HDR一樣，高曝光一張，低曝光再一張，然後合成一張正常觀感又能看到亮度細節的演算法出來。這個不是HDR最先出來宣傳的效果嗎。HDR不是來支援我們老裝置看高亮畫面的嗎，怎麼現在就要我不停的買買買買HDR裝置呢，我還要存錢買Dolby Vision呢，這裡面一定有很大的誤解。。
最後，很快會再見
nyanmisaka透露，元旦前後jellyfin 10.8.0正式版會推出。不過相對於官方的jellyfin/jellyfin，nyanmisaka/jellyfin是幫我們集成了最新驅動、字型檔和相關基礎庫的，官網因為遵循開源協議的問題，這方面是比較被動的。
作為半官方加強版的nyanmisaka/jellyfin，一起等待元旦節10.8.0正式版的釋出吧。
作者宣告本文無利益相關，歡迎值友理性交流，和諧討論～
