야동파티 화질 실험: 720p와 1080p, 비트레이트를 바꾸자 결과가 달라졌어요

‘1080p인데 왜 720p보다 뭉개져 보일까?’라는 질문에는 해상도만으로 답할 수 없어요. 야동파티에서는 영상의 내용과 길이를 고정하고, 해상도와 목표 비트레이트만 조합해 네 파일을 만들었습니다. 낮은 데이터 예산에서는 720p가 근소하게 앞섰지만, 예산을 늘리자 1080p가 앞섰어요. 서로 반대인 두 결과를 함께 봐야 해상도 메뉴를 제대로 해석할 수 있습니다.

이 글의 자료는 FFmpeg로 생성한 움직이는 합성 테스트 화면입니다. 외부 서비스의 영상을 내려받거나, 실제 이용자의 시청 기록을 수집한 실험은 아니에요. 아래에 같은 지점의 이미지와 네 파일을 모두 공개해 두었으니 수치와 눈으로 보이는 차이를 함께 확인할 수 있어요.

1. 네 파일에서 같게 둔 것과 바꾼 것

1920×1080, 30fps의 원본 180프레임을 만들었어요. 큰 색 면 위로 선과 작은 격자가 움직이는 testsrc2 화면입니다. 원본은 FFV1 무손실 영상으로 보관하고, 소리는 넣지 않았습니다. 같은 프레임을 출발점으로 삼아 아래 두 조건을 조합했어요.

• 해상도: 1280×720 또는 1920×1080.
• 목표 비트레이트: 300 kbps 또는 1500 kbps. 두 값 모두 권장 스트리밍 속도가 아니라, 차이를 보기 위해 정한 실험 조건입니다.
• 공통 인코딩: H.264/libx264, medium 프리셋, 2패스, GOP 60, 장면 전환 키프레임 비활성화, yuv420p.

720p 결과를 원본과 비교할 때는 Lanczos 방식으로 1920×1080까지 늘렸어요. 1080p와 같은 출력 크기에서 비교하기 위해서입니다. 이 과정에는 축소와 확대에서 생기는 손실도 포함돼요. 따라서 이 결과를 작은 휴대폰 화면에서의 체감 차이와 같다고 볼 수는 없습니다.

2. 목표값과 실제 파일 크기를 나눠 기록했어요

‘파일 평균’은 파일 바이트 × 8 ÷ 6초 ÷ 1000으로 계산했어요. MP4 컨테이너까지 포함한 값이며, 매 순간의 영상 비트레이트나 네트워크 측정 속도는 아닙니다. 목표를 똑같이 300k로 줘도 실제 파일이 정확히 같은 크기로 나오지는 않았어요.

SSIM은 FFmpeg로 180프레임 전체를 원본과 비교한 All 평균입니다. 두 입력의 시간 기준을 1/30초로 통일하고 프레임 번호로 맞춘 뒤, 끝 프레임 반복을 끄고 비교 횟수가 정확히 180인지 로그에서 확인했어요. 300k에서 두 해상도의 차이는 약 0.0049으로 작았고, 1500k에서는 1080p가 약 0.0118 높았어요. 이것을 ‘누가 봐도 몇 퍼센트 더 선명하다’로 바꿔 말하지는 않겠습니다. 수치의 의미와 실제로 눈에 띄는 부분은 구분해서 봐야 해요.

3. 같은 3초 지점에서 어디가 달랐을까요?

300k의 1080p 이미지에서는 작은 칸의 경계가 넓게 번지고 주변 색이 덩어리로 섞여 보여요. 720p도 원본의 가는 무늬를 그대로 보존하지는 못하지만, 이 부분에서는 작은 칸의 구분이 더 남아 있습니다. 같은 예산을 더 많은 픽셀에 나눠 쓰는 것이 항상 유리하지 않다는 예예요.

