1. 一個(gè)內(nèi)網(wǎng)播放場(chǎng)景引發(fā)的分歧服務(wù)端縮放和客戶(hù)端縮放到底差在哪1.1 觸發(fā)我的那個(gè)具體場(chǎng)景幾個(gè)月前我在一個(gè)自建媒體服務(wù)器的交流群里看到一張截圖一位群友用Jellyfin在家里看一部4K原盤(pán)電影播放進(jìn)度條卡在“轉(zhuǎn)碼中”的狀態(tài)整整十幾秒他忍不住在群里吐槽“內(nèi)網(wǎng)都千兆帶寬了為什么不直接串流原畫(huà)給電視為什么非要服務(wù)端縮放一下再發(fā)過(guò)來(lái)”這一問(wèn)直接把“內(nèi)網(wǎng)流媒體里服務(wù)端縮放與客戶(hù)端縮放怎么選”這個(gè)問(wèn)題擺到了臺(tái)面上。當(dāng)時(shí)群里立刻分成兩派一派說(shuō)“解碼不了就轉(zhuǎn)碼天經(jīng)地義”另一派說(shuō)“自己家的網(wǎng)絡(luò)直接原碼流推過(guò)去客戶(hù)端自己縮放不是更省事嗎”。兩邊各說(shuō)各有理但誰(shuí)也沒(méi)有把服務(wù)端和客戶(hù)端兩條鏈路背后的真實(shí)成本講透。后來(lái)我專(zhuān)門(mén)把這篇文章記錄下來(lái)也是基于自己跑了一兩年內(nèi)網(wǎng)流媒體服務(wù)后的一些實(shí)際體會(huì)。先給結(jié)論內(nèi)網(wǎng)流媒體場(chǎng)景下服務(wù)端縮放和客戶(hù)端縮放不是簡(jiǎn)單的“哪個(gè)更好”問(wèn)題而是“在什么條件下用哪個(gè)更合理”的問(wèn)題。兩者的本質(zhì)差異在于——服務(wù)端縮放做的是先解碼、再縮放、后重新編碼的完整轉(zhuǎn)碼鏈路客戶(hù)端縮放做的是保持原碼流直通、播放端解碼后由渲染管線做縮放輸出。這兩條鏈路對(duì)服務(wù)器CPU/核顯的壓力、對(duì)畫(huà)質(zhì)的影響、對(duì)客戶(hù)端解碼能力的要求完全不一樣。1.2 “縮放”這個(gè)詞在流媒體語(yǔ)境下其實(shí)包含三層含義很多剛接觸自建流媒體服務(wù)的人會(huì)把“服務(wù)端縮放”簡(jiǎn)單理解為“把4K壓成1080P”這其實(shí)只對(duì)了三分之一。我在實(shí)際配置里發(fā)現(xiàn)Jellyfin、Emby、Plex這些媒體服務(wù)器一旦觸發(fā)轉(zhuǎn)碼通常會(huì)同時(shí)做三件事分辨率縮放、編碼格式轉(zhuǎn)換、碼率重設(shè)。舉個(gè)例子一部片源是4K HEVC 10bit、碼率60Mbps的藍(lán)光原盤(pán)電視的硬件解碼器只支持H.264不支持HEVC 10bit。此時(shí)服務(wù)端會(huì)先解碼原始4K幀縮放成1080P再用H.264編碼器重新壓縮輸出碼率可能被限制在20Mbps左右。這個(gè)過(guò)程中分辨率變了、編碼格式變了、碼率也變了——這才是真正的“轉(zhuǎn)碼”縮放只是其中一環(huán)。而客戶(hù)端縮放的路子完全不同服務(wù)端檢測(cè)到播放器能力足夠時(shí)直接發(fā)送原始碼流不做任何處理。播放器拿到完整碼流后自行解碼出原始分辨率畫(huà)面然后再由GPU渲染管線和播放器渲染算法縮放到電視的實(shí)際物理分辨率。整個(gè)過(guò)程沒(méi)有二次編碼也就不存在重編碼造成的畫(huà)質(zhì)損失。這也就是我文章里想重點(diǎn)對(duì)比的核心問(wèn)題內(nèi)網(wǎng)環(huán)境下我們到底為了什么去做服務(wù)端縮放又什么時(shí)候應(yīng)該放手讓客戶(hù)端自己來(lái)2. 服務(wù)端縮放轉(zhuǎn)碼鏈路的真實(shí)成本、畫(huà)質(zhì)損耗與硬件門(mén)檻2.1 一條轉(zhuǎn)碼鏈路拆開(kāi)看解碼、縮放、重編碼各做了什么先明確一個(gè)容易被忽略的事實(shí)服務(wù)端縮放不是一個(gè)“直接壓縮畫(huà)面”的操作而是一條完整的處理管線。我用最常見(jiàn)的一條轉(zhuǎn)碼鏈來(lái)說(shuō)明原始碼流4K HEVC 10bit→ 硬解碼器解碼 → YUV幀 → 縮放器重采樣 → 1080P幀 → 硬編碼器重新編碼 → 輸出H.264/HEVC 8bit碼流 → 推送客戶(hù)端這一步里任何一個(gè)環(huán)節(jié)都會(huì)消耗服務(wù)器的CPU或GPU資源也會(huì)引入延遲。實(shí)測(cè)下來(lái)Jellyfin在觸發(fā)轉(zhuǎn)碼任務(wù)時(shí)從啟動(dòng)FFmpeg進(jìn)程到客戶(hù)端第一幀畫(huà)面出現(xiàn)通常需要3到10秒具體取決于片源體積、服務(wù)器性能和是否使用硬件轉(zhuǎn)碼。而直接串流原碼流時(shí)首幀時(shí)間通常不到1秒。這里有個(gè)隱藏很深的問(wèn)題很多人以為服務(wù)端縮放就是把4K縮小到1080P畫(huà)質(zhì)一定會(huì)變差但至少能看。實(shí)際上如果縮放器算法選得不好或者重編碼碼率設(shè)置得太保守輸出畫(huà)面可能出現(xiàn)明顯的色帶、涂抹和細(xì)節(jié)丟失尤其在暗部場(chǎng)景和高速運(yùn)動(dòng)畫(huà)面里。Jellyfin默認(rèn)使用的FFmpeg swscale縮放器在“快速”模式下質(zhì)量只能說(shuō)夠用和播放器端的專(zhuān)業(yè)渲染算法相比有明顯差距。2.2 畫(huà)質(zhì)損失不是玄學(xué)二次編碼與縮放算法我自己做過(guò)一次很直觀的對(duì)比同一部4K電影一條鏈路是服務(wù)端縮放到1080P重編碼后播放另一條鏈路是客戶(hù)端直接播放4K原盤(pán)然后讓電視把畫(huà)面縮放到1080P顯示。把兩路畫(huà)面定格在同一個(gè)復(fù)雜紋理場(chǎng)景下服務(wù)端輸出的1080P畫(huà)面在靜態(tài)場(chǎng)景下差別不大但一到樹(shù)葉、柵欄這種高頻細(xì)節(jié)區(qū)域服務(wù)端那條明顯有發(fā)糊的傾向而客戶(hù)端直連那條幾乎保留了原盤(pán)的全部細(xì)節(jié)。原因不難理解服務(wù)端縮放本質(zhì)上是一次有損重編碼即使碼率給到20Mbps重新編碼也一定會(huì)丟棄部分幀內(nèi)高頻信息。而客戶(hù)端縮放是播放器解碼出完整原分辨率畫(huà)面之后再縮放畫(huà)面信息沒(méi)有被二次重編碼損耗過(guò)相當(dāng)于“全量信息再做降采樣”畫(huà)質(zhì)下限高得多。所以如果你的播放終端性能足夠客戶(hù)端縮放幾乎總是能比服務(wù)端縮放提供更好的畫(huà)面——這里的“更好”不是玄學(xué)上的更好是放大到4K電視上也能一眼看出來(lái)的更好。2.3 硬件成本N100、核顯、并發(fā)數(shù)的真實(shí)賬要說(shuō)清楚服務(wù)端縮放的成本繞不開(kāi)硬件。我自己的服務(wù)器只是臺(tái)N100小主機(jī)核顯是Intel UHD Graphics支持QSV硬件轉(zhuǎn)碼。實(shí)測(cè)下來(lái)同時(shí)跑一條4K HEVC轉(zhuǎn)1080P H.264任務(wù)核顯占用大概40%左右CPU占用不會(huì)太高但如果強(qiáng)制開(kāi)啟HDR色調(diào)映射Tone MappingCPU占用直接飆到90%以上轉(zhuǎn)碼速度會(huì)掉到實(shí)時(shí)倍率以下。這引出一個(gè)實(shí)際決策點(diǎn)服務(wù)端縮放的強(qiáng)度直接決定了你能同時(shí)服務(wù)多少個(gè)客戶(hù)端。如果你的服務(wù)器同時(shí)要推流給兩臺(tái)電視、兩部手機(jī)和一個(gè)瀏覽器播放器而其中三臺(tái)設(shè)備都觸發(fā)了轉(zhuǎn)碼任務(wù)N100這種小主機(jī)很快就會(huì)被拖垮播放畫(huà)面會(huì)頻繁出現(xiàn)緩沖、卡頓。如果選擇客戶(hù)端縮放讓服務(wù)端只做碼流直通那N100同時(shí)撐五六個(gè)并發(fā)也毫無(wú)壓力負(fù)載幾乎可以忽略。所以在內(nèi)網(wǎng)場(chǎng)景里我通常把服務(wù)端縮放當(dāng)成一個(gè)“兜底方案”而不是默認(rèn)方案。它能解決兼容性問(wèn)題但代價(jià)是服務(wù)器負(fù)載、延遲和一定的畫(huà)質(zhì)下降。3. 客戶(hù)端縮放直連播放的渲染鏈路、硬解條件與潛在翻車(chē)點(diǎn)3.1 直連播放的渲染鏈路為什么“更接近原畫(huà)”客戶(hù)端縮放這條路簡(jiǎn)單說(shuō)就是“服務(wù)端不插手播放器自己搞定”。整個(gè)鏈路是服務(wù)端直接推送原始碼流 → 客戶(hù)端解碼器硬解/軟解出完整畫(huà)面 → GPU/渲染器按輸出分辨率縮放 → 顯示。因?yàn)橹虚g沒(méi)有二次編碼和碼率重設(shè)信息量是完整保留的所以畫(huà)質(zhì)上幾乎可以認(rèn)定是“無(wú)損處理”。這里要特別提一下播放器渲染器的縮放質(zhì)量差異。同一個(gè)4K視頻縮放到1080P顯示不同播放器的渲染效果差別非常明顯。比如Infuse在Apple TV上用的渲染管線、MPV系列的渲染線程、Kodi的默認(rèn)渲染器縮放算法都不一樣。好的渲染器在處理降采樣時(shí)會(huì)綜合考慮邊緣抗鋸齒和細(xì)節(jié)保留畫(huà)質(zhì)觀感顯著更好。Jellyfin官方客戶(hù)端在不同平臺(tái)上使用的渲染內(nèi)核也有差異實(shí)測(cè)下來(lái)Apple TV和iPad上的Infuse表現(xiàn)最好Android TV自帶的Jellyfin客戶(hù)端次之瀏覽器網(wǎng)頁(yè)播放器最弱。這也是為什么我常說(shuō)如果你手上的播放終端性能不錯(cuò)客戶(hù)端縮放畫(huà)質(zhì)幾乎永遠(yuǎn)優(yōu)于服務(wù)端縮放。但這個(gè)結(jié)論有一個(gè)致命前提——客戶(hù)端的解碼能力必須能扛得住原始碼流。3.2 客戶(hù)端硬解的邊界條件不是所有播放器都值得信賴(lài)客戶(hù)端縮放翻車(chē)的場(chǎng)景我踩過(guò)的坑至少有兩類(lèi)。第一類(lèi)是播放終端對(duì)HEVC 10bit的硬解支持不完整。很多老款A(yù)ndroid電視盒子芯片官方寫(xiě)著支持4K解碼但只支持HEVC 8bit碰到10bit HDR片源就軟解軟解4K高碼率基本就是幻燈片。這種情況下客戶(hù)端直連4K原盤(pán)會(huì)很卡這時(shí)候反而是服務(wù)端轉(zhuǎn)成H.264 1080P更實(shí)際。第二類(lèi)是客戶(hù)端渲染器的縮放優(yōu)化很弱。部分智能電視自帶的播放器雖然能硬解4K但降采樣到1080P的過(guò)程處理得很糙畫(huà)面要么銳化過(guò)度、要么閃爍。這種時(shí)候客戶(hù)端縮放反而不如服務(wù)端轉(zhuǎn)碼之后再播放來(lái)得穩(wěn)定。所以在選擇客戶(hù)端縮放之前一定要先確認(rèn)三件事終端解碼器是否支持片源的視頻編碼格式尤其是HEVC 10bit、AV1終端網(wǎng)絡(luò)吞吐是否穩(wěn)定內(nèi)網(wǎng)千兆其實(shí)完全夠但Wi-Fi信號(hào)弱的地方還是會(huì)翻車(chē)播放器的渲染質(zhì)量是否夠用如果這三條都滿(mǎn)足客戶(hù)端縮放就是最省服務(wù)器資源、畫(huà)質(zhì)最好的方案如果有一條不滿(mǎn)足那就得老老實(shí)實(shí)考慮服務(wù)端縮放了。4. 內(nèi)網(wǎng)帶寬、終端算力與畫(huà)質(zhì)的權(quán)衡我的決策依據(jù)和量化對(duì)比4.1 帶寬在這里其實(shí)是最不需要擔(dān)心的變量在討論內(nèi)網(wǎng)流媒體時(shí)很多人潛意識(shí)里會(huì)把“縮放”和“在線視頻網(wǎng)站為了省帶寬而轉(zhuǎn)碼”混為一談。這完全是誤解。視頻網(wǎng)站做服務(wù)端縮放主要目的是節(jié)省CDN帶寬成本和統(tǒng)一碼率標(biāo)準(zhǔn)但在家里面自己的NAS和電視之間千兆內(nèi)網(wǎng)跑一部80Mbps的4K原盤(pán)連1%的帶寬上限都用不到。我用數(shù)據(jù)來(lái)量化一下場(chǎng)景原碼流速率服務(wù)端縮后速率千兆內(nèi)網(wǎng)帶寬占用比4K藍(lán)光原盤(pán)60-80 Mbps15-25 Mbps6%-8%1080P高碼率25-40 Mbps8-15 Mbps2.5%-4%4K HEVC web-dl20-30 Mbps10-18 Mbps2%-3%從表里能看出來(lái)即使直接串流高碼率原盤(pán)內(nèi)網(wǎng)帶寬也幾乎不可能成為瓶頸。所以“內(nèi)網(wǎng)流媒體”場(chǎng)景下帶寬根本不該成為選擇服務(wù)端縮放的理由。真正需要權(quán)衡的是終端解碼能力、畫(huà)質(zhì)追求、服務(wù)器硬件負(fù)載、播放兼容性這幾個(gè)變量。4.2 每種場(chǎng)景下的選擇建議根據(jù)我這段時(shí)間的實(shí)操我把常見(jiàn)場(chǎng)景和推薦方案整理成一個(gè)表播放終端片源編碼推薦方案原因Apple TV Infuse4K HEVC 10bit客戶(hù)端縮放解碼能力和渲染質(zhì)量都強(qiáng)直連畫(huà)質(zhì)最佳主流電視端Jellyfin客戶(hù)端4K H.264 / 1080P客戶(hù)端縮放解碼壓力小直連體驗(yàn)流暢老款電視盒子4K HEVC 10bit服務(wù)端縮放硬解不支持必須轉(zhuǎn)兼容格式瀏覽器網(wǎng)頁(yè)播放4K HEVC服務(wù)端縮放瀏覽器對(duì)HEVC硬解支持不統(tǒng)一轉(zhuǎn)H.264更穩(wěn)手機(jī)/平板同一局域網(wǎng)任意客戶(hù)端縮放保證無(wú)線信號(hào)滿(mǎn)格現(xiàn)代手機(jī)解碼能力普遍夠用這個(gè)表格是我目前跑內(nèi)網(wǎng)流媒體服務(wù)時(shí)的默認(rèn)策略。核心邏輯很簡(jiǎn)單只要終端解碼能力過(guò)關(guān)就優(yōu)先客戶(hù)端縮放解碼能力不行就用服務(wù)端縮放兜底。不需要把兩者當(dāng)成對(duì)立選項(xiàng)而是要把它們組合成一套自動(dòng)降級(jí)的流程。這里有個(gè)我覺(jué)得特別關(guān)鍵的認(rèn)知變化“能解碼原盤(pán)”和“真正把客戶(hù)端縮放跑出好效果”不是一回事。真正決定體驗(yàn)的是渲染鏈路質(zhì)量。同樣是Apple TV用系統(tǒng)自帶的播放器和用Infuse直連同一個(gè)片源畫(huà)面觀感差距非常明顯——優(yōu)秀的渲染器不僅縮得好運(yùn)動(dòng)補(bǔ)償和色彩映射也會(huì)更好。4.3 一個(gè)具體的決策樹(shù)示例我在實(shí)際配置時(shí)會(huì)按下面的順序做判斷先看片源編碼格式→ 如果是AV1編碼先確認(rèn)終端是否支持硬解絕大多數(shù)智能電視的硬解支持列表里AV1可能缺失這時(shí)果斷服務(wù)端轉(zhuǎn)碼再看終端品牌和型號(hào)→ Apple TV、新iPad、新旗艦手機(jī)基本可以放心客戶(hù)端縮放老Android盒子、雜牌電視默認(rèn)走服務(wù)端轉(zhuǎn)碼最后看播放器→ 客戶(hù)端是Infuse、MPV這類(lèi)渲染質(zhì)量可靠的播放器優(yōu)先直連如果是系統(tǒng)自帶播放器謹(jǐn)慎測(cè)試一下縮放畫(huà)質(zhì)再?zèng)Q定這樣一個(gè)決策樹(shù)跑下來(lái)基本能夠在“畫(huà)質(zhì)優(yōu)先”和“穩(wěn)定優(yōu)先”之間找到平衡點(diǎn)。5. 實(shí)操可落地的混合策略與Jellyfin配置避坑指南5.1 我的混合策略默認(rèn)直連兜底轉(zhuǎn)碼既然客戶(hù)端縮放畫(huà)質(zhì)更好、服務(wù)器負(fù)載更低為什么還要保留服務(wù)端縮放因?yàn)樗娴氖嵌档桌?。我在服?wù)器上配置的原則很簡(jiǎn)單——默認(rèn)讓客戶(hù)端直連原碼流只有客戶(hù)端播放失敗或明顯卡頓才觸發(fā)服務(wù)端轉(zhuǎn)碼。Jellyfin里對(duì)應(yīng)的設(shè)置主要兩塊播放設(shè)置里的“轉(zhuǎn)碼”開(kāi)關(guān)保持開(kāi)啟但在客戶(hù)端偏好里選擇“最高原始分辨率”或“直接播放優(yōu)先”硬件加速打開(kāi)QSV/VAAPI/NVENC確保一旦觸發(fā)轉(zhuǎn)碼服務(wù)器壓力可控具體操作上我在Jellyfin的“控制臺(tái) → 播放 → 轉(zhuǎn)碼”里把硬件加速設(shè)為Intel QuickSync然后轉(zhuǎn)碼格式保持默認(rèn)。而在每個(gè)客戶(hù)端上把播放質(zhì)量偏好設(shè)置為“原始/原質(zhì)量”同時(shí)把“開(kāi)播前預(yù)先轉(zhuǎn)碼”關(guān)掉。這樣操作之后絕大多數(shù)情況都是直接串流客戶(hù)端自己處理縮放只有碰到不支持的編碼格式時(shí)Jellyfin才自動(dòng)降級(jí)為服務(wù)端轉(zhuǎn)碼。5.2 字幕與音頻比視頻縮放更常觸發(fā)轉(zhuǎn)碼的“隱形觸發(fā)器”這是我在實(shí)際使用中發(fā)現(xiàn)的最容易忽略的一個(gè)細(xì)節(jié)很多次轉(zhuǎn)碼并非視頻縮放引起的而是字幕燒錄或音頻格式不兼容觸發(fā)的。如果你選擇的是圖形字幕PGS而播放器不支持直接渲染Jellyfin會(huì)把字幕燒錄進(jìn)視頻畫(huà)面里這就強(qiáng)制要求服務(wù)端先解碼再重編碼輸出——哪怕視頻本身完全支持直連播放也逃不掉服務(wù)端縮放這條路。同理有些老音箱只支持AAC/MP3而片源是DTS-HD或TrueHD音軌服務(wù)端為了兼容音頻也得觸發(fā)轉(zhuǎn)碼即使視頻軌道本身只是在做直通。所以你在排查“為什么明明設(shè)備支持硬解卻還是轉(zhuǎn)碼了”的時(shí)候不要只盯視頻軌先看看音頻軌和字幕軌。我的經(jīng)驗(yàn)是給播放器端盡量匹配支持PGS/ASS字幕渲染的播放器比如Infuse、Kodi、MPV這類(lèi)同時(shí)把音頻直通設(shè)置打開(kāi)。這樣能大幅減少“被迫服務(wù)端轉(zhuǎn)碼”的頻率讓客戶(hù)端縮放的優(yōu)勢(shì)最大程度發(fā)揮出來(lái)。5.3 幾個(gè)真正翻過(guò)車(chē)的細(xì)節(jié)最后分享幾個(gè)我踩過(guò)的坑希望能幫你少走彎路坑一誤開(kāi)“自動(dòng)調(diào)整畫(huà)質(zhì)”導(dǎo)致內(nèi)網(wǎng)也被降碼率。Jellyfin客戶(hù)端里有個(gè)“自動(dòng)調(diào)整畫(huà)質(zhì)”選項(xiàng)它通常是為外網(wǎng)遠(yuǎn)程串流設(shè)計(jì)的。如果這個(gè)選項(xiàng)開(kāi)著它可能根據(jù)當(dāng)前網(wǎng)速自動(dòng)降低碼率觸發(fā)的還是服務(wù)端轉(zhuǎn)碼導(dǎo)致明明在內(nèi)網(wǎng)千兆環(huán)境畫(huà)質(zhì)也莫名被壓成低碼率。內(nèi)網(wǎng)環(huán)境下一定要把它關(guān)掉?？佣i-Fi信號(hào)差觸發(fā)轉(zhuǎn)碼卡頓。尤其平板、手機(jī)走5G Wi-Fi時(shí)2.4G頻段干擾嚴(yán)重即使服務(wù)端只是直連推送原碼流客戶(hù)端也會(huì)因?yàn)榫W(wǎng)絡(luò)吞吐不穩(wěn)而緩沖。這種問(wèn)題不是靠改服務(wù)端配置能解決的最好在關(guān)鍵播放位置布置更好的無(wú)線AP或者干脆把播放終端接有線網(wǎng)口?？尤齆100這類(lèi)小主機(jī)扛不住4K HDR色調(diào)映射轉(zhuǎn)碼。服務(wù)端縮放本身還好一旦片源帶HDR且需要轉(zhuǎn)為SDR播放色調(diào)映射算法非常吃算力小主機(jī)很容易過(guò)載。我的做法是客戶(hù)端能直連HDR就直連需要轉(zhuǎn)碼時(shí)直接限制輸出為HDR不打映射或者干脆不讓它在同一條鏈路上并發(fā)多任務(wù)?？铀臑g覽器播放器的HEVC支持是重災(zāi)區(qū)。在局域網(wǎng)里用Chrome、Edge打開(kāi)Jellyfin網(wǎng)頁(yè)版遇到HEVC片源時(shí)大概率觸發(fā)服務(wù)端轉(zhuǎn)碼即使你的電腦硬解能力完全沒(méi)問(wèn)題。這是因?yàn)闉g覽器對(duì)HEVC硬解支持參差不齊編碼器授權(quán)也是麻煩事。內(nèi)網(wǎng)場(chǎng)景下盡量用桌面客戶(hù)端或者Infuse這類(lèi)原生播放器能很大程度減少無(wú)謂的轉(zhuǎn)碼。5.4 從“服務(wù)端縮放還是客戶(hù)端縮放”升維到“自動(dòng)降級(jí)策略”把服務(wù)端縮放和客戶(hù)端縮放放在一起看對(duì)自建流媒體服務(wù)的管理員來(lái)說(shuō)真正的目標(biāo)不是“選一個(gè)固定方案”而是搭一套能自動(dòng)判斷、自動(dòng)降級(jí)的策略。既不能迷信“客戶(hù)端縮放萬(wàn)能”也不能一句“轉(zhuǎn)碼保平安”就把服務(wù)器負(fù)載和畫(huà)質(zhì)損失拋在腦后。我在實(shí)際部署中的配置邏輯是服務(wù)端只兜底不包辦客戶(hù)端能接就接接不住再轉(zhuǎn)碼。這樣安排之后服務(wù)器負(fù)載常年低水位畫(huà)質(zhì)體驗(yàn)也基本維持在“原盤(pán)直出”的水平偶爾遇到老終端設(shè)備也能自動(dòng)降級(jí)到服務(wù)端轉(zhuǎn)碼不至于完全不能播。最后再分享一個(gè)自己摸索出來(lái)的小習(xí)慣每次改完Jellyfin的轉(zhuǎn)碼或播放相關(guān)配置后我會(huì)拿一部特點(diǎn)明顯的片源比如暗部場(chǎng)景多的4K原盤(pán)分別在Apple TV、手機(jī)、瀏覽器三個(gè)端各播一遍記錄觸發(fā)轉(zhuǎn)碼的日志并檢查首幀時(shí)間。這樣配置動(dòng)沒(méi)動(dòng)、哪條鏈路有問(wèn)題一眼就能看出來(lái)。這套以播放日志為準(zhǔn)的驗(yàn)證流程比憑感覺(jué)試播放要高效得多。