paper&honey

직접 실험·검증한 가이드

작성 paper&honey 운영자 게시 수정

아이폰 MOV를 MP4로 — H.264는 리먹스, HEVC 미지원 환경은 재인코딩

아이폰으로 찍은 영상(.mov)을 회사 PC나 편집 프로그램이 받아주지 않아 변환기를 찾게 되는데, 60MB짜리 1분 영상 하나를 통째로 다시 압축하는 데 시간이 걸리고, 그러는 사이 화질이 깎이지는 않을지 신경 쓰입니다. 결론은 파일 안의 코덱에 따라 갈립니다. H.264라면 껍데기(컨테이너)만 바꾸는 리먹스로 수초 만에 무손실 변환할 수 있지만, HEVC를 못 읽는 프로그램에 맞추려는 목적이라면 H.264 재인코딩이 필요합니다. 두 경우를 ffmpeg로 직접 재봤습니다.

MOV 안의 코덱 할 일 결과
H.264(AVC) MP4로 리먹스 빠름 · 화질 손실 없음
HEVC(H.265), 상대 프로그램이 미지원 H.264로 재인코딩 느림 · 일부 화질 손실

먼저 속을 확인 — MOV 안에 든 코덱

.mov와 .mp4는 둘 다 "컨테이너", 즉 영상·음성 데이터를 담는 상자의 종류입니다. 실제 화질을 좌우하는 건 그 안에 든 영상 코덱인데, 아이폰이 쓰는 건 두 가지입니다 — 호환성 높은 H.264와, 고효율 설정일 때의 HEVC(H.265). 파일 속 코덱은 ffprobe로 바로 확인됩니다. 

$ ffprobe -show_entries stream=codec_name ...
iphone_h264.mov  →  codec_name: h264
iphone_hevc.mov  →  codec_name: hevc

여기서 코덱이 h264로 나온다면, MP4도 표준으로 H.264를 담기 때문에 다시 압축할 이유가 전혀 없습니다. 상자만 .mov에서 .mp4로 갈아 끼우면 끝입니다.

리먹스와 재인코딩, 시간·화질을 비교하면

1080p 60초짜리 H.264 MOV(60MB)를 두 방식으로 MP4로 만들어, 시간과 용량을 쟀습니다. 하나는 껍데기만 바꾸는 리먹스(-c copy), 하나는 통째로 다시 압축하는 재인코딩입니다.

방식 걸린 시간 결과 용량 화질
리먹스 (-c copy)0.05초60.6MB원본 그대로(무손실)
재인코딩 (libx264)8.87초59.2MB다시 압축(손실)

같은 결과물(재생되는 MP4)을 얻는데 리먹스는 0.05초, 재인코딩은 8.87초 — 약 162배 차이가 났습니다. 이건 60초짜리라 이 정도지, 몇 분짜리 영상이면 재인코딩은 몇 분씩 걸립니다. 리먹스는 영상 데이터를 해독하지 않고 그대로 복사만 하므로 길이와 거의 무관하게 순식간입니다. 용량도 리먹스 쪽이 원본과 사실상 동일(60→60.6MB)한데, 화질을 한 톨도 안 버렸기 때문입니다. 재인코딩은 다시 압축하느라 용량이 조금 줄었지만 그만큼 화질도 깎였습니다. "MP4로 변환하면 화질 나빠진다"는 걱정은, 실은 굳이 재인코딩을 했을 때만 생기는 문제입니다.

확장자만 .mp4로 바꾸면 파일 앞 20바이트가 그대로 남는다

"리먹스가 무손실이면 그냥 이름만 .mp4로 바꿔도 되는 것 아니냐"는 의문이 남습니다. 실제로 뭐가 다른지 파일 앞부분을 직접 열어 봤습니다. 1280×720 30fps 5초짜리 H.264+AAC MOV를 만들어, 하나는 확장자만 .mp4로 바꾸고 하나는 -c copy로 리먹스했습니다(ffmpeg 8.1.2, macOS 26.5.2). 

