프로토콜, 전송 및 컨테이너를 분리하여 시작하세요

HLS, FLV, HTTP-FLV 및 RTMP라는 용어는 종종 동일한 계층을 설명하는 것처럼 사용됩니다. 하지만 그렇지 않습니다.

• HLS(HTTP Live Streaming)는 Apple이 원래 개발한 미디어 전송 프로토콜입니다. 재생 목록과 HTTP 또는 HTTPS를 통해 전달되는 일련의 미디어 세그먼트를 사용합니다.

• FLV(Flash Video)는 인코딩된 오디오와 비디오를 전달할 수 있는 컨테이너 형식입니다. FLV 자체는 스트림이 네트워크를 통해 어떻게 이동하는지 정의하지 않습니다.

• HTTP-FLV는 HTTP 연결을 통해 FLV 스트림을 계속 열어 둡니다. 플레이어는 재생 목록과 별도 세그먼트를 요청하는 대신 미디어를 지속적으로 수신합니다.

• RTMP는 역사적으로 Flash와 관련된 별도의 스트리밍 프로토콜입니다. 시청자가 HLS 또는 다른 출력 형식을 수신하더라도 기여 또는 수집 측면에서 여전히 일반적으로 사용됩니다.

이 구분은 시스템 설계 시 중요합니다. 플랫폼은 인코더에서 RTMP를 수신하고, 소스를 한 번 처리한 후 다양한 시청자 그룹에 HLS 및 HTTP-FLV 출력을 게시할 수 있습니다. 따라서 전달 방법을 선택한다고 해서 반드시 카메라, 인코더 또는 업스트림 기여 프로토콜을 변경해야 하는 것은 아닙니다.

세그먼트 전송이 대규모에서 잘 작동하는 이유

HLS는 라이브 또는 주문형 프로그램을 미디어 세그먼트로 분할하고 M3U8 재생 목록에 나열합니다. 기존 배포에서는 일반적으로 .ts 확장자로 식별되는 MPEG-2 전송 스트림 세그먼트를 사용합니다. 최신 HLS는 조각난 MP4(fMP4라고도 함)를 사용할 수 있으며, 이는 현대적인 인코딩 및 패키징 워크플로우에 실용적인 기반을 제공합니다. 오디오와 자막은 비디오와 함께 별도의 렌디션으로 제공될 수 있습니다.

재생 목록과 세그먼트는 일반 HTTP 리소스이므로 표준 웹 서버, 리버스 프록시 및 콘텐츠 전송 네트워크(CDN)에서 제공할 수 있습니다. 에지 캐시는 인기 있는 세그먼트를 시청자 가까이에 유지하여 오리진으로의 반복 트래픽을 줄입니다. 이로 인해 HLS는 공개 라이브 이벤트, 교육 포털, 모바일 애플리케이션 및 지리적으로 분산된 시청자를 가진 서비스에 적합한 선택이 됩니다.

적응형 비트레이트 전송은 또 다른 핵심 이점입니다. 플랫폼은 다양한 해상도와 비트레이트로 동일한 프로그램의 여러 렌디션을 준비합니다. 현재 처리량, 버퍼 상태 및 기기 기능에 따라 플레이어는 이러한 변형 간을 이동하여 재생을 안정적으로 유지할 수 있습니다. 변화하는 모바일 연결 상태의 시청자는 완전한 중단을 경험하는 대신 더 낮은 렌디션을 받을 수 있습니다.

대가로 기존 HLS 재생은 일반적으로 세그먼트 생성, 재생 목록 업데이트 및 재생 버퍼를 기다립니다. 실제 지연은 세그먼트 지속 시간, 재생 목록 설계, 플레이어 설정 및 네트워크 조건에 따라 달라집니다. 저지연 HLS는 이 지연을 줄일 수 있지만 패키저, 오리진, CDN 및 플레이어 간의 조정된 지원이 필요합니다. 이는 마지막 단계에서 추가하는 스위치가 아닌 종단 간 설계 선택으로 처리해야 합니다.

