가로로 넓은 화면 하나가 720p 요금제를 깨뜨렸다
개요
이전 글에서 MPS가 장변/단변과 화면비로 해상도 등급을 판정한다는 걸 다뤘습니다. 이번 글은 그 판정 로직을 실제로 건드려야 했던 디버깅 사례입니다. 사용자가 세로 숏폼 위주 서비스를 운영하면서 720p와 360p 두 등급만으로 ABR 트랜스코딩 요금을 통제하고 싶어했는데, 특정 조건에서만 의도치 않게 1080p 등급이 트리거되는 문제를 겪었습니다.
이슈 제기: 왜 iPad에서만 1080p 요금이 찍히는가
사용자가 제기한 이슈는 이랬습니다. ABR 템플릿을 720p와 360p 두 개 rendition만 쓰도록 구성했는데, 가로 화면비가 9:16보다 넓은 입력(iPad 같은 태블릿에서 녹화된 영상 등)에서 불필요하게 1080p 트랜스코딩이 함께 트리거된다는 것이었습니다.
요구사항은 명확했습니다.
| Rendition | 설정 |
|---|---|
| Rendition 1 - 720p | 가로 해상도 720px로 제한 |
| Rendition 2 - 360p | 가로 해상도 360px로 제한 |
입력 화면비가 9:16보다 넓을 때(가로로 더 긴 경우), 트랜스코딩 템플릿이 강제로 가로 해상도 상한을 720 또는 360으로 제한해서 iPad 같은 와이드 기기에서 1080p로 올라가지 않도록 막아야 한다는 요구였습니다. 코덱이나 비트레이트 설정을 바꾼 것도 아닌데 특정 화면비에서만 등급이 튀는 상황이라, 템플릿의 해상도 스케일링 로직 자체를 뜯어봐야 했습니다.
원인: 한쪽 변만 고정하면 반대쪽 변이 상한을 넘는다
이 서비스의 ABR 템플릿은 원래 세로 숏폼(9:16)을 기준으로 만들어져 있었습니다. 세로 영상이 대부분이다 보니 "긴 변(높이)을 등급 상한에 맞추고, 짧은 변(너비)은 비율대로 계산한다"는 규칙 하나로 충분했던 겁니다.
문제는 이 템플릿이 참고하는 등급별 상한 자체가 장변과 단변 양쪽에 독립적으로 걸려 있다는 점입니다. 두 등급의 정의는 이렇습니다.
| 등급 | 조건 |
|---|---|
| 360P | 장변 ≤ 640px 그리고 단변 ≤ 360px |
| 720P | 장변 ≤ 1280px 그리고 단변 ≤ 720px |
이전 글에서 다룬 MPS의 비율 분기 방식과는 또 다른 형태지만, StreamLive의 해상도 등급 판정과 같은 "장변과 단변을 모두 만족해야 그 등급"이라는 AND 조건 구조라는 점은 동일합니다. 즉 두 조건 중 하나라도 넘으면 그 등급에서 밀려납니다.
"긴 변만 고정한다"는 규칙은 화면비가 9:16 근처일 때는 문제가 없습니다. 하지만 화면비가 9:16과 16:9 사이, 즉 정사각형에 가까운 구간(iPad의 4:3 같은 화면비 포함)으로 들어오면 얘기가 달라집니다. 이 구간에서 긴 변만 등급 상한에 맞추면, 짧은 변이 비율대로 계산되면서 오히려 그 등급의 단변 상한을 넘어버립니다.
숫자로 보면 이렇습니다. 850×1280 입력을 "장변(1280)을 720p 상한에 맞춘다"는 규칙으로 스케일링하면 이미 장변이 1280으로 상한과 같아서 아무것도 줄지 않고, 단변은 원래 값인 850이 그대로 남습니다. 그런데 720P의 단변 상한은 720px입니다. 850은 이 상한을 훌쩍 넘기 때문에, 이 결과물은 720P의 AND 조건(장변 ≤ 1280 그리고 단변 ≤ 720)을 만족하지 못하고 상위 등급인 1080P로 넘어가 버립니다. 화질 설정을 바꾼 적도 없는데 화면비 하나 때문에 등급이 튀어 오르는 정체가 바로 이겁니다.
해결: 화면비 구간별로 우선순위를 나눈다
고친 방식은 화면비(가로÷세로 비율, x)를 세 구간으로 나누고 구간마다 어느 변을 먼저 상한에 맞출지 다르게 적용하는 것이었습니다.
| 조건 | 처리 |
|---|---|
| x > 16:9 | 장변 우선 |
| 16:9 ≥ x ≥ 9:16 | 단변 우선 |
| x < 9:16 | 장변 우선 |
양 끝 구간(세로로 아주 길거나 가로로 아주 넓은 경우)은 장변을 상한에 먼저 맞추고 단변을 비율대로 계산해도 단변이 자연스럽게 상한 안에 들어옵니다. 문제가 되는 건 가운데 구간, 즉 정사각형에 가까운 화면비입니다. 이 구간에서는 반대로 단변을 먼저 상한에 맞추고 장변을 비율대로 계산해야, 장변도 자기 상한 안에 들어오면서 두 조건을 모두 만족합니다.
실제 검증: 네 가지 화면비로 확인하기
수정한 규칙을 네 가지 화면비에 실제로 대입해봤습니다.
| 화면비 | 입력 | 판정 | 처리 | 출력 |
|---|---|---|---|---|
| 8:16 (x=0.5, < 9:16) | 720×1440 | 장변 우선 | 장변 1440→1280 | 640×1280 |
| 10:16 (x=0.625, 중간 구간) | 800×1280 | 단변 우선 | 단변 800→720 | 720×1152 |
| 16:8 (x=2.0, > 16:9) | 1440×720 | 장변 우선 | 장변 1440→1280 | 1280×640 |
| 16:10 (x=1.6, 중간 구간) | 1280×800 | 단변 우선 | 단변 800→720 | 1152×720 |
네 케이스 모두 결과물이 720P의 AND 조건(장변 ≤ 1280, 단변 ≤ 720)을 만족합니다. 특히 10:16과 16:10처럼 "중간 구간"에 들어오는 화면비에서 단변 우선 규칙이 정확히 작동해, 장변이 1152/1152로 상한(1280) 안에 여유 있게 들어오는 걸 확인할 수 있습니다. iPad류의 4:3(x=1.33) 화면비도 이 중간 구간에 들어오기 때문에 같은 규칙으로 처리됩니다.
360p 등급으로도 같은 로직을 대입해 확인했습니다.
| 화면비 | 입력 | 판정 | 처리 | 출력 |
|---|---|---|---|---|
| 9:16보다 세로로 긴 화면 | 360×720 | 장변 우선 | 장변 720→640 | 320×640 |
| 9:16보다 가로로 넓은 화면 | 500×640 | 단변 우선 | 단변 500→360 | 360×461 |
두 경우 모두 360P의 AND 조건(장변 ≤ 640, 단변 ≤ 360)을 정확히 만족합니다.
정리
- 이 ABR 템플릿이 참조하는 등급 정의는 장변과 단변에 각각 독립적인 상한을 두고 두 조건을 모두 만족해야 하는 AND 구조입니다. StreamLive의 해상도 판정 방식과 같은 형태입니다.
- 세로 숏폼(9:16) 전제로 만들어진 "장변만 고정" 규칙은 화면비가 9:16과 16:9 사이인 구간(iPad의 4:3 포함)에서 단변이 등급 상한을 넘게 만들어, 의도치 않게 상위 등급(1080P)으로 판정되는 원인이었습니다.
- 해결책은 화면비를 세 구간(x>16:9, 9:16≤x≤16:9, x<9:16)으로 나누고, 양 끝 구간은 장변 우선, 가운데 구간은 단변 우선으로 스케일링 규칙을 다르게 적용하는 것이었습니다.
- 네 가지 화면비로 실제 검증한 결과 모두 목표 등급의 AND 조건을 만족했습니다.
세로 콘텐츠 위주 서비스라도 사용자가 태블릿이나 가로 촬영 영상을 업로드하는 경로가 하나라도 있다면, "긴 변만 고정하면 된다"는 단순 가정이 그 경로에서 정확히 깨집니다. 화면비 구간별로 어느 변이 등급을 결정하는지 직접 계산해보지 않으면, 요금제를 두 등급으로 딱 고정해뒀다고 믿고 있다가 청구서에서 예상 밖의 등급을 마주치게 됩니다.