CSS (Cloud Streaming Services)

공식문서: https://www.tencentcloud.com/document/product/267

CSS는 Tencent Cloud의 라이브 스트리밍 전용 클라우드 서비스다. 인코더로부터 스트림을 수신해 클라우드에서 처리하고, CDN을 통해 시청자에게 배포하는 원스탑 라이브 스트리밍 플랫폼이다. 트랜스코딩, 녹화, 타임시프트, 워터마크, 미디어 AI, 콘텐츠 모더레이션까지 별도 서비스 없이 CSS 안에서 모두 처리할 수 있다.

들어가기 전에

AWS에서 라이브 스트리밍을 구성할 때 선택지는 크게 두 가지다. MediaLive + MediaPackage + CloudFront를 조합해 직접 파이프라인을 구성하는 방법과, IVS(Interactive Video Service)처럼 인제스트부터 배포까지를 하나의 서비스로 처리하는 방법이다. Tencent Cloud CSS는 후자에 가깝다. 인코더로부터 스트림을 직접 수신해 클라우드에서 처리하고, CDN을 통해 시청자에게 배포하는 원스탑 라이브 스트리밍 플랫폼이다.

StreamLive나 StreamPackage 없이도 동작하는 독립적인 서비스이며, 방송급 파이프라인이 필요할 때 Stream 시리즈와 결합하는 형태로 확장된다.

입수부터 배포까지의 흐름

CSS의 기본 흐름은 단순하다.

인코더는 CSS의 Push Domain으로 스트림을 전송한다. CSS는 이를 수신해 설정된 처리 기능(트랜스코딩, 녹화, 워터마크 등)을 적용한 뒤, Pull Domain을 통해 시청자에게 스트림을 제공한다. 처리 기능은 기본적으로 비활성화 상태이며, 필요한 항목만 선택해 활성화한다.

지원 입수 프로토콜

도메인 구조와 스트림 식별

CSS는 Push Domain과 Pull Domain을 분리해 관리한다. 최소 2개의 도메인이 필요하며, 같은 2차 도메인 아래 서브도메인으로 구분할 수 있다(예: push.example.com, play.example.com).

하나의 스트림은 AppName과 StreamName의 조합으로 식별된다.

도메인 제약사항:

• 최대 45자, 대문자 불가

• 계정당 기본 100개까지 등록 가능

• Push/Pull 도메인은 반드시 분리해야 함

• 도메인 소유권 검증 필수(DNS TXT 레코드 또는 HTML 파일 방식)

푸시 URL과 인증

URL 구조

rtmp://{push-domain}/{AppName}/{StreamName}?txSecret=xxx&txTime=xxx

인증 파라미터

인증은 기본 활성화 상태다. 만료 시각이 지난 URL로는 인제스트가 차단되므로, 장시간 방송 시 인코더에서 정기적으로 URL을 갱신해야 한다.

Tencen에서 제공하는 tx인증이 아닌 타 사의 인증을 커스텀으로 사용할 수 있으므로 필요 시 담당자에게 문의한다.

URL 생성 방법

1. 콘솔 Address Generator — Toolkit에서 도메인, AppName, StreamName, 만료시간 입력 후 자동 생성

2. Domain Management — Push Configuration 탭에서 직접 생성

3. 서버 측 계산 — Sample Code 참고하여 key + StreamName + time으로 직접 연산

풀 URL과 프로토콜별 지연

재생 URL도 인증 구조는 동일하다. 프로토콜에 따라 URL 확장자와 스킴이 달라진다.

트랜스코딩 템플릿을 적용한 경우 StreamName 뒤에 템플릿 이름이 붙는다:

https://pull-domain/live/StreamName_hd.flv    ← HD 트랜스코딩 출력
https://pull-domain/live/StreamName_sd.flv    ← SD 트랜스코딩 출력

클라우드 처리 기능

트랜스코딩

원본 스트림을 다른 코덱, 해상도, 비트레이트로 변환한다. 해상도별 다중 출력을 구성해 어댑티브 비트레이트 스트리밍(ABR)에 활용할 수 있다.

지원 코덱:

• 비디오: H.264, H.265, AV1

• 오디오: AAC-LC, AAC-HE, AAC-HE v2

주요 파라미터:

기본 프리셋 템플릿:

Top Speed Codec (TSC)

