Jellyfin na Raspberry Pi 5: Direct Play i ograniczenia transkodowania

Jellyfin na Pi 5: zgodność odtwarzania ma pierwszeństwo

Raspberry Pi 5 może udostępniać lokalną bibliotekę przez Jellyfin, gdy urządzenie odtwarzające obsługuje pliki. Praktycznym celem jest unikanie zbędnej konwersji wideo. Ani SSD, ani szybka sieć nie gwarantują odtwarzania bez buforowania; znaczenie mają nośnik, skoki bitrate, warunki Wi-Fi i możliwości klienta.

Pi 5 ma sprzętowy dekoder HEVC, ale nie ma sprzętowego kodera wideo. Jellyfin wycofał wsparcie dla akceleracji V4L2 na Raspberry Pi i nie zapewnia wspieranej ścieżki transkodowania sprzętowego na Pi 5 w tej konfiguracji. Ustawienie akceleracji pozostaje więc na Brak. Udostępnienie /dev/dri kontenerowi nie dodaje brakującej obsługi.

Cztery tryby odtwarzania i różny nakład pracy

Remux i konwersja samego dźwięku również mogą wymagać stosunkowo niewiele mocy. Niskie obciążenie CPU nie dowodzi trybu Direct Play. Transkodowanie wideo, wtapianie napisów i mapowanie tonów HDR do SDR mogą przekroczyć możliwości Pi. Wtapianie umieszcza napisy bezpośrednio w obrazie filmu, a mapowanie tonów dostosowuje zakres jasności materiału HDR do odtwarzania SDR. Obie operacje mogą wymagać konwersji wideo. Zgodny klient lub wcześniej przekonwertowana kopia materiału często pozwala uniknąć tej pracy podczas odtwarzania.

1. Przygotowanie nośników i uprawnień

Przykład zakłada utrzymywaną 64-bitową instalację Raspberry Pi OS, Docker Engine i aktualną wtyczkę Compose. Wybrany oficjalny obraz Jellyfin musi obsługiwać ARM64. W zapisywalnym katalogu projektu poniższe polecenia tworzą katalogi konfiguracji i pamięci podręcznej oraz pokazują numeryczne identyfikatory bieżącego konta:

mkdir -p config cache
id -u
id -g

Te identyfikatory pasują tylko wtedy, gdy usługa ma działać na bieżącym koncie. Oddzielne konto usługi wymaga własnego UID/GID i praw zapisu do config oraz cache. Katalog mediów potrzebuje praw odczytu plików i przechodzenia przez katalogi nadrzędne. Ogólne chmod -R 755 niepotrzebnie udostępniałoby pliki i nadawało prawa wykonywania; istniejące uprawnienia wymagają kontroli dla wybranego konta.

SSD może przyspieszyć dostęp do bazy danych i miniatur. Media mogą również znajdować się na wystarczająco szybkim dysku twardym lub zamontowanym zasobie sieciowym. Decyduje rzeczywista, utrzymywana przepustowość. Udokumentowany interfejs zewnętrzny Pi 5 to PCIe 2.0 x1; działanie w trybie PCIe 3.0 wykracza poza tę oficjalną specyfikację. Podstawą są stabilne zasilanie, odpowiednie chłodzenie i trwale zamontowana ścieżka mediów.

2. Uruchomienie prostego kontenera

Poniższy plik otrzymuje nazwę compose.yaml. Sąsiedni .env definiuje JELLYFIN_IMAGE jako odwołanie do przetestowanego wydania jellyfin/jellyfin, a także JELLYFIN_UID, JELLYFIN_GID i istniejącą bezwzględną ścieżkę MEDIA_PATH. Zapisany digest, czyli skrót wskazujący dokładną zawartość obrazu, ułatwia odtworzenie tej samej wersji oprogramowania; aktualizacje nadal wymagają świadomej zmiany wersji oraz kopii konfiguracji i danych.

services:
  jellyfin:
    image: ${JELLYFIN_IMAGE:?set tested official jellyfin/jellyfin image}
    restart: unless-stopped
    user: "${JELLYFIN_UID:?set service UID}:${JELLYFIN_GID:?set service GID}"
    ports:
      - "${JELLYFIN_BIND_IP:-127.0.0.1}:8096:8096/tcp"
    volumes:
      - ./config:/config
      - ./cache:/cache
      - type: bind
        source: ${MEDIA_PATH:?set existing absolute media directory}
        target: /media
        read_only: true
        bind:
          create_host_path: false
    security_opt:
      - no-new-privileges:true

Domyślnym adresem nasłuchu jest loopback 127.0.0.1, więc zdalne urządzenia nie uzyskają połączenia. W zaufanej sieci lokalnej JELLYFIN_BIND_IP może wskazywać stały prywatny adres LAN urządzenia Pi. Reguły zapory hosta i routera muszą ograniczać dostęp do właściwej sieci; przekierowanie portu z internetu nie jest potrzebne. Montowanie mediów jest tylko do odczytu, więc Jellyfin nie zapisze metadanych ani napisów w katalogach z filmami.

docker compose config --quiet sprawdza składnię po podstawieniu zmiennych. docker compose up -d uruchamia usługę; docker compose logs jellyfin pokazuje błędy startu i uprawnień. Interfejs WWW działa pod adresem http://<skonfigurowany-adres>:8096. Pierwsza konfiguracja tworzy konto administratora i biblioteki wskazujące ścieżki kontenera, na przykład /media/movies.

Taki dostęp bezpośredni nie wymaga urządzeń graficznych, grup renderowania, sieci hosta ani publicznego adresu wykrywania. HTTP na porcie 8096 nie jest szyfrowane. Dostęp spoza zaufanej sieci LAN wymaga odpowiedniej konfiguracji VPN lub odwrotnego proxy HTTPS. Oficjalny obraz zawiera już jellyfin-ffmpeg; zwykła konfiguracja obrazu nie wymaga podmiany na FFmpeg hosta ani ręcznej zmiany ścieżki.

3. Sprawdzenie rzeczywistego odtwarzania

Informacje o aktywnej sesji w panelu pokazują tryb odtwarzania i przyczynę konwersji. Reprezentatywne pliki testowe powinny obejmować różne kodeki, ścieżki dźwiękowe, formaty napisów i skoki bitrate. Nawet klient obsługujący HEVC może wymagać konwersji wideo z powodu profilu, rozdzielczości, limitu bitrate lub wtapiania napisów.

Przy konwersji log FFmpeg w zamontowanym katalogu konfiguracji pokazuje wybrane strumienie i kodeki. copy jako wyjściowy kodek wideo oznacza brak ponownego kodowania obrazu; dźwięk nadal może być konwertowany. libx264 oznacza programowe kodowanie H.264, ale nie jest jedynym możliwym koderem. Direct Play nie musi tworzyć logu transkodowania.

Samo obciążenie CPU nie potwierdza akceleracji sprzętowej. Więcej informacji daje łączna ocena tempa konwersji, pozostałego bufora odtwarzania, oczekiwania na nośnik, temperatury i przepustowości sieci. Jeśli przetworzenie minuty filmu trwa dłużej niż minutę, konwersja nie nadąży stale za odtwarzaniem. Ogólne polecenie hosta, takie jak ffmpeg -hwaccel drm, nie dowodzi integracji z Jellyfin ani użycia konkretnego dekodera sprzętowego.