ZimaOS에서 16GB RAM을 탑재한 Intel N100 시스템으로 Jellyfin을 실행하던 한 사용자는 재생 동작이 뚜렷하게 나뉜다고 보고했습니다. 최대 1080p의 미디어는 정상적으로 작동했지만, 트랜스코딩이 필요한 4K 스트림에서는 CPU 사용률이 100%까지 올라가고 재생이 너무 끊겨 시청하기 어려웠습니다. Jellyfin은 Host 네트워킹으로 실행 중이었으며, 서버에는 전용 GPU가 없었습니다.
커뮤니티 논의에서는 최종적으로 확인된 단일 해결책이 나오지 않았습니다. 대신 소프트웨어 트랜스코딩, Intel 통합 그래픽, VA-API, 코덱 호환성, HDR 톤 매핑, 활성 트랜스코딩을 확인해야 할 정확한 위치를 실무적으로 검토하는 방향으로 발전했습니다. 원래 사용자는 결국 하드웨어 가속을 활성화해 하나의 트랜스코딩 스트림을 재생할 수 있었지만, CPU 사용률은 여전히 약 95~98%에 머물렀습니다.
Jellyfin에서 발생한 원래의 4K 트랜스코딩 문제
서버에는 Intel N100 프로세서와 16GB 메모리가 사용되었습니다. Jellyfin은 로컬 미디어 서버로 작동했고, Docker 네트워크 유형은 Host로 설정되어 있었습니다. 일반적인 1080p 재생에는 문제가 없었습니다.
문제는 4K 파일에 트랜스코딩이 필요할 때만 발생했습니다. 이때 프로세서 사용률이 100%까지 올라가고 재생이 끊겼으며, 스트림은 사실상 시청할 수 없는 상태가 되었습니다. 따라서 사용자는 전용 그래픽 카드 없이 트랜스코딩 성능을 향상할 수 있는 Jellyfin 설정을 알고 싶어 했습니다.
1080p와 4K의 차이는 답변에서 핵심 단서가 되었습니다. 커뮤니티 구성원들은 네트워킹과 메모리보다는 Jellyfin이 무엇을 변환하는지, N100의 통합 그래픽이 사용되는지, 선택한 클라이언트가 소스 형식을 직접 재생할 수 있는지에 더 주목했습니다.
코덱과 클라이언트 호환성이 논의에 등장한 이유
goultron은 N100급 시스템에서 4K 트랜스코딩이 특히 서버가 CPU로 전환될 때 매우 부담이 큰 작업이라고 설명했습니다. goultron은 4K 라이브러리를 유지하지 않고, 더 다양한 장치에서 직접 재생되는 H.264 미디어를 선호하는 방식을 택했습니다.
또한 답변에서는 중요한 실무적 요점을 강조했습니다. H.264 동영상이라도 어떤 형태로든 변환이 필요할 수 있다는 것입니다. 수신 장치, 지원되는 오디오 형식, 사용 가능한 네트워크 속도에 따라 최종 재생 경로가 달라질 수 있습니다. goultron은 H.264 동영상을 사용했는데도 일부 스트림이 계속 트랜스코딩된 원인이 오디오 변환일 수 있다고 추정했습니다.
이들은 H.265/HEVC를 일반적으로 사용하는 시중의 많은 4K 콘텐츠와 이를 대조했습니다. 일부 소형 재생 장치와 TV는 모든 H.265 프로필을 직접 처리하지 못할 수 있습니다. 이러한 경우 Jellyfin은 클라이언트를 위해 소스를 변환해야 하므로, 작업이 다시 서버로 돌아옵니다.
gelbuilding의 주요 진단: 먼저 N100 iGPU를 확인할 것
gelbuilding은 Jellyfin이 4K 소프트웨어 트랜스코딩을 수행하고 있다면 N100의 동작이 예상된 결과라고 보았습니다. 설명은 간단했습니다. 소형 CPU는 이 작업으로 사용률이 최고치까지 올라갈 수 있으며, 이로 인해 원래 사용자가 겪은 원활한 1080p 재생과 사용 불가능한 4K 트랜스코딩이 발생한다는 것입니다.
처음 확인할 사항은 Jellyfin이 실제로 N100에 내장된 Intel 미디어 엔진을 사용하고 있는지 여부였습니다. N100은 iGPU를 인식시키기 위해 별도의 그래픽 카드가 필요하지 않지만, Jellyfin에서 하드웨어 가속을 활성화하고 컨테이너에서 해당 장치에 액세스할 수 있어야 합니다.
답변에서 공유된 설정 경로는 다음과 같습니다.
- Jellyfin 관리 인터페이스를 엽니다.
- 재생을 엽니다.
- 트랜스코딩을 엽니다.
- 하드웨어 가속을 활성화합니다.
- 이 스레드에서 설명한 구성에는 VA-API를 선택합니다.
예상되는 결과는 작업이 CPU의 소프트웨어 처리에서 벗어나 Intel iGPU로 이동하는 것이었습니다. gelbuilding은 N100 iGPU가 모든 4K 소스를 원활하게 변환할 수 있다고 기대해서는 안 된다고도 경고했습니다. 특히 일부 고비트레이트 HEVC 파일은 소프트웨어 처리로 다시 전환될 수 있는 작업이라고 지적했습니다.
커뮤니티에서 VA-API 확인 위치를 바로잡다
처음 답변에서는 대시보드 → 활동에서 H.264 또는 HEVC VA-API 레이블을 확인하라고 제안했습니다. goultron은 Jellyfin 10.10.7에서 이 안내를 테스트했고, Activity 페이지에는 VideoPlayback 및 VideoPlaybackStopped와 같은 이벤트만 표시된다는 사실을 확인했습니다.
그 후 gelbuilding은 안내를 수정했습니다. Activity 페이지에 트랜스코딩이 VA-API를 사용했는지 소프트웨어 방식을 사용했는지가 표시될 것으로 예상한 것은 잘못이었습니다. 관련 정보는 4K 스트림이 다음 경로에서 실제로 트랜스코딩되는 동안 확인해야 합니다:
- 대시보드
- 재생
- 트랜스코딩
활성 세션에는 코덱 아래에 한 줄이 표시되어야 합니다. VA-API 레이블은 하드웨어 가속이 사용되고 있음을 나타내고, Software 레이블은 CPU가 변환을 수행하고 있음을 나타냅니다. 트랜스코딩 영역이 비어 있다면 파일이 직접 재생(Direct Playing) 또는 직접 스트리밍(Direct Streaming) 중일 수 있으며, 이는 현재 활성화된 비디오 트랜스코딩이 이루어지지 않는다는 뜻입니다.
btop이 이 스레드에 명확한 답을 제시하지 못한 이유
goultron은 btop을 통해 iGPU 활동도 확인해 보았습니다. Intel iGPU는 GPU 영역에 명확하게 표시되지 않았지만, 동일한 iGPU는 이미 Frigate에 성공적으로 전달되었고 Frigate에는 해당 장치를 사용 중이라고 표시되었습니다.
gelbuilding은 이 ZimaOS 환경에서 btop이 주로 전용 GPU를 표시하므로 Intel iGPU가 활성화되어 있어도 표시하지 못할 수 있다고 답변했습니다. 이를 근거로 Jellyfin의 활성 트랜스코딩 화면을 직접적인 확인 방법으로 사용하라고 권장했습니다.
Zima-Jerry는 이후 GPU 사용량을 확인하는 데 btop을 사용할 수 있다고 덧붙였습니다. 그러나 토론이 끝날 때까지 이 두 진술은 조정되지 않았습니다. 따라서 해당 커뮤니티 스레드는 btop을 추가 관찰 도구로 사용할 수 있다는 점은 뒷받침하지만, 유일한 증거로 삼아서는 안 됩니다. VA-API 처리인지 소프트웨어 처리인지 확인하려면 Jellyfin의 활성 트랜스코딩 정보가 여전히 필요합니다.
Zima-Jerry의 HDR 톤 매핑 구성
Zima-Jerry는 Intel N100에서 Jellyfin 하드웨어 가속과 HDR 톤 매핑에 초점을 맞춘 또 다른 커뮤니티 구성을 공유했습니다. 당시에는 App Store에서 제공되는 Jellyfin 버전에 색조 변환 문제가 있다고 보고되었습니다.
제안된 대안은 nyanmisaka Jellyfin 컨테이너 이미지와 사용자 지정 YAML 구성을 함께 사용하는 것이었습니다. 이는 당시 사용되던 Jellyfin 및 ZimaOS 버전에 맞춘 커뮤니티 우회 방법이므로, 기존 설치를 교체하기 전에 현재 App Store 버전과 비교해야 합니다.
관련 게시물에서 공유된 결과가 4K 트랜스코딩을 무제한으로 지원한다는 의미는 아니었습니다. Zima-Jerry는 테스트한 구성에서 N100 내장 그래픽이 약 4K 30fps 이하의 Dolby Vision 비디오를 원활하게 변환할 수 있다고 추정했습니다.
원래 사용자가 하드웨어 가속을 활성화한 후 변경된 사항
답변을 검토한 후 Heimwerkerking은 트랜스코딩 하드웨어 가속을 활성화했습니다. 그 결과 눈에 띄는 개선이 이루어졌고, 최소 한 개의 트랜스코딩 스트림을 재생할 수 있게 되었습니다.
대시보드에 표시된 활성 재생 정보는 다음과 같았습니다. 48.7Mbps MP4 H264 AAC그러나 CPU 사용량은 95%에서 98% 사이를 유지했기 때문에, 사용자는 여전히 Intel iGPU가 실제로 비디오 변환을 처리하고 있는지 확신하지 못했습니다.
이 결과만으로 문제가 완전히 해결되었다고 입증할 수는 없습니다. 구성 변경으로 재생이 개선되었음을 보여주었지만, 스레드에는 확인된 VA-API 레이블, 전체 FFmpeg 결과, 또는 일관되게 해석된 iGPU 수치가 여전히 없었습니다. 마지막 답변에서도 btop으로 GPU 사용량을 관찰하라고 다시 제안했으며, 이후 확인 내용은 게시되지 않았습니다.
이 커뮤니티 스레드가 실제로 확인한 내용
이 토론은 N100의 CPU 사용률이 100%에 도달한 첫 번째 원인이 소프트웨어 4K 트랜스코딩일 가능성이 높다는 점을 강하게 뒷받침합니다. 또한 Activity 기록이 아니라 Jellyfin의 Playback 및 Transcoding 영역에서 4K 트랜스코딩을 시작한 뒤 활성 세션을 확인해야 한다는 올바른 검증 방법도 제시합니다.
답변에서는 몇 가지 작업 부하의 한계도 설명했습니다. H.265 클라이언트 호환성, 오디오 변환, 높은 소스 비트레이트, HDR 톤 매핑, 그리고 사용 중인 Jellyfin 컨테이너에 따라 결과가 달라질 수 있습니다. VA-API를 활성화하면 원래 사용자가 트랜스코딩된 스트림 하나를 재생하는 데는 도움이 되었지만, CPU 사용률은 여전히 높았습니다.
이 스레드만으로는 N100이 처리할 수 있는 스트림 수를 보편적으로 확정하거나 Intel Arc GPU가 필요하다는 사실을 입증할 수 없습니다. gelbuilding은 안정적인 4K 변환이 여전히 필요한 사용자를 위한 다음 단계로 소스 비트레이트를 낮추거나 소형 Intel Arc GPU를 추가하는 두 가지 가능성을 제시했습니다. 원 게시자가 두 선택지 중 어느 것도 테스트하기 전에 토론이 종료되었습니다.
커뮤니티 토론 FAQ
1080p는 작동했는데 4K 트랜스코딩은 왜 끊겼나요?
커뮤니티는 4K 파일을 변환해야 할 때 발생하는 훨씬 더 높은 소프트웨어 작업량 때문에 차이가 생겼다고 보았습니다. 원래 N100은 이 과정에서 CPU 사용률이 100%에 도달했습니다.
Jellyfin에서 VA-API는 어디에서 확인해야 하나요?
트랜스코딩을 강제하는 4K 스트림을 시작한 다음 Dashboard, Playback, Transcoding에서 활성 세션을 확인하세요. Activity 이벤트 기록에는 필요한 VA-API 또는 Software 레이블이 표시되지 않는 것으로 확인되었습니다.
활성 트랜스코딩 화면이 비어 있다는 것은 무엇을 의미하나요?
gelbuilding의 정정에 따르면, 이는 파일이 Direct Playing 또는 Direct Streaming 상태이며 현재 비디오 트랜스코딩이 활성화되지 않았다는 의미일 수 있습니다.
하드웨어 가속을 활성화하면 이 문제가 완전히 해결되었나요?
아니요. 트랜스코딩된 스트림 하나를 재생할 수 있게 되었지만, 보고된 CPU 사용률은 여전히 95~98%였고, iGPU가 전체 파이프라인을 처리했다는 최종 확인 없이 스레드가 종료되었습니다.
4K가 계속 불안정하다면 커뮤니티에서는 어떤 선택지를 제안했나요?
실용적인 경우 호환성이 높은 H.264 미디어를 우선 사용하고, 4K 소스 비트레이트를 낮추거나, Zima-Jerry가 공유한 사용자 지정 Jellyfin 구성을 테스트하거나, 더 강력한 하드웨어 트랜스코딩 경로를 위해 소형 Intel Arc GPU를 추가하라는 제안이 있었습니다.