$ xxd -l 32 원본.mov
00000000: 0000 0014 6674 7970 7174 2020 ...   ....ftypqt

$ xxd -l 32 확장자만바꿈.mp4
00000000: 0000 0014 6674 7970 7174 2020 ...   ....ftypqt      ← 그대로

$ xxd -l 32 리먹스.mp4
00000000: 0000 0020 6674 7970 6973 6f6d ...   ... ftypisom
00000010: 6973 6f6d 6973 6f32 6176 6331 6d70 3431  isomiso2avc1mp41

파일 맨 앞 ftyp 상자에는 "이 파일이 어떤 규격인지" 적는 자리가 있습니다. 확장자만 바꾼 파일은 여기가 여전히 qt  (QuickTime)입니다. 겉이름만 mp4일 뿐 속표지에는 MOV라고 쓰여 있는 셈입니다. 리먹스한 파일은 isom / iso2 / avc1 / mp41로 다시 쓰였습니다. 이 표시를 보고 받아줄지 말지 정하는 프로그램에서는 두 파일의 운명이 갈립니다. 한편 두 파일의 영상·음성 데이터 자체는 완전히 같았습니다. 원본과 리먹스본에서 스트림만 뽑아 해시를 내 보니 둘 다 7b4df88020eb6d94274aa1c888035a62로 일치했습니다. 리먹스가 무손실이라는 말이 비유가 아니라 바이트 단위로 같다는 뜻입니다. 주의할 점도 하나 나왔습니다. 확장자만 바꾼 파일을 ffprobe로 찍으면 "QuickTime / MOV"라고 나오는데, 리먹스한 진짜 MP4도 똑같이 "QuickTime / MOV"로 나옵니다. ffmpeg 계열은 MOV와 MP4를 한 묶음으로 다루기 때문입니다. 그래서 변환이 제대로 됐는지는 ffprobe의 포맷 이름이 아니라 위처럼 ftyp 값으로 확인해야 합니다.

코덱이 HEVC라면 이야기가 다르다

ffprobe에서 코덱이 hevc로 나오는 경우(아이폰 설정이 '고효율'일 때)는 주의가 필요합니다. 리먹스로 상자를 .mp4로 바꿀 수는 있지만, 그래도 안에 든 건 여전히 HEVC입니다. 상대 PC나 편집기가 HEVC를 못 읽으면 확장자가 .mp4여도 여전히 안 열립니다. 확인차 HEVC로 인코딩한 MOV를 같은 방식으로 리먹스해 코덱을 다시 찍어 봤습니다. hevc.mov → codec_name: hevc, hevc_remux.mp4 → codec_name: hevc. 상자만 바뀌고 내용물은 그대로였습니다. 리먹스는 호환성 문제를 해결해 주는 마법이 아니라, 애초에 내용물이 맞을 때만 시간을 아껴 주는 방법입니다. 이 경우엔 H.264로 재인코딩이 불가피합니다. 시간이 걸리고 화질 손실이 생기지만, 호환성을 얻는 대가입니다. 이 "고효율 최신 코덱은 용량은 좋은데 호환성이 걸린다"는 구도는 아이폰 사진의 HEIC와 정확히 같은 이야기인데, 자세한 건 HEIC 호환 실측 가이드에 정리했습니다. 그래서 순서는 언제나 ffprobe로 코덱을 먼저 확인하는 것입니다 — H.264면 리먹스로 끝, HEVC면 재인코딩. 무작정 변환기부터 돌리면 H.264인데도 괜히 재인코딩해 시간과 화질을 낭비하게 됩니다.

터미널 없이 코덱을 확인하려면

위 판단은 전부 "안에 든 코덱이 뭐냐"에 걸려 있는데, ffprobe를 깔 수 없는 상황이 더 흔합니다. 명령 없이 확인하는 길이 세 갈래 있습니다.

여기서 H.264(또는 AVC)라고 나오면 재인코딩은 낭비이고, HEVC(또는 H.265)라고 나오면 재인코딩이 필요한 상황입니다. 표시가 안 보이거나 애매하면 그냥 재인코딩하는 쪽이 안전하지만, 그만큼 시간과 화질을 내주는 선택이라는 점은 알고 하는 편이 좋습니다.