세그먼트 지속 시간은 서비스 목표에 맞게 선택해야 합니다. 더 짧은 세그먼트는 플레이어가 새 미디어를 더 빨리 발견하는 데 도움이 되지만 재생 목록 업데이트, 개체 요청 및 패키징 오버헤드도 증가시킵니다. 더 긴 세그먼트는 요청 빈도를 줄이고 전송 효율성을 향상시킬 수 있지만 시작 시간을 늘리고 품질 전환의 응답성을 저하시킬 수 있습니다. 인코더의 키프레임 간격은 패키징 계획을 따라야 하며, 모든 렌디션이 동일한 위치에 깨끗한 전환 지점을 노출하도록 해야 합니다.

연속 HTTP 스트림이 여전히 의미 있는 경우

HTTP-FLV는 장기 HTTP 응답을 통해 FLV 태그를 전송합니다. 재생이 시작되면 미디어 데이터는 동일한 연결을 통해 계속 도착합니다. 새로 고칠 세그먼트 재생 목록이 없으므로 올바르게 조정된 시스템은 일반적으로 기존 세그먼트 워크플로우보다 라이브 소스에 더 가깝게 유지될 수 있습니다.

이 동작은 운영자 대상 애플리케이션(사람들이 이벤트를 관찰하고 신속하게 대응해야 하는 경우: 비디오 모니터링 페이지, 프로덕션 대시보드, 장비 감독, 원격 검사 및 내부 라이브 뷰 시스템)에서 유용합니다. 또한 HTTP 또는 HTTPS 트래픽을 이미 허용하는 네트워크를 통한 전송을 간소화할 수 있습니다.

그러나 HTTP-FLV를 브라우저의 기본 비디오 지원과 혼동해서는 안 됩니다. Adobe Flash Player의 종료는 이전 플러그인 재생 경로를 제거했습니다. Adobe는 2020년 12월 31일에 Flash Player 지원을 종료하고 2021년 1월 12일에 Flash 콘텐츠 차단을 시작했습니다. 따라서 최신 HTTP-FLV 재생은 HTML5 플레이어에 의존하며, 일반적으로 JavaScript를 사용하여 FLV 스트림을 구문 분석하고 브라우저 미디어 API를 사용하여 지원되는 오디오 및 비디오 코덱을 디코더에 공급합니다.

이로 인해 호환성 종속성이 발생합니다. 브라우저는 필요한 미디어 API와 FLV 컨테이너 내에서 전달되는 코덱을 지원해야 합니다. 결과적으로 HTTP-FLV는 제한되지 않은 공개 시청자보다는 통제된 웹 클라이언트 및 전용 애플리케이션에 더 적합합니다. 많은 수의 지속적인 연결은 캐시 가능한 세그먼트 개체보다 전송 서버 및 중간 네트워크 장치에 더 지속적인 부하를 가할 수 있습니다.

전송 경로를 시청 요구 사항에 일치시키기

프로토콜 결정은 기능 체크리스트가 아닌 운영 요구 사항에서 시작해야 합니다. 다음 비교는 유용한 출발점을 제공합니다.

시청자 규모를 예측할 수 없거나, 시청자가 다양한 기기를 사용하거나, 재생 연속성이 즉시성보다 중요하거나, CDN 전송이 계획의 일부인 경우 HLS를 기본 출력으로 사용하십시오. 플랫폼이 웹 플레이어를 제어하고, 시청자가 알려져 있으며, 동시 시청자 수를 관리할 수 있고, 라이브 시청 지연 감소가 명확한 운영 가치를 가질 때 HTTP-FLV를 사용하십시오.

두 경로 중 하나를 승인하기 전에 각 단계(캡처, 인코딩, 네트워크 수집, 미디어 처리, 분배, 플레이어 버퍼링, 디코딩)에 대한 지연 예산을 정의하십시오. 이렇게 하면 다른 곳에서 발생한 지연에 대해 전송 프로토콜이 비난받는 것을 방지할 수 있습니다. 저지연 출력은 긴 GOP의 인코더, 과부하된 트랜스코더 또는 큰 안전 버퍼로 구성된 플레이어를 보상할 수 없습니다. 프로덕션에서 사용되는 실제 엔드포인트와 네트워크에서 결과를 측정하십시오.