TSC는 CSS의 독자적인 지능형 인코딩 기술이다. 장면 인식, 동적 인코딩, CTU/라인/프레임 3레벨 비트레이트 제어를 결합해 동일 화질 기준으로 비트레이트를 평균 50% 절감한다.

비용 절감 시뮬레이션 (3Mbps, 4시간, 200명 시청 기준):

• TSC 미적용: 대역폭 비용 $127

• TSC 적용(30% 절감): 대역폭 $89 + TSC 트랜스코딩비 $11 = 총 $100 → 약 $27 절약

1080p 이상 고화질 방송에서 TSC 효과가 극대화된다.

TSC를 비롯한 인코딩에 관한 내용은 다른 글에서 더 자세히 작성하였다.

Remuxing

코덱을 변경하지 않고 컨테이너 포맷만 변환한다. RTMP 입력을 FLV, HLS, DASH, TS로 출력할 수 있으며, DRM 적용도 이 단계에서 처리된다.

녹화

라이브 스트림을 실시간으로 VOD(Video on Demand) 서비스에 저장한다.

녹화 대상 선택:

• 원본 스트림 — 트랜스코딩 전 원본 그대로 저장

• 워터마크 스트림 — 워터마크 적용 후 저장

• 트랜스코딩+워터마크 스트림 — 트랜스코딩과 워터마크 모두 적용 후 저장

녹화 완료 약 5분 후 VOD에서 재생 가능하며, VOD 태스크 플로우와 연동하면 녹화 즉시 후처리(편집, 배포 등)를 자동화할 수 있다.

스트림 중단 처리:

• HLS 포맷만 중단 후 재개(Resumption) 지원

• Resumption Timeout 내 재연결 시 단일 파일로 이어서 녹화

• Timeout 초과 시 새 파일 생성

타임시프트

스트림을 TS 세그먼트 단위로 저장해 시청자가 현재 방송 중에 과거 시점으로 되감아 볼 수 있다. 최대 6시간 구간을 지원하며, 최대 3만 동시 시청자를 수용한다.

재생 방식 2가지:

1. 특정 구간 재생 — 시작/종료 시각 지정

https://pull-domain/live/stream.m3u8?txTimeshift=on&tsFormat=unix_s&tsStart=1675302995&tsEnd=1675303025

2. 지연 재생 — 현재로부터 N초 전 시점 재생

https://pull-domain/live/stream.m3u8?txTimeshift=on&tsDelay=30

스포츠 중계(하이라이트 리플레이), 예능(중간 입장 시청자), 콘텐츠 모더레이션 딜레이 등에 유용하다.

워터마크

스트림에 이미지나 텍스트 워터마크를 실시간으로 삽입한다. 위치는 비율(%)로 지정하므로 다중 해상도 트랜스코딩 출력에서도 동일한 상대 위치에 표시된다.

스크린캡쳐

일정 간격으로 라이브 스트림의 썸네일을 자동 생성한다. 생성된 이미지는 COS(Cloud Object Storage)에 저장되며, 콘텐츠 모더레이션 파이프라인의 입력으로 활용된다.

Relay

외부 소스의 스트림을 CSS로 끌어오는 기능이다. 외부 RTMP/HLS/FLV URL을 지정하면 CSS가 해당 스트림을 Pull하여 자체 CDN으로 배포한다. 다중 소스 페일오버, 외부 피드 통합 등에 사용된다.

스트림 믹싱 (Stream Mix)

여러 스트림을 하나로 합성해 출력한다. 다중 화면 구성(PiP, 격자 레이아웃), 게스트 화면 합성, 코-앵커링 시나리오에서 사용된다.

Standby Stream

주 입력 스트림이 끊길 경우 자동으로 대기 스트림(또는 미리 지정한 콘텐츠)으로 전환한다. 방송 공백 없이 대체 화면을 송출할 수 있어 고가용성이 요구되는 방송 환경에 적합하다.

미디어 AI 기능

CSS는 별도 서비스 호출 없이 스트림 처리 파이프라인 안에서 AI 기능을 직접 적용할 수 있다.

콘텐츠 모더레이션은 스크린캡쳐 기능과 연동되어 동작한다. 일정 간격으로 캡쳐된 프레임을 AI 모델이 분석하고, 위반 감지 시 콜백 URL로 알림을 전송한다.

서비스 타입

CSS는 사용 목적에 따라 세 가지 서비스 타입을 제공한다.