1500k에서는 두 결과 모두 낮은 예산에서 보이던 큰 뭉개짐이 줄어듭니다. 이 조건의 전체 SSIM은 1080p가 가장 높았어요. 다만 색 격자처럼 가는 반복 무늬는 작은 부분마다 인상이 다를 수 있습니다. 한 장의 확대 이미지로 평균값을 대신 설명하거나, 가장 유리한 부분만 골라 순위를 정해서는 안 돼요.

이미지는 모두 0부터 센 90번 프레임, 즉 3.000초에서 잘랐어요. 원본 좌표 x=1216, y=704의 320×192 영역이며, 별도 선명화나 명암 보정 없이 무손실 WebP로 저장했습니다.

4. 저희가 내린 결론: 숫자를 올리기 전에 움직이는 구간을 봐요

해상도는 한 화면에 들어가는 픽셀의 수를 알려 주지만, 압축 뒤 어떤 정보가 남았는지까지 알려 주지는 않습니다. 이번에는 720p에서 1080p로 바꾸며 픽셀 수가 2.25배로 늘었어요. 그러나 300k 조건의 실제 파일 크기는 거의 그대로였습니다. 낮은 예산에서 작은 무늬가 버티지 못한 결과와 함께 읽을 수 있는 부분이에요.

반대로 1500k에서는 더 큰 해상도가 가진 장점이 드러났습니다. 그래서 ‘낮은 해상도가 더 좋다’는 제목만 남기면 실험의 절반을 버리게 돼요. 저희의 판단은 해상도 메뉴를 품질 순위표로 읽지 말자는 쪽입니다. 메뉴는 조건 중 하나이고, 결과는 같은 장면을 실제로 재생해 확인해야 해요.

• 잔무늬가 있는 배경이나 빠르게 움직이는 구간을 골라 같은 크기로 비교해 보세요. 다른 장면끼리 비교하지 않는 것이 먼저입니다.
• 1080p가 계속 뭉개져도 그것만으로 인터넷이 느리다고 단정할 수는 없어요. 이 실험의 뭉개짐은 네트워크를 거치기 전, 저장된 파일 안에 이미 있었습니다.
• 버퍼링이나 프레임 끊김이 함께 있다면 별도 문제예요. 이번 실험에는 서버 전송, 모바일 기기의 디코딩 성능, 자동 화질 전환을 포함하지 않았습니다.

5. 이 결과를 어디까지 사용할 수 있을까요?

같은 내용과 비슷한 데이터 예산이어도 해상도만으로 결과를 단정할 수 없다는 예로 사용할 수 있어요. 하지만 6초짜리 합성 화면 한 종류로 영화·실사·애니메이션의 권장값을 정할 수는 없습니다. 반복 무늬가 많은 이번 소스는 자연스러운 촬영 영상과 특성이 달라요.

또한 코덱은 H.264 한 종류, 프리셋은 medium 하나만 썼습니다. AV1·HEVC와의 비교도, 사람을 대상으로 한 선호도 조사도 하지 않았어요. 모바일에서는 화면 크기와 시청 거리에 따라 차이가 덜 보일 수 있지만, 이 글은 실제 휴대폰 체감 실험으로 제시하지 않습니다.

원본 조건과 네 결과를 확인하는 방법

아래 영상은 각각 6초이며 소리가 없습니다. 원하는 파일을 누를 때만 열립니다. 표의 수치를 다시 계산하려면 측정값 CSV를, 같은 조건으로 다시 만들려면 전체 명령과 확인 방법을 이용해 주세요. CSV에는 파일별 SHA-256도 함께 넣었습니다.

• 720p / 300k 영상 · 217 kB
• 1080p / 300k 영상 · 214 kB
• 720p / 1500k 영상 · 1.13 MB
• 1080p / 1500k 영상 · 1.15 MB

ffmpeg -f lavfi -i "testsrc2=duration=6:size=1920x1080:rate=30" -an -c:v ffv1 -threads 2 -pix_fmt yuv420p reference.mkv

기술 근거: FFmpeg SSIM 설명 · FFmpeg 테스트 화면 생성 · MDN 영상 인코딩 조건. 측정값과 화면 비교에 대한 해석은 이번 실험을 바탕으로 작성했습니다.