같은 동영상인데 컴퓨터에서는 재생되고 휴대폰에서는 열리지 않을 때: 층별 점검 목록(각 층에 실측값 포함)

컴퓨터에서는 열리고 휴대폰에서는 열리지 않을 때, 원인은 대개 화질도 파일 손상도 아닙니다. 실제로 첫 프레임을 그리기 전에 네 개의 층이 각자 판단하고, 어느 한 층이라도 통과하지 못하면 보이는 결과는 언제나 같습니다 — 「열리지 않음」. 그래서 올바른 첫걸음은 다른 도구로 다시 압축하는 것이 아니라 파일을 읽어서 어느 층이 막았는지 판단하는 것입니다.

1. 화면이 한 프레임도 보이기 전에 네 층이 각자 결정됩니다

• 컨테이너. 기기가 이 파일을 열 생각이 있는지 — 여기서 결정되는 것은 「열리느냐」이지 「좋으냐」가 아닙니다.
• 화면 트랙의 라벨. 같은 HEVC 화면도 MP4 계열 컨테이너에는 서로 다른 두 가지 선언으로 적힐 수 있습니다. 두 파일의 화면은 바이트 단위로 완전히 같아도 동작은 정반대가 될 수 있습니다.
• 오디오 트랙. 화면이 모두 맞아도 오디오 트랙 하나 때문에 파일 전체가 거부되거나 열려도 소리가 없을 수 있습니다.
• 자막 트랙. 텍스트 자막과 그래픽 자막은 서로 다른 데이터이고, MP4의 자막 트랙은 텍스트를 기준으로 만들어집니다.

네 개의 층은 각각 따로 판단하므로 증상도 따로 나타납니다. 컨테이너가 맞지 않으면 아예 열리지 않고, 라벨이 맞지 않으면 열려도 화면이 움직이지 않으며, 오디오가 맞지 않으면 열려도 소리가 없고, 자막이 맞지 않으면 영상은 멀쩡한데 자막만 사라집니다. 네 증상을 「이 도구는 못 쓴다」로 뭉개는 것이 이 종류 제품에서 가장 흔한 오해입니다.

2. 첫걸음은 파일을 읽는 것이지 도구를 바꾸는 것이 아닙니다

한 층을 읽고 한 층을 보세요. 파일 안의 구조를 목록으로 뽑을 수 있는 검사 도구라면 컨테이너, 트랙별 코덱 이름, 트랙 라벨, 비트 심도, 픽셀 형식, 길이, 바이트 수를 나눠 적어 줍니다. 여기서 쓰는 몇 분은 나중에 몇 시간씩 반복하는 재시도를 대신 없애 줍니다.

아래 측정값은 모두 같은 기기에서의 같은 점검에서 가져왔고, 환경은 8절에 적혀 있습니다.

두 파일은 길이가 두 분인 같은 화면에서 나왔고, 프레임을 하나도 다시 인코딩하지 않아 바이트 수가 똑같습니다. 유일한 차이는 그 네 글자의 트랙 라벨입니다.

확장자를 바꿔도 위의 어느 층도 바뀌지 않고, 높은 비트율로 화면을 다시 압축해도 막은 그 층은 그대로입니다. 위치를 먼저 정하고 손대십시오.

3. 라벨이라는 층: 같은 화면, 두 가지 표기

MP4 계열 컨테이너에서 HEVC는 hvc1 또는 hev1로 선언됩니다. 차이는 디코딩 구성을 어디에 쓰느냐입니다. hvc1은 이를 트랙의 샘플 서술자에 써 넣으므로 읽는 쪽이 첫 프레임을 만나기 전에 디코더를 준비할 수 있고, hev1은 이 데이터가 스트림과 함께 전달되는 것을 허락합니다. 시작 전에 구성을 받아야 하는 읽는 쪽은 중간에 나타나기를 기다리지 않습니다.

이 층은 프레임을 다시 압축할 필요가 없습니다. 화면을 복사로 옮겨 가고 트랙 라벨만 다시 씁니다. 위의 두 샘플이 바로 그렇게 만든 것입니다 — 같은 화면을 두 번 적었더니 결과물이 바이트 단위로 같은 길이가 되었습니다.

이 층의 비용을 기억할 가치가 있습니다. 이것은 복사 한 번이지 재압축 한 번이 아닙니다. 범위를 이 층에서 좁힐 수 있는 문제는 재인코딩을 써서는 안 됩니다.

4. 오디오라는 층: 화면이 완벽해도 오디오 트랙 하나에 묶입니다

화면이 통과된 뒤에는 「재생되는지, 소리가 나는지」를 결정하는 것이 오디오 트랙만 남습니다. 이 계열의 실제 범위는 대다수가 아는 것보다 넓습니다. 같은 묶음의 소재에서 TrueHD, E-AC3, AC-3, Opus, FLAC, MP2, MP3, DTS, PCM이 한꺼번에 나온 적이 있습니다.