LVB vs LEB

둘 다 CSS 안에서 동작하는 서비스 타입이며, 같은 Push Domain으로 인제스트한 스트림을 Pull 프로토콜만 달리해서 시청자에게 제공하는 구조다.

핵심 차이: LEB는 WebRTC 프로토콜 기반의 초저지연 단방향 스트리밍이다.

WebRTC라는 이름 때문에 양방향 통화(RTC)를 떠올리기 쉽지만, LEB는 호스트 → 시청자로의 단방향 배포이며, 시청자 간 또는 시청자-호스트 간 음성/영상 양방향 통신은 포함하지 않는다. 양방향 실시간 통화가 필요하면 TRTC(Tencent Real-Time Communication)를 별도로 사용해야 한다.

LEB를 선택하는 기준:

• 시청자의 반응 속도가 비즈니스에 직접 영향을 미칠 때 (라이브 커머스 실시간 문의, 스포츠 베팅, 경매)

• 호스트와 시청자 간 채팅/이모지 등 텍스트 인터랙션의 동기화가 중요할 때

• 불안정한 네트워크 환경(모바일, 해외)에서도 끊김 없는 재생이 필요할 때

LVB를 선택하는 기준:

• 2~3초 지연이 허용되는 일반 방송 (스포츠 중계, 쇼룸, 게임 스트리밍)

• 비용 최적화가 우선일 때 (LVB 트래픽 단가가 더 낮음)

• HLS 호환성이 중요한 환경 (Smart TV, 레거시 셋톱박스)

참고: LEB는 "초저지연 단방향 배포"이고, TRTC는 "양방향 실시간 통화"다. 라이브 방송 중 시청자와 호스트가 음성/영상으로 직접 대화해야 하는 시나리오(코-앵커링, 1:1 화상 상담 등)는 TRTC 영역이며, CSS/LEB와 TRTC를 조합해 구현한다.

Stream 시리즈와의 연동

CSS는 단독으로도 완결된 서비스지만, 방송급 대형 파이프라인이 필요한 경우 Stream 시리즈와 결합한다. (Stream 시리즈는 Tencent cloud의 미디어 파이프라인 서비스이다. AWS의 Elemental 시리즈와 매칭된다고 보면 된다.) 주로 CSS가 Streampackage에서 패키징된 스트림을 CDN을 통해 배포하는 역할을 한다.

인코더 → StreamLink → StreamLive → StreamPackage → CSS → 시청자

이 구성에서 각 서비스의 역할은 명확하게 나뉜다.

StreamPackage가 오리진 역할을 하고 CSS가 CDN으로 스트림을 Pull하는 구조다.

언제 Stream 시리즈가 필요한가:

• 크로스 리전 전송 안정성이 중요할 때 (StreamLink)

• SCTE-35 기반 광고 삽입이 필요할 때 (StreamLive)

• FairPlay/Widevine DRM + 오리진 이중화가 필요할 때 (StreamPackage)

• 위 요구사항이 없다면 CSS 단독으로 충분하다

주요 사용 케이스

마치며

CSS는 단순한 CDN 서비스라기보다, 라이브 스트리밍에 필요한 인제스트(Ingest), 트랜스코딩 및 패키징과 같은 미디어 처리, 그리고 글로벌 CDN 배포까지 하나의 플랫폼 안에서 제공하는 원스탑 라이브 스트리밍 서비스에 가깝다. RTMP, SRT 등의 다양한 입력 프로토콜을 받아 HLS, FLV, WebRTC(LEB) 등 여러 재생 포맷으로 배포할 수 있으며, 필요에 따라 트랜스코딩, 타임시프트, DRM, SSAI와 같은 기능도 함께 구성할 수 있다.

소규모 1인 방송부터 수백만 단위 동시 접속이 발생하는 스포츠·대형 이벤트 중계까지 CSS만으로 커버할 수 있고, 보다 복잡한 워크플로우가 필요한 경우에는 StreamLive, StreamPackage, StreamLink 등의 Stream 시리즈와 결합하여 방송국 수준의 미디어 파이프라인으로 확장하는 것도 가능하다.

전체적인 방향성으로 보면 AWS IVS와 유사한 포지션으로 볼 수 있지만, 보다 CDN 및 미디어 처리 계열 기능과의 결합성이 강하다는 점이 특징이라고 할 수 있겠다.