영상 용량 줄이기 — 화질 손상을 줄이는 설정

결론부터: 용량과 화질을 동시에 고정할 수는 없습니다

영상 압축은 같은 화면을 더 적은 비트로 다시 인코딩하는 작업입니다. 현재 도구는 H.264 영상과 AAC 오디오가 들어간 MP4로 만들며, 손실 압축입니다. 따라서 ‘화질 손상 없이 용량만 줄인다’거나 ‘눈으로 절대 구분할 수 없다’고 약속할 수 없습니다. 대신 목적에 맞는 CRF와 해상도를 고르고, 결과를 실제 게시 환경에서 검수해 불필요한 손상을 줄이는 것이 현실적인 접근입니다.

이 글의 테스트 원본은 1920×1080, 8초, 화면 표시 기준 10.9MB입니다. 인물 두 명이 앉아 있고 움직임이 매우 적은 합성 샘플이라 일반 촬영보다 압축하기 쉬운 조건입니다. 특정 실존 인물을 묘사하지 않도록 AI로 생성한 가상 성인 이미지로 만든 제품 시연 영상입니다. 표준 설정에서 결과가 0.1MB로 표시됐지만, 스포츠·게임·콘서트·카메라 이동처럼 변화가 큰 영상에 같은 압축률이 나온다고 예상해서는 안 됩니다.

10.9MB에서 0.1MB는 이 8초 저동작 합성 샘플의 관측값입니다. 일반 영상의 예상 절감률이나 품질 보장 수치로 사용하지 마세요.

1단계 — 원본 정보와 처리 환경을 확인합니다

영상 압축 페이지에서 파일을 선택하면 이름, 용량, 해상도, 길이를 먼저 확인할 수 있습니다. 현재 브라우저 도구의 파일 상한은 2GB입니다. 이 압축 기능은 선택한 영상 바이트를 압축을 위해 서버로 보내지 않고 브라우저 안의 ffmpeg.wasm으로 처리합니다. 그래서 업로드 대기 대신 기기 성능에 따라 처리 시간이 달라지고, 탭을 닫으면 진행 중인 작업이 끝날 수 있습니다. 첫 실행에는 브라우저용 처리 구성 요소를 불러오는 시간도 생길 수 있습니다.

‘브라우저 처리’가 원본 이용 권한까지 해결해 주는 것은 아닙니다. 내가 편집할 권한이 있는 파일인지 먼저 확인하세요. 오래된 휴대전화나 메모리가 적은 환경에서는 2GB 이하라도 작업이 느리거나 실패할 수 있으므로, 중요한 원본은 별도로 보관하고 짧은 복사본으로 설정을 먼저 시험하는 편이 좋습니다. 파일 상한은 성공이나 처리 시간을 보장하는 값이 아닙니다.

2단계 — 먼저 CRF 프리셋을 고릅니다

목표 용량을 꼭 맞출 필요가 없다면 품질 프리셋부터 시험하는 것이 단순합니다. CRF는 장면마다 필요한 비트를 조절하면서 목표 품질 수준을 정하는 값입니다. 같은 코덱과 원본이라면 숫자가 낮을수록 보통 더 많은 정보를 남겨 파일이 커지고, 숫자가 높을수록 더 강하게 줄여 손상이 보일 가능성이 커집니다. 다만 파일 크기는 영상의 움직임, 노이즈, 질감, 프레임률에 따라 크게 달라지므로 CRF만 보고 최종 MB를 계산할 수는 없습니다.

현재 세 프리셋은 고화질 CRF 23, 표준 CRF 28, 최대 압축 CRF 33입니다. 처음에는 기본값인 표준 28로 짧게 시험하고, 얼굴 윤곽·작은 글자·빠른 움직임이 무너지면 23으로 올려 비교하세요. 이메일 첨부처럼 용량 제약이 더 중요하고 손상을 감수할 수 있을 때만 33을 검토합니다. ‘고화질’도 원본 그대로라는 뜻이 아니며 세 값 모두 다시 인코딩되는 손실 결과입니다.

3단계 — 해상도는 ‘확대값’이 아니라 높이 상한입니다

해상도는 원본, 1080p, 720p, 480p 중에서 고릅니다. 원본을 선택하면 입력 해상도를 유지하고 압축 설정만 바꿉니다. 1080p·720p·480p는 세로 높이의 상한으로 동작하며 화면 비율을 유지합니다. 예를 들어 4K 원본을 1080p로 고르면 줄어들지만, 720p 원본을 1080p로 골랐다고 인위적으로 확대하지는 않습니다.