그래서 실제로 뭘 하면 되나

맥이라면 대부분 별도 변환 없이 해결됩니다. QuickTime이나 미리보기로 열어 그대로 쓰거나, 편집 프로그램이 .mov를 못 받을 때만 확장자를 바꿔주면 되는 경우가 많습니다. 코덱이 궁금하면 위처럼 ffprobe 한 줄로 확인하면 됩니다. 받은 사람이 윈도우이고 파일을 열지 못한다면, 순서는 이렇습니다. 먼저 코덱을 확인해 H.264라면 리먹스만으로 끝나니 굳이 오래 걸리는 변환기를 돌릴 필요가 없고, HEVC라면 재인코딩 외에는 방법이 없습니다. 리먹스를 지원하는 프로그램이 없다면 재인코딩이라도 해야 하는데, 그때는 이왕 다시 압축하는 김에 용량까지 함께 줄이는 쪽이 손해가 적습니다. HEVC라서 재인코딩이 필요하거나, 이참에 용량까지 줄이고 싶다면 동영상 용량 줄이기 도구로 H.264로 다시 인코딩하면 됩니다. 이때 해상도·품질을 어떻게 잡아야 화질 손해가 적은지는 동영상 용량 줄이기 실측에 정리했습니다.

이 수치의 전제

위 시간·용량은 1080p 60초 테스트 영상을 이 맥(macOS 26.5.2)에서 실제로 인코딩해 잰 값이고, ftyp 바이트와 스트림 해시는 같은 환경에서 만든 1280×720 5초 영상으로 따로 확인한 값입니다. 절대 시간은 기기 성능·영상 길이·해상도에 따라 달라지지만, "리먹스는 길이와 무관하게 순식간, 재인코딩은 길이에 비례해 오래 걸린다"는 관계는 영상이 무엇이든 달라지지 않습니다. 또 실제 아이폰 영상의 코덱은 촬영 설정(호환성 우선 vs 고효율)과 iOS 버전에 따라 H.264일 수도 HEVC일 수도 있으니, 판단은 항상 ffprobe로 실제 코덱을 확인한 뒤 하는 것이 정확합니다.

그래도 남는 질문 — 확장자와 재인코딩

Q. 그냥 확장자를 .mov에서 .mp4로 바꾸면 안 되나요? 경우에 따라 됩니다만 권하지 않습니다. 위에서 파일 앞부분을 직접 열어 확인했듯, 확장자만 바꾼 파일은 규격 표시가 qt(QuickTime) 그대로 남고 리먹스한 파일만 isom으로 다시 쓰입니다. 이 표시를 보고 파일을 받아줄지 정하는 프로그램에서는 결과가 갈립니다. 화질 손실이 없다는 점은 같지만, 확실하게 하려면 리먹스가 안전합니다. 같은 컨테이너·코덱 구분 이야기는 M4A 재생 안 됨 가이드에서도 다뤘습니다.

Q. 리먹스는 무손실인데 왜 변환기들은 다 재인코딩을 하나요? 범용 변환기는 어떤 입력이 들어올지 모르니 안전하게 항상 재인코딩하도록 만들어진 경우가 많습니다. 내 파일이 이미 H.264라는 걸 ffprobe로 확인했다면, 재인코딩은 시간과 화질을 낭비하는 불필요한 과정이 됩니다.

Q. 편집 프로그램에서 아이폰 영상이 안 열리는 게 코덱 때문인지 어떻게 아나요? ffprobe로 코덱을 확인하는 게 가장 확실합니다. hevc로 나오면 편집기가 HEVC를 지원하지 않아서일 가능성이 큽니다. h264인데도 안 열린다면 코덱이 아니라 컨테이너(.mov) 자체를 그 프로그램이 안 받는 경우이니, 이때가 바로 리먹스로 .mp4 컨테이너로만 바꿔주면 해결되는 상황입니다.