두 경로에서 모두 화면을 다시 압축하지 않았고 차이는 전부 오디오에 있습니다. 하나는 다시 써야 하고 하나는 그대로 옮겨 갈 수 있습니다. 또한 트랙을 하나씩 세어 봐야만 알게 되는 사실이 있습니다 — 첫 번째 오디오 트랙만 점검하는 방식은 「열리는데 고요한」 파일을 만듭니다. 여러 언어의 영상에서 필요한 언어는 대개 두 번째 자리에 앉아 있습니다.

5. 자막이라는 층: 텍스트와 그림은 서로 다른 데이터

SRT, ASS 같은 텍스트 계열은 대상 컨테이너에 들어가도 여전히 텍스트이고, 글자크기와 색은 계속 사용자가 바꿉니다. 그림 계열 — 블루레이에서 페이지마다 그림으로 압축된 자막, 그리고 DVD와 셋톱박스 녹화에 들어 있는 자막 — 의 실체는 자막의 사진입니다. MP4의 자막 트랙은 텍스트를 기준으로 만들어지므로 그림을 담을 자리가 없습니다.

쓸 수 있는 방법은 두 가지입니다. 그림 속 글자를 텍스트로 인식해 옮겨 가거나(인식은 능력이지 보증이 아니고, 인식한 글자에 오류가 있을 수 있으니 넘기기 전에 확인해야 합니다), 그 자막을 포기하는 방법입니다. 화면은 픽셀 하나도 건드리지 않고 글자를 화면에 굽지도 않습니다 — 그렇게 하면 새 화면 트랙 하나가 나오지 원래 영상이 남는 것이 아닙니다.

「자막을 지원하나요」라는 물음은 의미가 없습니다. 물어야 하는 것은 이것입니다. 이 트랙이 텍스트인지 그림인지, 그리고 변환 후에도 같은 종류로 남는지.

6. 파일은 읽을 수 있어도 기기는 읽을 수 없습니다

이 목록은 「어느 층을 만져야 하는지」까지는 데려갑니다. 특정 기기가 받아들이는지는 대신 결정하지 않습니다. 비트 심도와 프로파일, 색 표시, 프레임 속도, 4:2:2, 긴 GOP 같은 조건은 실제 기기에서야 답이 나옵니다. 같은 묶음의 샘플에 Main 10과 Main 8이 함께 있고 색 표시도 있는 것과 없는 것이 나뉩니다 — 이런 차이는 파일에서는 읽히지만 기기에 가야 알 수 있습니다.

• 「HEVC입니다」라는 한마디는 답이 아닙니다. 라벨, 비트 심도, 오디오, 자막을 모두 읽어야 범위를 한두 층으로 좁힐 수 있습니다.
• 같은 화면을 다른 상자로 돌려 봤다고 이 상자로 돌려 본 것은 아닙니다 — 컨테이너와 코덱은 서로 다른 두 변수입니다.
• 짧은 샘플은 구조를 증명할 뿐, 파일 크기와 화질 동작을 증명하지 못합니다. 이런 결론은 긴 영상과 실제 기기에서 나와야 합니다.
• 어떤 「기기 표」도 그대로 믿으면 안 됩니다. 이 페이지도 마찬가지입니다. 자기 파일로 그 기기에서 한 번 재생해 보는 것이 유일하게 인정되는 확인입니다. 측정으로 확인한 컨테이너와 코덱 목록은 여기에 있습니다.

7. 그대로 따라 하는 점검 순서

1. 안을 읽습니다. 컨테이너, 화면 라벨, 오디오 트랙 하나하나, 자막 트랙 하나하나를 한 번에 목록으로 뽑습니다.
2. 컨테이너 층. 파일이 대상 기기가 열려는 계열에 들지 않기만 해도 「아예 열리지 않음」은 설명됩니다. 안의 화면이 완전히 멀쩡해도 마찬가집니다.
3. 라벨 층. 컨테이너가 맞고 화면이 HEVC인데 구성을 읽지 못하면, 먼저 3절대로 라벨을 다시 쓰십시오 — 이것은 복사이지 재압축이 아닙니다.
4. 오디오 층. 모든 오디오 트랙을 목록으로 뽑으십시오. 첫 번째 트랙만 보는 것이 아닙니다. 어느 언어를 앞에 둘지는 의도한 선택이어야 하고 운에 맡길 일이 아닙니다.
5. 자막 층. 텍스트는 옮겨 갈 수 있고, 그림은 인식시키거나 포기하는 둘 중 하나입니다.
6. 마지막에 화면 재압축을 검토합니다. 라벨로도 안 되는 계열만 다시 인코딩해야 하고, 그것은 따로 더 오래 걸리는 일이며 그 자신의 파일 크기 경계가 있습니다.

순서가 틀리면 같은 기기에서 같은 실수를 세 번 반복하게 됩니다.

8. 이 페이지의 측정값은 어디서 나왔고, 우리는 무엇을 하는가

