긴 GOP 비디오는 대부분의 프레임이 완전한 이미지를 포함하지 않기 때문에 탐색 속도를 늦춥니다. 시청자가 새로운 시간으로 점프할 때 플레이어는 종종 더 이전의 독립적으로 디코딩 가능한 프레임을 찾아 그 지점과 요청된 이미지 사이의 종속 프레임을 재구성해야 합니다.
홈 미디어 서버는 Direct Play 중에 파일을 읽고 전달만 할 수 있으며, 실제 디코딩은 클라이언트가 수행합니다. 서버가 트랜스코딩을 할 경우, 새로운 출력 스트림을 생성하기 전에 동일한 종속성 재구성을 수행해야 하므로 탐색 비용이 저장소와 컴퓨팅 모두에서 더 커집니다.
긴 GOP가 독립 프레임과 다른 점은 무엇인가요?
긴 GOP는 이전 참조 프레임에 의존합니다. I 또는 IDR 프레임은 독립적으로 디코딩 가능한 이미지를 포함하고, P와 B 프레임은 다른 프레임에 대한 변경이나 예측을 저장합니다.
독립 프레임 간 간격이 길수록 인코더는 반복되는 시각 정보를 모션과 차이 데이터로 표현할 기회가 많아집니다. 그 결과 스트림은 완전한 이미지를 더 자주 삽입하는 스트림보다 작아질 수 있습니다.
그 이유는 시간적 종속성 때문입니다. 42분에 있는 압축된 프레임은 그 자체로는 의미가 없을 수 있는데, 픽셀이 디코더 참조 버퍼에 보관된 하나 이상의 이전에 디코딩된 이미지에 의존하기 때문입니다.
플레이어가 요청된 아무 프레임에서나 시작할 수 없는 이유는 무엇인가요?
무작위 점프 시 탐색은 보통 키프레임에서 시작됩니다. 디멀티플렉서는 정확한 목표 프레임을 독립적인 이미지로 처리하지 않고 인덱스를 사용해 근처의 랜덤 액세스 포인트를 찾습니다.
디코더는 그 지점부터 요청된 프레젠테이션 타임스탬프를 재구성할 때까지 앞으로 진행합니다. 키프레임 바로 다음의 목표는 프리롤이 거의 필요 없지만, 긴 GOP의 끝 근처 목표는 많은 프레임을 처리하고 버려야 할 수 있습니다.
오픈 GOP 구조와 프레임 재정렬은 더 많은 종속성 복잡성을 추가할 수 있습니다. 탐색 후 처음 표시되는 프레임은 프레젠테이션 순서가 달라도 디코딩 순서상 더 앞에 나타나는 참조가 필요할 수 있습니다.
디코더 프리롤 동안 어떤 작업이 이루어지나요?
요청된 이미지가 나타나기 전에 종속 프레임을 표시 전에 디코딩해야 합니다. 클라이언트나 트랜스코더는 압축된 패킷을 읽고, 참조 프레임을 재구성하며, 출력 순서를 재정렬하고, 목표 프레임보다 이전의 프레임은 버립니다.
스토리지 지연 시간은 패킷을 찾아 읽어야 하기 때문에 중요하지만, 작업 부하는 단순한 대용량 순차 전송이 아닙니다. 반복적인 스크럽은 많은 작은 범위를 요청하고 유용한 캐시 데이터를 축출하며 디코더가 다른 접근 지점에서 계속 재시작하게 만듭니다.
트랜스코딩은 서버 측 디코드 및 인코드 작업을 추가합니다. 탐색으로 인해 트랜스코딩이 재시작되면 서버는 디코더 상태를 재구성하고 출력 버퍼를 다시 채우며 인코더가 새 재생 가능한 세그먼트를 생성할 때까지 기다릴 수 있습니다.
컨테이너 인덱스와 스트리밍 세그먼트가 지연에 어떻게 영향을 미칠까요?
좋은 파일 인덱스는 타임스탬프를 바이트 위치에 매핑하며, 세그먼트 경계는 키프레임과 함께 작동할 때 가장 좋습니다. 정확한 인덱싱이 없으면 플레이어가 사용 가능한 접근 지점을 찾기 위해 더 많은 패킷을 스캔할 수 있습니다.
HLS 또는 DASH의 경우, 서버와 클라이언트는 임의 바이트 위치보다 세그먼트 단위로 탐색하는 경우가 많습니다. 깨끗한 키프레임으로 시작하는 세그먼트는 독립적으로 시작할 수 있지만, 정렬이 맞지 않는 세그먼트는 이전 세그먼트의 데이터에 의존할 수 있습니다.
관찰된 탐색 지연은 따라서 GOP 거리, 인덱스 품질, 세그먼트 길이, 네트워크 왕복 시간, 클라이언트 버퍼링 및 디코더 속도를 결합한 것입니다. GOP를 단축하는 것은 그 경로의 의존성 부분만 해결합니다.
왜 미디어 라이브러리는 여전히 긴 GOP를 사용할까요?
더 긴 GOP는 압축 효율을 향상시킵니다 왜냐하면 완전한 키프레임이 일반적으로 예측 프레임보다 크기 때문입니다. 키프레임 수가 적으면 비슷한 시각적 품질을 더 낮은 평균 비트레이트로 유지할 수 있습니다.
비트레이트가 낮아지면 라이브러리 크기, 디스크 읽기, 네트워크 트래픽 및 원격 업로드 요구가 줄어듭니다. 일반 영화 재생의 경우, 1~2초의 임의 접근 간격은 시청자가 지속적으로 탐색하지 않기 때문에 허용될 수 있습니다.
보안 영상, 스포츠 분석, 편집 프록시, 썸네일 또는 타임라인을 빠르게 스크럽하는 인터페이스에서는 이러한 절충이 덜 유리해집니다. 이러한 작업 흐름은 최대 압축 효율성보다 빠른 임의 접근 속도를 더 중요하게 여깁니다.
가정용 미디어 서버는 언제 짧은 GOP를 사용해야 할까요?
키프레임 간격은 비트레이트와 접근 속도 간의 균형을 이룹니다. 더 자주 깨끗한 접근 지점으로 재인코딩하면 탐색, 시작, 손상 후 복구, 적응형 스트림 전환이 개선될 수 있습니다.
한 클라이언트가 탐색을 잘 못한다고 해서 대규모 라이브러리를 재인코딩하지 마세요. 먼저 다이렉트 플레이와 트랜스코드 동작을 비교하고, 컨테이너 인덱스를 확인하며, 다른 클라이언트를 테스트하고, 느린 저장소나 원격 지연 중 어느 쪽이 더 큰 병목인지 확인하세요.
자주 검색 및 스크러빙되는 콘텐츠나 인터랙티브 재생용으로 생성된 스트리밍 버전에는 짧은 GOP를 사용하세요. 저장 공간과 대역폭 절감이 가끔의 탐색 지연보다 중요할 때는 아카이브 및 일반 시청용으로는 긴 GOP를 유지하세요.
| 비디오 패턴 | 탐색 효과 | 압축 효과 |
|---|---|---|
| 쇼트 GOP | 가까운 임의 접근 지점이 디코더 프리롤을 줄임 | 더 많은 큰 키프레임이 비트레이트를 증가시킴 |
| 롱 GOP | 점프 후 더 많은 종속 프레임이 디코딩될 수 있음 | 예측 코딩이 효율성을 향상시킴 |
| 약하거나 없는 인덱스 | 플레이어가 사용 가능한 접근 지점을 스캔할 수 있음 | 본질적인 비트레이트 이점 없음 |
| 서버 트랜스코드 | 디코더와 출력 파이프라인이 재시작될 수 있습니다 | 소스를 직접 제공하는 대신 새 스트림을 생성합니다 |
자주 묻는 질문
미디어 서버가 항상 탐색 디코딩을 수행하나요?
아닙니다. 다이렉트 플레이 중에는 서버가 요청된 바이트 범위를 읽고 전달하는 동안 클라이언트가 디코딩합니다. 트랜스코딩 시에는 서버가 소스를 디코딩하고 출력 스트림을 재구성해야 합니다.
모든 I-프레임이 완벽한 임의 접근 지점일까요?
반드시 그렇지는 않습니다. 깨끗한 IDR 또는 닫힌 GOP 경계가 더 안전한데, 그 이유는 이후 프레임이 그 이전 참조에 의존하지 않기 때문입니다. 열린 GOP 구조는 명백한 경계 너머로 종속성을 유지할 수 있습니다.
미디어 메타데이터를 SSD에 저장하면 Long-GOP 탐색이 해결될까요?
라이브러리 탐색과 인덱스 접근을 개선할 수 있지만, 비디오 내부의 프레임 종속성은 제거할 수 없습니다. 미디어 파일, 디코더, 재생 경로가 여전히 프리롤을 결정합니다.
가정용 미디어 파일에 1초 GOP를 사용해야 할까요?
전적으로 그렇지는 않습니다. 1초 GOP는 접근 속도를 개선하지만 키프레임 오버헤드를 증가시킵니다. 일반 영화 재생은 더 긴 간격을 선호할 수 있지만, 인터랙티브 스크러빙은 더 짧은 간격이 유리합니다.
최종 요점
Long-GOP 탐색이 느린 이유는 요청된 프레임이 독립적인 이미지가 아니라 종속 체인의 끝인 경우가 많기 때문입니다. 플레이어나 트랜스코더는 이전 접근 지점을 찾아 앞으로 디코딩하고 재생 상태를 다시 채워야 합니다. 더 나은 인덱스, 정렬된 세그먼트, 적합한 클라이언트, 짧은 GOP는 지연을 줄일 수 있지만, 각 변경은 압축 효율성, 저장 공간 또는 인코딩 작업을 희생하여 더 빠른 임의 접근을 가능하게 합니다.
기술 및 AI 허브
더 읽어보기

Plex 상태란 무엇이며, 어떤 부분을 영구적으로 보존해야 하나요?
영구 Plex 상태는 재시작 및 재구축 후에도 서버 환경을 유지하는 정보이며, 미디어와 임시 트랜스코딩 데이터는 별도의 역할을 합니다.

Plex는 로컬 세션과 원격 세션의 인증을 어떻게 처리하나요?
Plex 인증은 서버와 계정의 신원 확인으로 시작되며, 이후 로컬 또는 원격 네트워크 경로에 따라 연결 가능 여부와 보안 연결 동작이 결정됩니다.

라이브러리 데이터가 늘어날수록 Plex 검색이 느려지는 이유는 무엇인가요?
라이브러리 증가만으로는 원인을 진단할 수 없습니다. 데이터베이스 크기를 탓하기 전에 쿼리 형태, 인덱스, 캐시 상태, 스토리지 지연 시간, 쓰기 작업을 점검하세요.

