Ein ZimaOS-Benutzer, der Jellyfin auf einem Intel-N100-System mit 16 GB RAM betrieb, berichtete von einem deutlichen Unterschied beim Wiedergabeverhalten: Medien bis 1080p funktionierten normal, aber ein 4K-Stream, der eine Transkodierung erforderte, trieb die CPU-Auslastung auf 100 % und ruckelte so stark, dass er nicht mehr anschaubar war. Jellyfin lief mit Host-Netzwerk, und der Server hatte keine dedizierte GPU.
Die Community-Diskussion führte nicht zu einer einzigen bestätigten endgültigen Lösung. Stattdessen entwickelte sie sich zu einer praktischen Untersuchung von Software-Transkodierung, integrierter Intel-Grafik, VA-API, Codec-Kompatibilität, HDR-Tone-Mapping und der richtigen Stelle zur Überprüfung einer aktiven Transkodierung. Der ursprüngliche Benutzer aktivierte schließlich die Hardwarebeschleunigung und konnte einen transkodierten Stream wiedergeben, obwohl die CPU-Auslastung weiterhin bei etwa 95–98 % lag.
Das ursprüngliche Jellyfin-Problem mit der 4K-Transkodierung
Der Server verwendete einen Intel-N100-Prozessor und 16 GB Arbeitsspeicher. Jellyfin fungierte als lokaler Medienserver, und der Netzwerktyp für Docker war auf Host eingestellt. Die normale 1080p-Wiedergabe war kein Problem.
Das Problem trat nur auf, wenn eine 4K-Datei eine Transkodierung erforderte. Daraufhin stieg die Prozessorauslastung auf 100 %, die Wiedergabe ruckelte und der Stream war praktisch nicht mehr anschaubar. Der Benutzer wollte daher wissen, welche Jellyfin-Einstellungen die Transkodierungsleistung ohne dedizierte Grafikkarte verbessern könnten.
Dieser Unterschied zwischen 1080p und 4K wurde zum zentralen Hinweis in den Antworten. Die Community konzentrierte sich weniger auf Netzwerk und Arbeitsspeicher und mehr darauf, was Jellyfin konvertierte, ob die integrierte Grafik des N100 verwendet wurde und ob der ausgewählte Client das Quellformat direkt wiedergeben konnte.
Warum Codec- und Client-Kompatibilität zum Thema wurden
goultron beschrieb 4K-Transkodierung auf einem System der N100-Klasse als anspruchsvolle Aufgabe, insbesondere wenn der Server auf die CPU zurückgreift. Der eigene Ansatz bestand darin, keine 4K-Bibliothek zu pflegen und H.264-Medien zu bevorzugen, da sie auf einer größeren Bandbreite von Geräten direkt wiedergegeben werden.
Die Antwort hob außerdem einen wichtigen praktischen Punkt hervor: Selbst ein H.264-Video kann weiterhin irgendeine Form der Konvertierung erfordern. Das Empfangsgerät, die unterstützten Audioformate und die verfügbare Netzwerkgeschwindigkeit können den endgültigen Wiedergabepfad beeinflussen. goultron vermutete, dass die Audiokonvertierung für einige Streams verantwortlich war, die trotz H.264-Video weiterhin transkodiert wurden.
Sie stellten dies einem großen Teil der verfügbaren 4K-Inhalte gegenüber, die üblicherweise H.265/HEVC verwenden. Einige kleinere Wiedergabegeräte und Fernseher können möglicherweise nicht jedes H.265-Profil direkt verarbeiten. In diesen Fällen muss Jellyfin die Quelle für den Client konvertieren, wodurch die Last wieder auf den Server verlagert wird.
gelbuildings Hauptdiagnose: Zuerst die iGPU des N100 überprüfen
gelbuilding hielt das Verhalten des N100 für erwartbar, wenn Jellyfin eine 4K-Transcodierung per Software durchführte. Die Erklärung war einfach: Eine kleine CPU kann durch diese Aufgabe vollständig ausgelastet werden, was die ursprüngliche flüssige 1080p-Wiedergabe und die unbrauchbare 4K-Transcodierung des Benutzers erklärt.
Zunächst sollte überprüft werden, ob Jellyfin tatsächlich die im N100 integrierte Intel-Media-Engine verwendet. Der N100 benötigt keine separate Grafikkarte, um eine iGPU bereitzustellen. Jellyfin muss jedoch die Hardwarebeschleunigung aktiviert haben und aus seinem Container auf dieses Gerät zugreifen können.
Der in der Antwort genannte Einstellungspfad lautete:
- Öffnen Sie die Jellyfin-Administrationsoberfläche.
- Öffnen Sie Wiedergabe.
- Öffnen Sie Transcodierung.
- Aktivieren Sie die Hardwarebeschleunigung.
- Wählen Sie für die im Thread besprochene Konfiguration VA-API aus.
Erwartet wurde, dass die Verarbeitung nicht mehr per Software auf der CPU, sondern auf der Intel-iGPU erfolgt. gelbuilding wies außerdem darauf hin, dass nicht erwartet werden könne, dass die iGPU des N100 jede 4K-Quelle problemlos konvertiert. Als mögliche Ausnahmen wurden insbesondere HEVC-Dateien mit hoher Bitrate genannt, bei denen weiterhin eine Verarbeitung per Software erfolgen könne.
Die Community korrigierte, wo VA-API überprüft werden sollte
Die erste Antwort schlug vor, im Dashboard → Aktivität nach einer VA-API-Kennzeichnung für H.264 oder HEVC zu suchen. goultron testete diesen Hinweis in Jellyfin 10.10.7 und stellte fest, dass auf der Aktivitätsseite nur Ereignisse wie VideoPlayback und VideoPlaybackStopped angezeigt wurden.
gelbuilding korrigierte daraufhin die Anweisung. Die Aktivitätsseite sollte nicht anzeigen, ob die Transcodierung per VA-API oder per Software erfolgte. Die relevanten Informationen sollten überprüft werden, während der 4K-Stream unter folgendem Menüpunkt aktiv transcodiert wird:
- Dashboard
- Wiedergabe
- Transcodierung
Die aktive Sitzung sollte unter dem Codec eine Zeile anzeigen. Eine VA-API-Kennzeichnung bedeutet, dass die Hardwarebeschleunigung beteiligt ist; eine Software-Kennzeichnung bedeutet, dass die CPU die Konvertierung übernimmt. Wenn der Transcodierungsbereich leer ist, wird die Datei möglicherweise direkt wiedergegeben oder direkt gestreamt, d. h. es findet keine aktive Videotranscodierung statt.
Warum btop keine eindeutige Antwort auf die Frage des Threads gab
goultron versuchte außerdem, die iGPU-Aktivität über btop zu überprüfen. Die Intel-iGPU wurde im GPU-Bereich nicht eindeutig angezeigt, obwohl dieselbe iGPU zuvor bereits erfolgreich an Frigate durchgereicht worden war und Frigate angezeigt hatte, dass das Gerät verwendet wurde.
gelbuilding antwortete, dass btop in diesem ZimaOS-Kontext hauptsächlich dedizierte GPUs anzeige und daher die Intel-iGPU möglicherweise auch bei aktiver Nutzung nicht darstelle. Aus diesem Grund empfahlen sie, die aktive Transkodierungsansicht von Jellyfin als direkte Bestätigungsmethode zu betrachten.
Zima-Jerry ergänzte später, dass btop zur Beobachtung der GPU-Auslastung verwendet werden könne. Diese beiden Aussagen wurden vor dem Ende der Diskussion nicht miteinander in Einklang gebracht. Der Community-Thread spricht daher dafür, btop als zusätzliches Beobachtungswerkzeug zu verwenden, jedoch nicht als alleinigen Beleg. Die aktiven Transkodierungsinformationen von Jellyfin bleiben erforderlich, um VA-API-Verarbeitung von Softwareverarbeitung zu unterscheiden.
Zima-Jerrys Konfiguration für HDR-Tonemapping
Zima-Jerry verlinkte eine weitere Community-Konfiguration, die sich auf Jellyfin-Hardwarebeschleunigung und HDR-Tonemapping auf dem Intel N100 konzentrierte. In jenem früheren Fall wurde berichtet, dass die damals im App Store verfügbare Jellyfin-Version ein Problem bei der Farbtokonvertierung hatte.
Als Alternative wurde das nyanmisaka-Jellyfin-Container-Image zusammen mit einer benutzerdefinierten YAML-Konfiguration vorgeschlagen. Dabei handelte es sich um eine gemeinschaftliche Behelfslösung, die an die damals verwendeten Jellyfin- und ZimaOS-Versionen gebunden war. Daher sollte sie vor dem Ersetzen einer bestehenden Installation mit der aktuellen App-Store-Version verglichen werden.
Das in diesem verwandten Beitrag geteilte Ergebnis bedeutete kein uneingeschränktes 4K-Transkodieren. Zima-Jerry schätzte, dass die integrierte Grafik des N100 in der getesteten Konfiguration Dolby-Vision-Videos mit ungefähr 4K bei 30 fps oder darunter flüssig konvertieren konnte.
Was sich änderte, nachdem der ursprüngliche Nutzer die Hardwarebeschleunigung aktiviert hatte
Nach der Prüfung der Antworten aktivierte Heimwerkerking die Hardwarebeschleunigung für das Transkodieren. Dies führte zu einer deutlichen Verbesserung: Mindestens ein transkodierter Stream wurde abspielbar.
Die im Dashboard angezeigten Informationen zur aktiven Wiedergabe waren 48,7 Mbit/s MP4 H264 AAC. Die CPU-Auslastung blieb jedoch zwischen 95 % und 98 %, sodass der Nutzer weiterhin unsicher war, ob die Intel-iGPU die Videokonvertierung tatsächlich übernahm.
Dieses Ergebnis bewies nicht, dass das Problem vollständig gelöst war. Es zeigte, dass die Konfigurationsänderung die Wiedergabe verbesserte, doch dem Thread fehlten weiterhin ein bestätigtes VA-API-Label, ein vollständiges FFmpeg-Ergebnis oder eine abgestimmte iGPU-Anzeige. In der letzten Antwort wurde erneut empfohlen, die GPU-Auslastung mit btop zu beobachten, und es wurde keine spätere Bestätigung veröffentlicht.
Was dieser Community-Thread tatsächlich belegt
Die Diskussion spricht stark dafür, dass eine Software-4K-Transcodierung die erste Erklärung für eine CPU-Auslastung von 100 % auf einem N100 ist. Außerdem wird ein korrigierter Prüfpfad beschrieben: Starten Sie eine 4K-Transcodierung und überprüfen Sie die aktive Sitzung im Bereich „Wiedergabe“ und „Transcodierung“ von Jellyfin statt im Aktivitätsverlauf.
Die Antworten zeigen mehrere Grenzen hinsichtlich der Arbeitslast auf. Die H.265-Kompatibilität des Clients, Audiokonvertierung, eine hohe Quellbitrate, HDR-Tonemapping und der konkrete Jellyfin-Container können das Ergebnis beeinflussen. Die Aktivierung von VA-API verbesserte die Möglichkeit des ursprünglichen Nutzers, einen transkodierten Stream abzuspielen, doch die CPU-Auslastung blieb hoch.
Der Thread legt weder eine allgemein gültige Anzahl von Streams für den N100 fest noch beweist er, dass eine Intel-Arc-GPU erforderlich ist. gelbuilding stellte zwei mögliche nächste Schritte für Nutzer vor, die weiterhin eine stabile 4K-Konvertierung benötigen: die Quellbitrate senken oder eine kleine Intel-Arc-GPU hinzufügen. Die Diskussion endete, bevor eine der beiden Optionen vom ursprünglichen Verfasser getestet wurde.
FAQ aus der Community-Diskussion
Warum funktionierte 1080p, während die 4K-Transcodierung ruckelte?
Die Community führte den Unterschied auf die deutlich höhere Software-Arbeitslast zurück, die entsteht, wenn die 4K-Datei konvertiert werden muss. Der ursprüngliche N100 erreichte während dieses Vorgangs eine vollständige CPU-Auslastung.
Wo sollte VA-API in Jellyfin überprüft werden?
Starten Sie einen 4K-Stream, der eine Transkodierung erzwingt, und überprüfen Sie die aktive Sitzung unter „Dashboard“, „Wiedergabe“ und „Transcodierung“. Es wurde gezeigt, dass der Aktivitätsverlauf nicht das erforderliche VA-API- oder Software-Label liefert.
Was bedeutet eine leere Ansicht für aktive Transkodierungen?
Laut der Korrektur von gelbuilding kann das bedeuten, dass die Datei direkt wiedergegeben oder direkt gestreamt wird und derzeit keine Videotranscodierung aktiv ist.
Hat die Aktivierung der Hardwarebeschleunigung das Problem vollständig gelöst?
Nein. Dadurch wurde ein transkodierter Stream abspielbar, aber die gemeldete CPU-Auslastung blieb bei 95–98 %, und der Thread endete ohne endgültige Bestätigung, dass die iGPU die gesamte Pipeline verarbeitet hatte.
Welche Optionen schlug die Community vor, falls 4K weiterhin instabil blieb?
Die Antworten empfahlen, nach Möglichkeit kompatible H.264-Medien zu bevorzugen, die Bitrate der 4K-Quelle zu senken, die von Zima-Jerry geteilte benutzerdefinierte Jellyfin-Konfiguration zu testen oder eine kleine Intel-Arc-GPU für einen leistungsfähigeren Hardware-Transcoding-Pfad hinzuzufügen.