위의 모든 숫자는 같은 기기에서의 한 차례 점검에서 가져왔습니다. Apple M2, macOS 27.2, 명령줄 검사 도구 9.0.2 환경이고, 샘플은 직접 만든 시험 꾸러미에서 나왔습니다. B와 C는 같은 자체 제작 화면을 복사로 두 번 적어 만든 것이며(원본은 우리가 직접 만든, 길이 2분짜리 테스트 파일입니다: HEVC Main 10, 1920×1080, yuv420p10le, AAC 오디오 트랙 하나, 읽어 들이면 14,956,756 바이트. B와 C는 그 영상을 그대로 두 개의 mp4에 복사해 트랙 라벨만 다시 붙였고, 바이트수는 위 표에 있습니다), G부터 L까지는 디스크 시대 오디오와 자막 형식을 상대로 만든 시험 파일입니다. 이 페이지는 어떤 샘플 파일도 재배포하지 않습니다 — 위의 각 계열 구조는 이미 가지고 있는 소재로 직접 다시 만들 수 있습니다.

만드는 제품은 iPhone, iPad, Mac용이고 결과물 컨테이너는 MP4 하나뿐입니다. 비트율, 인코더, 해상도 같은 조절 항목은 없습니다. 대신 내리는 결정은 셋 중 하나뿐 — 컨테이너만 바꾸기, 컨테이너를 바꾸면서 오디오를 다시 쓰기, 화면을 다시 인코딩하기입니다. 애초에 바로 재생되는 파일은 변환으로 치지 않습니다. 앱은 두 번째 파일을 만들지 않고 횟수에도 넣지 않습니다. 유료 형태는 일회성 구매이고(이 구매 항목은 제품 안에서 Opus라고 불립니다) 바뀌는 것은 그다음 몇 번 더 변환할 수 있는가뿐이며, 이 이야기는 여기 적혀 있습니다.

• DRM으로 보호된 콘텐츠는 처리하지 않습니다. 상점에서 빌려 왔거나 산 영상도 마찬가집니다.
• 애초에 텍스트가 아니었던 자막은 텍스트로 인식시킬 수 있습니다. 인식에는 오류가 생길 수 있고, 화면은 그대로 두며 글자를 화면에 굽지 않습니다.
• 자막을 다시 만들 때는 간체와 번체의 구분이 사라집니다.
• 화면을 다시 압축하는 경로에서는 결과물이 원본보다 커지면 막아 두고, 그대로 넘기지 않습니다.
• 처리는 이 기기 안에서 끝나고 파일 자체를 다른 곳에 넘길 필요가 없습니다. Mac판과 iPhone판은 같은 화면이 아니므로 같은 것처럼 굴지 않습니다.

자주 묻는 질문

.mkv 이름을 .mp4로 바꾸면 되나요?

안 됩니다. 이 절차는 원래 지름길이 아닙니다. 확장자는 라벨일 뿐이고, 라벨을 바꿔도 컨테이너 안의 구조는 다시 쓰이지 않으며 화면 코덱도 바뀌지 않습니다. 기기가 파일을 열 때 읽는 것은 안의 구조이지 파일 이름이 아닙니다. 이름을 바꾼 뒤에 「열린다」는 확률은 변하지 않고, 어느 층에서 문제가 났는지 판단할 기회만 잃습니다.

라벨만 다시 쓰면 파일이 다른 것이 되나요?

되지 않습니다. 위의 두 샘플을 읽으면 바이트 수가 완전히 같습니다(둘 다 12,973,400). 화면은 프레임을 하나도 다시 압축하지 않았습니다. 이것이 바로 이 층의 값어치입니다. 복사 한 번으로 끝나는 층을 재인코딩으로 시험하면 안 됩니다.

영상에 오디오 트랙이 다섯 개인데, 하나만 남나요?

트랙은 하나씩 판단하고 파일 전체에 하나의 결론을 얹지 않습니다. 옮겨 갈 수 있는 것은 트랙대로 옮겨 가고, 못 옮기는 그 트랙은 재인코딩으로 갑니다. 진짜로 「하나만 남는」 상황을 만드는 것은 첫 번째 오디오 트랙만 보는 일입니다. 여러 언어의 영상은 손대기 전에 필요한 언어가 몇 번째에 있는지 먼저 세어 보십시오.

그래픽 자막을 그대로 MP4에 넣을 수 있나요?

안 됩니다. MP4의 자막 트랙은 텍스트를 기준으로 만들어지고, 그림 계열은 들어갈 자리가 없습니다. 쓸 수 있는 방법은 두 가지뿐입니다. 텍스트로 인식한 뒤 옮겨 가거나(오류가 있을 수 있으니 확인해야 합니다), 그 자막을 포기하는 것입니다. 원래 그림을 지켜 하면서 텍스트 트랙에 넣는 세 번째 방법은 없습니다.

이 측정값을 내 기기에서 다시 계산할 수 있나요?

읽는 것은 파일 안이므로 어떤 기기에서든 다시 계산할 수 있습니다. 손에 있는 파일에 무엇이 들었는지는 검사 도구가 목록으로 뽑아 냅니다. 다시 계산할 수 없는 것은 뒷부분뿐입니다. 기기 쪽이 받아들이는지는 실제 재생 한 번으로만 알 수 있습니다. 이 페이지가 주는 것은 판단 순서이고, 믿기를 요구하는 표가 아닙니다.

Axiom One LLC — CineX