10-bit, 4:2:2 동영상은 변환 후 어떻게 되나: 화면을 다시 압축하느냐에 달려 있습니다
가장 중요한 말을 먼저 놓습니다. 화면을 다시 압축할 필요가 없으면 10-bit과 HDR 정보가 그대로 따라 가고, 화면을 다시 압축해야 하면 넘기는 모양은 원본 비트 심도를 따라 최대 10-bit에 크로마 서브샘플링 4:2:0입니다. 두 길 중 어느 곳을 갈지는 CineX가 스스로 판단하고, 그 판단 기준은 CineX는 왜 어떤 동영상은 빠르고 어떤 동영상은 더 오래 걸리는가에 적혀 있습니다 — 같은 파일이라도 다시 인코딩이 필요한지는 안의 화면 코덱이 정하지, 확장자가 정하지 않습니다.
1. 「다시 압축하지 않는」 경로는 왜 아무것도 바뀌지 않는가
HEVC 10-bit(HDR10 같은 종류 포함), H.264 Hi10P 화면은 기기 쪽에서 애초에 읽을 수 있으면 CineX는 「다시 그리기」가 아니라 「옮기기만」 합니다. 픽셀 데이터는 한 바이트도 새로 만들지 않으므로 비트 심도, 색 샘플링, 밝기 범위가 모두 그대로 남습니다. 이런 파일은 대개 몇 초에 끝나고, 빠른 이유는 화면을 다시 압축하지 않기 때문입니다.
화면을 다시 그리지 않은 상황에서 「화질이 떨어지는가」를 따지는 것은 의미가 없습니다 — 손대지 않았기 때문입니다.
2. 다시 압축해야 할 때: 비트 심도는 원본을 따라, 최대 10-bit, 크로마 서브샘플링은 4:2:0
화면을 반드시 다시 인코딩해야 할 때(예를 들어 원본이 VP9, AV1, Xvid처럼 기기가 바로 읽을 수 없는 화면인 경우), 비트 심도는 스스로 내려가지 않습니다. 원본이 10-bit(HDR 계열의 PQ／HLG 전달 함수 포함)이면 10-bit으로 넘기고, 원본이 12-bit이면 10-bit으로 내립니다. 4:2:2와 4:4:4의 크로마 서브샘플링은 4:2:0으로 통일되지만 비트 심도는 지켜집니다. 8-bit으로 넘어가는 경우는 두 가지뿐입니다. 원본이 애초에 8-bit인 경우, 그리고 파일에서 비트 심도 정보를 읽을 수 없는 경우입니다. 바뀌는 것은 크로마 서브샘플링이라는 층입니다 — 10-bit의 계조 정밀도는 픽셀에 남지만, 4:2:2의 크로마 서브샘플링은 픽셀에 남지 않습니다.
왜 크로마 서브샘플링을 4:2:0으로 통일하고 12-bit은 10-bit까지만 내리는가: 이것은 CineX가 정한 출력 기준선입니다. 결과물은 통과 근거가 확인된 사양인 HEVC Main 10, 4:2:0으로만 만들고 더 넓은 사양은 시도하지 않습니다. 이것은 선택이지 관리 소홀이 아니며, 이를 되돌릴 수 있는 항목은 없습니다 — CineX는 파라미터가 없고 화질 등급을 제공하지 않습니다.
3. 이 유형에서 HDR과 Dolby Vision의 결과는 다릅니다
여기서는 비트 심도와 바로 이어지는 결론 하나만 남깁니다. 다시 인코딩하는 경로는 원본 비트 심도를 따라 넘기되 최대 10-bit입니다. 돌비 비전 계열 정보가 화면을 따라간다는 말은 컨테이너만 바꾸는 경로에 대해서만 했습니다. 다시 인코딩한 뒤에 무엇이 남는지는 검증하지 않았으니 어느 쪽으로도 약속처럼 적지 않습니다. 색 표시(전달 곡선, 색 영역 계열)는 출처를 따라 있어서 있으면 실어 보내고 없으면 채우지 않습니다. 그래서 「표시가 있다」와 「효과가 있다」는 다른 일이고, 돌비 비전과 HDR10을 나눠서 다뤄야 합니다.
4. 10-bit라고 항상 느린 것은 아니지만, 시간을 두어야 할 경우가 하나 있습니다
10-bit H.264(Hi10P)와 10-bit HEVC는 모두 실제 기기 샘플로 통과를 확인한 입력 범위 안에 들어 있습니다. 시간을 두어야 하는 것은 극단적인 경우입니다. 프레임 속도와 해상도가 높은 화면이 전체 변환 경로를 타면, 기다리는 시간은 소재 길이를 기준으로 정해지고 보통 소재 자체보다 더 깁니다. 이런 「못 기다리는」 파일은 다른 도구로 바꾸기 전에 정말로 다시 압축이 필요한지 먼저 보는 것이 대개 더 효과적입니다.
느려지게 하는 것은 언제나 「10-bit」라는 숫자가 아니라, 화면을 다시 그려야 하는지의 문제입니다. 다시 그리지 않는 종류는 비트 심도를 원본대로 지켜 두지만, 다시 그리는 종류는 원본 비트 심도를 따라 최대 10-bit으로 처리한 4:2:0 화면을 넘깁니다 — 시간을 두어야 하는 것은 후자입니다.
5. 미리 알아야 할 경계
- 이 글이 다루는 것은 세 갈래 길의 각각의 규칙입니다. 10-bit과 HDR이 「다시 인코딩하지 않는」 계열에서 어떻게 동작하는지는 실제 기기 샘플의 뒷받침이 있고, 12-bit과 4:2:2에도 각각 실제 기기 측정값이 하나씩 있습니다(12-bit은 10-bit으로 내리고, 4:2:2의 크로마 서브샘플링은 4:2:0으로 내려가되 비트 심도는 지켜집니다). 이 계열의 항목별 회귀 검증은 iOS에서 아직 끝나지 않았으므로 ⇒ 여기서는 10-bit을 넘기는 모양으로만 말하고 판매 문구로 쓰지 않습니다. 반드시 필요한 조건으로 여기는 사람은 먼저 자기 파일로 한 번 확인해 보십시오.
- 다시 압축하면 화면이 바뀌는 사실을 부정하지 않으며, 「원본 그대로」 옵션도 제공하지 않습니다.
- 비트 심도와 색은 「변환 실패」의 신호가 아닙니다. 결과물은 그대로 재생되고, 크로마 서브샘플링을 4:2:0으로 통일하는 것은 이 경로의 규칙이지 고장난 것이 아닙니다.
- 전체 변환에는 충분한 여유 공간도 남겨 두어야 합니다(디스크 사용 최대치는 원본 파일의 두 배를 넘지 않고, 컨테이너만 바꿀 때는 결과물 하나의 공간이면 충분합니다). 이유는 비디오 변환에 여유 공간이 더 필요한 이유에 적혀 있습니다.
자주 묻는 질문
제 HEVC 10-bit 영화도 8-bit로 강등되나요?
그렇지 않습니다. 기기가 이 화면을 바로 읽을 수 있으면 CineX는 컨테이너만 바꾸고 픽셀에는 손대지 않으며 10-bit은 그대로 남습니다. 다시 인코딩이 필요할 때도 비트 심도를 내려놓지 않아, 10-bit 원본은 10-bit으로 넘깁니다. 원본이 애초에 8-bit이거나 파일에서 비트 심도 정보를 읽을 수 없을 때만 결과물이 8-bit이 됩니다.
변환 후에도 HDR 표시가 남아 있는데 화면은 왜 회색빛으로 보일까요?
희끄무레해지는 문제는 대개 결과물이 망가져서가 아니라, 보이는 쪽에서 HDR 계열 밝기 정보를 어떻게 다루는지에서 생깁니다. 다시 인코딩하는 경로는 4:2:0으로 통일해 넘기고 색 표시는 출처를 따라 그대로 실어 보냅니다. 「표시가 있다」는 「효과가 있다」와 같지 않고, 올바른 방법은 그것을 지원할 수 있는 경로에 원본 파일을 남겨 두는 것입니다.
10-bit 출력을 유지하게 할 방법이 있나요?
별도로 설정할 필요도 없고 설정할 수도 없습니다. 다시 인코딩할 때 비트 심도는 애초에 원본을 따라 정해지므로, 10-bit 원본은 10-bit으로 넘기고 8-bit 원본은 지켜 주고 싶다고 해서 10-bit이 되지 않습니다. CineX는 파라미터가 없습니다. 화질 등급, 비트 심도 선택, 목표 파일 크기를 제공하지 않습니다.
10-bit 변환은 항상 아주 느린가요?
그렇지 않습니다. 느린 쪽은 「반드시 다시 압축해야」 하는 데다 프레임 속도와 해상도까지 높은 계열뿐입니다. 많은 10-bit 파일은 다시 인코딩하지 않는 경로를 타서 몇 초면 끝납니다.
Axiom One LLC — CineX