두 옵션 모두 모든 형태의 실시간 통신에 적합하지 않습니다. 사용자가 양방향 대화를 하거나 매우 긴밀한 상호 작용 타이밍으로 장치를 작동해야 하는 경우 실시간 통신 기술이 더 적절할 수 있습니다. 중요한 점은 전송 아키텍처를 선택하기 전에 단방향 비디오 분배를 대화형 미디어와 분리하는 것입니다.

하이브리드 설계는 소스를 복제하지 않고 더 많은 사용자를 포괄합니다

많은 프로젝트는 이분법적 결정을 필요로 하지 않습니다. 하이브리드 플랫폼은 하나의 소스를 수집하고, 타임스탬프와 코덱을 정규화한 후 다양한 클라이언트를 위해 별도의 출력을 패키징할 수 있습니다.

1. 소스를 획득합니다. 카메라, 인코더, 게이트웨이 또는 업스트림 플랫폼에서 현장 장치가 지원하는 기여 프로토콜을 통해 라이브 비디오를 수신합니다.

2. 미디어를 검사합니다. 스트림을 다시 패키징할 수 있는지 또는 트랜스코딩해야 하는지 결정하기 전에 코덱, 해상도, 프레임 속도, 오디오 형식 및 타임스탬프 연속성을 확인합니다.

3. 전송 렌디션을 생성합니다. HLS용 적응형 비트레이트 래더를 생성합니다. HTTP-FLV 출력은 필요하고 해당 미디어 프로필을 디코딩할 수 있는 클라이언트에만 생성합니다.

4. 시청자 경로를 분리합니다. HLS는 외부 또는 대규모 시청을 위해 오리진과 CDN을 통해 전송합니다. HTTP-FLV는 운영 사용자를 위해 통제된 전송 클러스터를 통해 라우팅합니다.

5. 액세스 제어를 적용합니다. 각 경로에 적합한 HTTPS, 단기 인증, 오리진 보호 및 세션 정책을 사용합니다.

6. 전체 체인을 측정합니다. 수집 연속성, 트랜스코딩 부하, 패키징 오류, 첫 프레임 시간, 버퍼링, 연결 끊김 및 종단 간 지연을 모니터링합니다.

이 모델은 모든 클라이언트에게 동일한 절충안을 강요하지 않습니다. 공개 시청자는 복원력 있고 확장 가능한 스트림을 받고, 운영자는 저지연 경로를 사용할 수 있습니다. 미디어 플랫폼은 또한 레거시 소스 형식을 현재 브라우저와 애플리케이션이 소비할 수 있는 출력으로 변환하는 지점이 됩니다.

재패키징과 트랜스코딩 중 선택

입력 코덱이 이미 전송 프로필과 일치하는 경우 플랫폼은 압축된 미디어를 재패키징하기만 하면 될 수 있습니다. 재패키징은 각 프레임을 디코딩하고 인코딩하지 않고 컨테이너 또는 출력 구조를 변경하므로 일반적으로 처리 리소스를 적게 소비하고 소스 품질을 보존합니다. 이는 코덱 지원, 타임스탬프, 키프레임 배치 및 오디오 매개변수가 대상 플레이어에 이미 적합한 경우에만 적절합니다.

트랜스코딩은 소스 코덱을 의도된 클라이언트가 디코딩할 수 없거나, 여러 해상도와 비트레이트가 필요하거나, 프레임 속도, 오디오 형식 및 키프레임 구조를 정규화해야 할 때 필요합니다. 이는 계산 비용과 처리 지연을 추가하므로 용량은 평균 사용량이 아닌 피크 동시 채널 수를 기준으로 계산해야 합니다. 하드웨어 가속은 채널 밀도를 높일 수 있지만 출력 품질과 동작은 선택한 플레이어로 테스트해야 합니다.

프로덕션 시스템은 단일 장애 지점도 제거해야 합니다. 중복 오리진, 통제된 플레이어 재연결 및 테스트된 장애 조치 규칙을 사용하고 장애를 증폭시키는 공격적인 재시도 루프를 만들지 마십시오.

피할 수 있는 장애를 방지하는 배포 점검 사항

프로토콜 선택만으로는 안정적인 서비스를 보장하지 않습니다. 출시 전에 전체 미디어 및 네트워크 경로를 검증하십시오.

