라이브 멀티스트리밍 플랫폼

하나의 라이브 입력을 관리형 수신 지점에서 받은 뒤 해당 신호를 소셜 플랫폼, 파트너 엔드포인트, 플레이어, 다른 워크플로 모듈 중 어디로 보낼지 결정한다는 의미입니다.

하나의 소스를 여러 목적지로 보내야 하거나 백업 경로가 중요하거나, 라우팅 로직을 인코더 설정이 아닌 관리형 워크플로에서 운영해야 할 때 선택합니다.

가능합니다. 이 계층을 사용하는 주된 이유 중 하나입니다. 하나의 기여 피드를 수신해 여러 외부 또는 내부 출력으로 전달할 수 있습니다.

가능합니다. 기본 경로가 불안정해지기 전에 대체 라우트, 백업 목적지, 페일오버용 워크플로 분기를 준비할 수 있습니다.

워크플로가 올바르게 구성됐다면 인코더 측에서는 필요하지 않습니다. 소스는 일반적으로 하나의 관리형 기여 스트림만 전송하고 플랫폼이 다운스트림 분배를 처리합니다.

가능합니다. 동일한 워크플로에 소셜 출력, 비공개 RTMP/SRT 목적지, 시청자용 재생 화면을 함께 포함할 수 있습니다.

가능합니다. 브랜딩, 오버레이, 녹화, 재생 전용 설정을 소스 인코더에 넣지 않고 라우팅 경로에 추가할 수 있습니다.

가능합니다. 한 번 수신한 신호를 라이브 출력으로 라우팅하면서 동시에 녹화하는 것이 일반적인 프로덕션 패턴입니다.

가능합니다. 네트워크 상태, 기여 품질, 제어 가능한 수신 인프라가 중요할 때 SRT가 널리 사용됩니다.

가능합니다. 최종 목적지가 해당 전송 방식을 요구하면 라우팅 워크플로에서 SRT 기여 입력과 RTMP 또는 RTMPS 출력을 함께 사용하는 경우가 많습니다.

둘 다 가능합니다. 일반적으로 대시보드에서 워크플로를 먼저 검증한 뒤 API를 통해 동일한 로직을 자체 운영자 도구나 백엔드로 옮깁니다.

가능합니다. 클라우드에서 시작하거나 셀프호스팅 인프라로 이전해도 동일한 워크플로 모델을 유지할 수 있다는 점이 이 스택의 실용적인 장점입니다.

신호의 수신 지점부터 정해야 한다면 SRT 서버에서 시작한 뒤 SRT 라우트와 재스트리밍으로 이동해 신호 경로를 정의하세요.

스트림 비트레이트에는 별도 제한을 두지 않습니다. 다만 일부 목적지 플랫폼에는 자체 비트레이트 제한이 있을 수 있습니다.