FAST 채널의 로고 — 화면 모서리에 있는 작은 마크 —는 채널에서 방영되는 모든 프로그램, 모든 광고 시간, 모든 슬레이트에서 변함없이 시각적으로 일관된 요소입니다. 시청자가 어떤 품질 수준으로 받든 전문가답게 보여야 합니다. 하나의 마스터 이미지를 업로드하고 AWS MediaLive가 렌디션별로 스케일링하도록 하는 기본적인 접근 방식은 1080p에서는 선명한 로고를, 360p에서는 눈에 띄게 흐릿한 로고를 생성합니다. 이는 광대역 네트워크를 사용하지 않는 모든 시청자에게 브랜드 문제가 됩니다. 여기서는 대신 로고 크기를 각 렌디션의 정확한 픽셀 그리드에 맞춘 방법을 소개합니다.
빠른 개요
| 항목 | 세부 정보 |
|---|---|
| 도메인 | FAST 채널의 채널 로고 (DOG) 오버레이 |
| 메커니즘 | 각 렌디션(1080p, 720p, 480p, 360p)별 출력 StaticImageOutputActivate |
| 에셋 생성 | Lanczos 리샘플링을 사용하는 Python 스크립트 |
| 활성화 타이밍 | 각 프로그램의 입력 전환 후 1.5초 |
| 상태 | 프로덕션 환경에서 1개 렌디션별 스택 |
비즈니스 문제
FAST 채널은 단일 품질 수준을 제공하지 않습니다. MediaLive는 동일한 채널을 여러 렌디션(1080p, 720p, 480p, 360p)으로 인코딩하며, 각 시청자의 플레이어는 연결 상태에 따라 가장 적합한 렌디션을 선택합니다. 셀룰러 데이터를 사용하는 모바일 시청자는 360p를 시청하고, 광대역 네트워크를 사용하는 스마트 TV 시청자는 1080p를 시청합니다. 이들은 모두 동일한 브랜드 마크를 보고 있으며, 모두 전문가답게 보이기를 기대합니다. 로고가 1080p에서는 선명하고 360p에서는 눈에 띄게 흐릿할 경우, 브랜드는 일관성을 잃게 됩니다. 이는 로고가 어떤 단일 프로그램보다도 시청자에게 더 많이 보이는 24/7 채널에서 사소한 문제가 아닙니다.
오버레이가 실제로 적용되는 위치
다중 렌디션 인코더 파이프라인에서 오버레이는 두 곳에 적용될 수 있습니다.
렌디션별 스케일러 **이전**, 하나의 마스터 이미지가 소스에 합성되고 전체가 출력별로 축소되는 방식 — 이는 MediaLive가 전역 StaticImageActivate 액션을 통해 수행하는 방식입니다.
스케일러 **이후**, 각 출력이 캔버스가 최종 크기로 지정된 후 자체 오버레이를 적용받는 방식. API에서는 차이가 작아 보입니다. 시각적으로는 그렇지 않습니다. 스케일러 이전에 합성된 모든 것은 스케일러가 도입하는 모든 아티팩트를 상속하며, 360p에서는 스케일러가 공격적입니다.
명백한 해결책이 실패하는 이유
"하나의 마스터 이미지를 업로드하고 MediaLive가 스케일링하게 합니다." 전역 액션은 출력별 스케일러가 실행되기 전에 마스터 이미지를 합성합니다. 360p용 64x21px 로고로 축소되는 큰 마스터 이미지는 약 40배 축소에 해당합니다. — Lanczos 리샘플링조차도 이 비율에서는 미세한 디테일을 잃으며, 결과물은 비디오 자체와 동일한 압축 체인을 거칩니다.
"더 큰 마스터 이미지를 사용합니다." 이렇게 하면 축소 비율이 더 작아지는 것이 아니라 **커지므로** 아티팩트가 더 심해집니다.
"SD 출력에서 로고를 건너뜁니다." 규정 준수 및 브랜드 요구 사항에 따라 모든 렌디션에 마크가 필요합니다. 옵션이 아닙니다.
"인코딩 시점에 소스 비디오에 로고를 굽습니다." 모든 운영 레버를 잃게 됩니다. — 캠페인별 또는 지역별 로고 변경이 불가능하며, 전체 라이브러리를 재인코딩하지 않고는 업데이트할 수 없습니다.
"해상도별 수동 좌표를 사용하여 전역 오버레이를 사용합니다." 전역 액션은 고정된 1920x1080 참조에 대해 위치를 계산하므로, 그보다 좁은 소스 비디오는 캔버스 외부 좌표를 생성합니다. — 로고가 모서리 밖으로 벗어나거나 잘립니다.
실제 레버는 MediaLive의 오버레이 스케일링을 완전히 우회하는 것이었습니다. 즉, 인코더가 건드리기 전에 각 렌디션의 캔버스에 맞게 로고 크기를 직접 조정하는 것이었습니다.
해결책
각 렌디션의 로고는 정확한 픽셀 치수에 맞춰 사전 렌더링되어 별도의 PNG로 저장됩니다. 각 프로그램 경계에서 Lambda 오케스트레이터는 4개의 StaticImageOutputActivate 액션(렌디션당 하나씩)을 방출하며, 각 액션은 해당 특정 출력에 맞게 이미 크기가 조정된 PNG를 가리킵니다. MediaLive는 오버레이에 대해 스케일링을 전혀 수행하지 않습니다.
GLOBAL (기본 방식) 출력별 (우리가 제공하는 방식)
master.png ──► 소스 캔버스에 합성 master.png ──► Lanczos 리사이즈 (오프라인)
(오버레이도 스케일링) → 4개의 정확한 크기 PNG로
│ │
▼ ▼
렌디션별 스케일러 렌디션별 스케일러
(오버레이도 스케일링 (오버레이는 건드리지 않음 —
→ SD 출력에서 흐린 로고) 정확한 픽셀 크기로 나중에 합성됨)Python 스크립트는 작은 크기에서 예측 가능하고 반복 가능한 동작을 위해 선택된 Lanczos 리샘플링을 사용하여 단일 마스터 이미지에서 네 가지 크기의 PNG를 생성하며, 이는 픽셀 품질 경쟁에서 이기기 위함이 아닙니다. 각 로고는 캔버스 너비의 약 10% 정도에 위치하여 눈에 거슬리지 않으면서도 잘 보이며, 새로운 렌디션을 추가하는 것은 단일 배열 항목과 새로운 PNG 하나만 추가하면 됩니다.
주목할 만한 주요 결정 사항
1.5초 활성화 지연. 워터마크 활성화 액션은 정확한 전환 순간이 아니라 각 입력 전환 후 1.5초 뒤에 실행됩니다. — 즉시 활성화하면 아직 안정적이지 않은 프레임에 대해 깜박임이 발생할 수 있습니다. 이 값은 경험적으로 조정되었으며 단일 상수로 중앙 집중화되어 향후 조정 시 한 줄만 변경하면 됩니다.
오프라인, 사람의 개입에 의한 에셋 생성 — 의도적으로. Lanczos 리사이즈 파이프라인은 빌드 단계나 CDN 측 변환으로 자동화되지 않습니다. 로고 에셋은 변경 빈도가 낮으므로 한 번의 명령으로 재생성하는 것이 적절한 자동화 수준입니다. — 추가 자동화를 구축하는 비용이 1년에 두 번 스크립트를 실행하는 것보다 큽니다.
"두꺼운" 변형이 존재하지만 배포되지 않았습니다. 생성기는 더 두꺼운 스트로크가 있는 확장 알파 변형도 생성하며, 이는 낮은 SD 비트레이트에서 H.264 양자화를 견디도록 고안되었습니다. 현재 프로덕션 환경에 배포되어 있지 않습니다. — 표준 변형은 현재 비트레이트 범위에 충분하며, 아직 전환을 정당화할 만한 측정 결과는 없습니다. 이는 코드 테스트된 대기 상태로 존재합니다. — 유지 비용이 저렴하며, 배포하기에는 시기상조입니다.
여전히 주시하고 있는 부분
어떤 프로덕션 비디오 파이프라인도 진정으로 완성되는 일은 없으며, 시간이 지남에 따라 이 접근 방식을 개선할 기회는 여전히 존재합니다.
현재 구현은 모든 렌디션이 자체 출력 해상도에 맞춰 특별히 준비된 로고를 받도록 보장하여, MediaLive 파이프라인에서 런타임 오버레이 스케일링을 제거합니다. 그러나 최종 외관은 특히 낮은 비트레이트에서 각 렌디션의 해상도와 비디오 압축에 의해 자연스럽게 제한됩니다. 스트리밍 프로필이 발전함에 따라, 이러한 조건에서 다른 로고 처리가 측정 가능한 시각적 이점을 제공하는지 계속 평가할 것입니다.
에셋 생성기는 이미 표준 로고와 더 두꺼운 로고 변형을 모두 지원합니다. 향후 테스트에서 더 두꺼운 버전이 낮은 비트레이트 렌디션에 더 나은 성능을 보인다면, 로고 변형 선택을 구성 기반으로 만들어 애플리케이션을 재배포하지 않고도 변경할 수 있도록 할 것입니다.
결과
이제 모든 렌디션은 MediaLive가 런타임 오버레이 스케일링을 전혀 수행하지 않고, 자체 캔버스에 맞춰 특별히 크기가 조정된 로고를 받습니다. 각 출력은 대상 해상도에 맞춰 준비된 아트워크를 사용하여, 런타임 오버레이 스케일링으로 인한 추가적인 흐림 현상을 방지하면서 해당 렌디션이 제공할 수 있는 최상의 실질적인 시각적 품질을 보존합니다.
이전 전역 오버레이 방식에서 1920px보다 좁은 소스 비디오에서 로고가 이동할 수 있었던 좌표 이탈 버그는 출력별 활성화가 전적으로 출력 좌표에서 작동하므로 구조적으로 제거되었습니다.
이제 로고 교체는 간단한 운영 작업입니다. — 단일 스크립트로 렌디션별 에셋을 재생성하고 업로드하면 됩니다. 비디오 재인코딩이나 렌디션별 수동 편집은 필요하지 않습니다.
이 구현은 간단한 엔지니어링 원칙을 따릅니다. — 가능한 한 파이프라인 초기에 문제를 해결하고, 다운스트림 해결책에 의존하기보다는 플랫폼의 기능에 맞춰 설계하는 것입니다. 인코딩 전에 올바른 에셋을 준비함으로써 라이브 파이프라인은 더 단순하고 예측 가능하며 유지 관리가 용이해집니다.
라이브 비디오 파이프라인에서 비슷한 렌디션 또는 오버레이 품질 문제에 직면하고 있다면 문의하세요.
기술 스택: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)