• 엔드포인트에서 코덱 지원을 확인합니다. 전송은 플레이어에 성공적으로 도달할 수 있지만 브라우저가 오디오 또는 비디오 프로필을 디코딩할 수 없어 재생이 실패할 수 있습니다.

• 타임스탬프를 연속적으로 유지합니다. 손상되거나 단조롭지 않은 타임스탬프는 끊김, 오디오 드리프트 및 품질 전환 실패를 초래할 수 있습니다.

• 키프레임을 패키징 규칙에 맞춥니다. HLS 렌디션은 조정된 키프레임 경계를 사용하여 플레이어가 눈에 띄는 중단 없이 품질을 전환할 수 있도록 해야 합니다.

• 소스에서 플레이어까지 HTTPS를 계획합니다. 보안 페이지는 안전하지 않은 미디어를 요청해서는 안 되며, 인증서는 오리진 및 배포 계층 전체에서 유효해야 합니다.

• 실제 네트워크 조건을 테스트합니다. 로컬 네트워크에서만 테스트하는 대신 제한된 대역폭, 패킷 손실 및 짧은 중단 상태에서 시작, 복구 및 품질 변화를 검증합니다.

• 연결 동작에 맞게 용량을 산정합니다. HLS 용량 계획은 세그먼트 요청, 스토리지 및 캐시 적중률에 중점을 둡니다. HTTP-FLV 계획은 장기 동시 연결 및 지속적인 송출 트래픽을 고려해야 합니다.

• 대체 정책을 제공합니다. 기본 플레이어 또는 형식을 사용할 수 없는 경우 애플리케이션은 무한정 재시도하는 대신 지원되는 대안 또는 명확한 오류를 반환해야 합니다.

대부분의 대외 서비스의 경우 HLS가 더 안전한 기본값입니다. 적응형 비트레이트 재생과 성숙된 HTTP 분배를 결합하기 때문입니다. HTTP-FLV는 관리되는 플레이어와 낮은 지연이 보편적 도달 범위보다 더 중요할 때 여전히 유용합니다. 동일한 라이브 소스가 두 그룹 모두에 서비스를 제공해야 할 때 하이브리드 아키텍처가 종종 가장 실용적인 답변입니다.

자주 묻는 질문

라이브 전송 워크플로우에 자막을 추가할 수 있나요?

네. 자막은 업스트림에서 생성하거나 미디어 처리 중에 삽입할 수 있습니다. HLS의 경우 WebVTT 자막 렌디션이 일반적인 옵션입니다. 사용자 정의 HTTP-FLV 플레이어는 별도의 시간 지정 텍스트 채널과 자체 동기화 로직이 필요할 수 있습니다.

라이브 이벤트가 진행 중일 때 시청자가 되감기를 할 수 있나요?

서비스가 충분히 긴 라이브 창을 유지하고 플레이어가 시간 이동 제어 기능을 제공하는 경우 가능합니다. 보존 창, 스토리지 용량 및 콘텐츠 권한은 라이브 되감기를 활성화하기 전에 정의해야 합니다.

비디오 대역폭을 사용할 수 없을 때 플레이어가 오디오만으로 대체할 수 있나요?

네, 플랫폼이 오디오 전용 렌디션 또는 별도의 오디오 스트림을 게시하고 플레이어가 이를 선택하도록 구성된 경우 가능합니다. 이는 매우 제한된 연결에서 중요한 해설이나 지침을 보존할 수 있습니다.

분석은 시청자 이탈과 네트워크 장애를 구분할 수 있나요?

단일 연결 끊김 이벤트만으로는 불가능합니다. 플레이어 이벤트, 하트비트 간격, 세션 식별자, 재시도 동작 및 서버 연결 로그를 결합하여 이탈을 더 확실하게 분류하십시오.

이벤트 종료 후 라이브 URL은 어떻게 되어야 하나요?

플랫폼은 라이브 세션을 닫거나, 종료 화면을 게시하거나, 처리가 완료된 후 사용자를 보관된 프로그램으로 리디렉션할 수 있습니다. 포함된 플레이어와 공유 링크가 설명 없이 실패하지 않도록 전환을 미리 정의하십시오.