동영상 압축
해상도·화질을 조정해 용량 줄이기 — 카톡·이메일·SNS 첨부 한도에 맞춰.
📱 모바일: 720p 이하·1분 이내 영상 권장 — 큰 영상은 데스크톱 Chrome이 안정적입니다.
권장: 26~30 (시각 손실 거의 없이 용량 30~60% 감소). 18 = 거의 무손실, 35 = 강한 압축.
해상도·CRF별 용량 가이드
5분 1080p 영상(원본 ~250MB) 기준 추정. 실제 용량은 영상 복잡도(움직임·디테일)에 따라 다름.
| 해상도 | CRF | 용량 추정 | 용도 |
|---|---|---|---|
| 1080p | 23 | 180~220MB | 고화질 보관·유튜브 업로드 |
| 1080p | 28 | 80~120MB | 웹 권장, 시각 손실 X |
| 720p | 28 | 40~60MB | 카톡(300MB)·SNS 충분 |
| 720p | 32 | 20~35MB | 이메일 첨부(25MB) 근접 |
| 480p | 30 | 15~25MB | 메신저·미리보기 |
같은 CRF인데 왜 데스크톱 앱보다 용량이 큰가요?
동영상 압축은 같은 화질 설정(CRF)이라도 인코더가 얼마나 오래 고민하느냐에 따라 결과 용량이 크게 달라집니다. ffmpeg의 -preset 옵션이 그 "고민의 양"을 정하는데, ultrafast부터 veryslow까지 단계가 있고 느린 단계일수록 같은 화질을 더 작은 용량에 담아냅니다.
이 도구는 내부적으로 libx264 -preset ultrafast로 인코딩합니다. 빠른 preset을 고른 이유는 처리 속도 때문입니다. GitHub Pages 같은 정적 호스팅은 Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy 헤더를 줄 수 없어 브라우저의 SharedArrayBuffer가 꺼지고, 그 결과 ffmpeg.wasm이 단일 스레드로만 돌아갑니다. 멀티스레드를 못 쓰는 환경에서 느린 preset까지 쓰면 5분 영상에 수십 분이 걸릴 수 있어, 현실적인 대기 시간을 위해 속도를 우선한 설정입니다.
그래서 현실적인 기대치는 이렇습니다. 데스크톱 Chrome에서 인코딩 속도는 대략 원본 길이의 0.3~1배 수준(5분 영상이면 보통 1~3분), 모바일은 그보다 2~3배 더 걸립니다. iOS Safari는 탭당 메모리가 약 500MB로 제한되어 1080p 장편 영상은 도중에 멈출 수 있습니다.
요점은 "이 도구가 데스크톱 전문 앱(HandBrake 등)보다 같은 CRF에서 용량을 덜 줄이는 건 정상"이라는 점입니다. 더 작은 용량이 꼭 필요하면 CRF를 한두 단계 올리거나(예: 28→30) 해상도를 720p 이하로 내리는 쪽이, 이 환경에서는 가장 효과가 확실합니다.
관련 도구
왜 첫 사용 시 30MB가 다운로드되나요?
처리 도중 페이지를 닫아도 되나요?
왜 멀티 스레드(빠른 처리)는 지원 안 되나요?
Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy 헤더를 설정할 수 없어 SharedArrayBuffer가 비활성됩니다. 이 때문에 단일 스레드로만 동작 — 안전하지만 느립니다(원본 길이의 0.3~1배). 빠른 처리가 필요하면 데스크톱 사용 + 720p 이하로 다운스케일을 추천합니다.
iOS Safari에서 큰 영상이 멈춥니다.
자주 묻는 질문
원본 영상이 서버로 업로드되나요?
처리 시간이 얼마나 걸리나요?
어떤 영상 포맷이 입력되나요?
CRF는 무엇이고 어떻게 정하나요?
큰 영상도 처리 가능한가요?
오디오는 그대로 유지되나요?
참고
- ffmpeg.wasm — 공식 사이트 (BSD/LGPL)
- H.264/AVC 표준 — ISO/IEC 14496-10
- CRF 가이드 — FFmpeg Wiki