작은 화면으로만 공유한다면 720p가 용량을 크게 줄이는 데 도움이 될 수 있지만, 화면 속 자막이나 제품 UI를 읽어야 한다면 해상도 감소가 더 눈에 띌 수 있습니다. 먼저 원본 해상도와 표준 CRF로 결과를 본 뒤, 여전히 크면 720p를 비교하는 순서가 원인을 구분하기 쉽습니다. CRF와 해상도를 한꺼번에 가장 강하게 낮추면 어떤 선택 때문에 읽기 어려워졌는지 알기 어렵습니다.

4단계 — 0.1MB 결과는 이 샘플에만 귀속합니다

기본 표준 CRF 28과 원본 해상도로 실행한 이번 결과는 화면에서 0.1MB로 표시됐습니다. 입력은 10.9MB였으므로 숫자 차이가 매우 크지만, 영상이 8초로 짧고 배경과 인물 움직임이 적은 특수 조건이었습니다. 원본이 생성 과정에서 비효율적으로 큰 비트레이트를 사용했다면 재인코딩 차이도 더 커질 수 있습니다. 이 한 건으로 ‘99% 감소’ 같은 일반 문구를 만들면 안 됩니다.

결과 카드의 파일 크기만 보지 말고 8초 전체를 재생하세요. 오디오가 끝까지 나오는지, 입술·눈·머리카락 경계가 뭉개지지 않는지, 배경 벽의 완만한 색 변화에 띠가 생기지 않는지 확인합니다. 다운로드 뒤 실제 게시 플랫폼이 다시 압축할 수 있으므로, 가능하면 비공개 업로드나 최종 기기에서도 읽기 어려운 요소가 없는지 점검하세요.

5단계 — 같은 시점 프레임과 움직이는 구간을 함께 봅니다

전후 비교는 같은 시점의 프레임을 나란히 두면 시작하기 쉽습니다. 이번 비교 자산은 왼쪽 원본과 오른쪽 압축 결과를 같은 크기로 배치해 얼굴 윤곽, 머리카락, 옷의 질감과 배경 경계를 살펴보도록 만들었습니다. 다만 한 장의 축소된 스크린샷에서 차이가 작아 보인다고 무손실이 증명되는 것은 아닙니다. 브라우저 표시 크기와 스크린샷 자체의 변환도 세부를 숨길 수 있습니다.

정지 화면 다음에는 변화가 큰 구간을 정상 크기와 전체 화면으로 재생하세요. 블록 노이즈는 고개를 돌리거나 카메라가 움직이는 순간에 더 잘 보이고, 음성은 영상과 별도로 AAC 128kbps로 다시 인코딩됩니다. 말소리의 치찰음, 음악의 고음, 입 모양과 소리의 동기화도 확인해야 합니다. 화질 판단은 한 프레임, 움직임, 소리 세 가지를 모두 봐야 합니다.

목표 MB는 단일 패스 근사치입니다

메일이나 업로드 상한 때문에 목표 용량이 있다면 MB 값을 입력할 수 있습니다. 이 값을 넣으면 품질 프리셋보다 목표 용량 계산이 우선합니다. 현재 구현은 영상 길이로 목표 평균 비트레이트를 한 번 계산하고, 오디오 128kbps를 제외한 나머지를 영상에 배정해 단일 패스로 인코딩합니다. 영상 비트레이트는 지나치게 낮아지지 않도록 최소값도 둡니다.

이 방식은 빠르게 근접 값을 만들기 위한 계산이지 정확히 입력한 MB에 맞추는 2패스 보장이 아닙니다. 컨테이너 오버헤드, 오디오, 원본 길이 판독과 장면 복잡도 때문에 결과가 목표보다 크거나 작을 수 있습니다. 특히 원본보다 큰 목표, 매우 짧은 영상, 현실적으로 너무 작은 목표에서는 기대와 차이가 커질 수 있습니다. 상한이 엄격하다면 약간 낮은 목표로 시험한 뒤 실제 결과 파일 크기를 확인하고 한 번 더 조정하세요.

목표 MB는 ‘정확히 이 크기’가 아니라 단일 패스 비트레이트 계산의 근사 목표입니다. 최종 제한은 다운로드된 파일 크기로 판단하세요.

실패를 줄이는 압축 순서

• · 원본은 덮어쓰지 말고 별도로 보관한다
• · 2GB 이하인지, 브라우저가 읽은 길이·해상도가 맞는지 확인한다
• · 먼저 표준 CRF 28과 원본 해상도로 짧게 시험한다
• · 손상이 크면 CRF 23, 용량이 더 중요하면 CRF 33을 비교한다
• · 여전히 크고 작은 화면용이면 720p 또는 480p를 별도로 시험한다
• · 엄격한 상한이 있을 때만 목표 MB를 사용하고 결과 크기를 재확인한다
• · 정지 프레임뿐 아니라 빠른 움직임·작은 글자·오디오를 끝까지 검수한다
• · 게시 플랫폼의 재압축 뒤에도 최종 화면을 확인한다