Callaba SRT Server

SRT 서버란 무엇인가요?

여기서 말하는 SRT 서버 는 SRT 연결을 수락하거나 관리하는 엔드포인트입니다. 인코더의 라이브 SRT 스트림을 수신해 다른 시스템으로 중계하거나, 원격 소스와 프로덕션 플랫폼 사이의 통제된 인계 지점 역할을 할 수 있습니다.

일반적인 라이브 워크플로에서 SRT 서버는 다음 네 가지 실무 작업을 수행합니다.

• 라이브 피드 수신: 카메라 인코더, OBS, vMix, FFmpeg, Larix 또는 다른 소스가 서버로 비디오를 전송합니다.
• 콘트리뷰션 경로 보호: SRT는 손실된 패킷을 복구하고 전송 세션을 암호화할 수 있습니다.
• 라이브 통계 제공: 운영자는 비트레이트, RTT, 패킷 손실, 재전송 및 연결 상태를 모니터링할 수 있습니다.
• 스트림을 다운스트림으로 전달: 서버는 피드를 녹화, 트랜스코딩, 재스트리밍, 스위칭 또는 재생 워크플로로 라우팅할 수 있습니다.

따라서 SRT 서버는 소스 측과 플랫폼 측 사이의 경계가 됩니다. 원격 팀이 “전송 중입니다”라고 말할 때, 신호가 실제로 도착하는지, 안정적인지, 다운스트림에서 미디어를 사용할 수 있는지를 확인하는 곳이 SRT 서버입니다.

SRT 서버와 SRT 프로토콜의 차이

여기서 SRT 프로토콜 은 전송 방식이고, SRT 서버 는 해당 프로토콜을 사용하여 라이브 스트림을 수신하거나 전송하는 시스템 또는 소프트웨어 엔드포인트입니다.

SRT 라이브 서버란 무엇인가요?

여기서 말하는 SRT 라이브 서버 는 실시간 또는 준실시간 라이브 비디오 콘트리뷰션에 사용하는 SRT 서버입니다. 이벤트가 진행되는 동안 라이브 스트림을 수신해 라이브 프로덕션, 녹화 또는 배포 워크플로로 전달합니다.

팀은 원격 이벤트 콘트리뷰션, 카메라와 인코더의 클라우드 인제스트, 스튜디오-클라우드 전송, 파트너 피드 인계, 백업 콘트리뷰션 경로, 원격 프로덕션 워크플로 및 다중 대상 재스트리밍에 SRT 라이브 서버를 사용합니다.

“라이브”라는 단어가 중요한 이유는 SRT 튜닝이 파일 전송과 다르기 때문입니다. 서버는 지연 시간과 복구 사이의 균형을 맞춰야 합니다. 실제 네트워크 경로에 비해 지연 시간이 너무 낮으면 스트림은 연결되더라도 패킷 손실이나 지터가 발생할 때 끊길 수 있습니다.

SRT 서버의 작동 방식

SRT 서버는 SRT 연결을 통해 인코딩된 오디오와 비디오를 수신합니다. 미디어는 SRT가 전송하기 전에 이미 인코딩되어 있습니다. 라이브 비디오 워크플로에서는 다중화된 MPEG-TS 스트림을 SRT로 전달하는 경우가 많지만 정확한 컨테이너는 송신자와 워크플로에 따라 달라질 수 있습니다. 실무에서는 보통 H.264 또는 H.265/HEVC 같은 비디오, AAC 같은 오디오, 경우에 따라 메타데이터가 포함된 준비된 미디어 스트림을 수신합니다.

1. 인코더가 라이브 오디오와 비디오 스트림을 생성합니다.
2. 인코더가 스트림을 SRT 서버로 전송합니다.
3. SRT 서버가 스트림을 수신하고 연결 상태를 추적합니다.
4. 패킷이 손실되면 아직 유효한 동안 SRT가 재전송을 요청할 수 있습니다.
5. 서버가 다음 워크플로 단계로 스트림을 전달합니다. 녹화기, 트랜스코더, 재스트리밍, 스위처, API 워크플로 또는 재생 시스템 등이 이에 해당합니다.

Caller, Listener 및 Rendezvous 모드

SRT에는 세 가지 연결 모드가 있습니다. 어느 쪽이 연결을 시작하는지와 방화벽 및 NAT를 통과해 세션이 작동하는 방식을 모드가 결정합니다.

• Listener: 알려진 UDP 포트에서 수신 SRT 연결을 기다립니다. 클라우드 인제스트 서버 또는 데이터 센터 엔드포인트에서 일반적으로 사용합니다.
• Caller: Listener에 대한 연결을 시작합니다. 현장 인코더, OBS, vMix, FFmpeg, 모바일 앱 및 원격 소스에서 일반적으로 사용합니다.
• Rendezvous: 양쪽에서 연결을 시작합니다. 일부 NAT 환경에서 유용할 수 있지만 프로덕션 전에 신중하게 테스트해야 합니다.

SRT 서버 포트와 방화벽 규칙

SRT는 UDP를 사용합니다. 따라서 클라우드 보안 그룹, 호스트 방화벽, 라우터 또는 네트워크 정책에서 올바른 UDP 포트를 열어야 합니다.

• 서버에 공인 IP 또는 접근 가능한 네트워크 주소가 있음;
• 올바른 UDP 포트가 열려 있음;
• 인코더가 올바른 Caller/Listener 모드를 사용함;
• Stream ID를 사용하는 경우 서버 라우팅 규칙과 일치함;
• 암호화를 사용하는 경우 양쪽의 패스프레이즈가 일치함;
• 수신 워크플로가 올바른 다운스트림 출력에 매핑됨.

인코더에 “연결됨”이라고 표시되는지만 확인하는 것은 흔한 실수입니다. 연결만으로는 충분하지 않습니다. 미디어가 도착하고 비트레이트가 안정적이며 다운스트림 시스템이 스트림을 사용할 수 있는지도 확인해야 합니다.

SRT 서버 설정 예시

실무적인 첫 테스트 설정입니다. 호스트, 포트, Stream ID 및 패스프레이즈를 실제 값으로 바꾸십시오.

Server side:
mode: listener
UDP port: 10080
latency: 200 ms
stream ID: event-main
passphrase: optional, same on both sides

Sender side:
srt://YOUR_CALLABA_IP:10080?mode=caller&latency=200&streamid=event-main

라이브 스트리밍 워크플로에서 SRT 서버의 위치

SRT는 일반적으로 워크플로의 콘트리뷰션 측, 즉 라이브 피드가 소스에서 플랫폼으로 이동하는 구간에서 가장 강점을 발휘합니다.

카메라 또는 인코더 → SRT 서버 → 트랜스코더 / 녹화기 / 재스트리밍 / 플레이어 워크플로

SRT 서버가 스트림을 수신한 후 플랫폼은 재스트리밍, 녹화, 트랜스코딩, 재생, 라우팅, 장애 조치, API 워크플로 또는 프로덕션 모니터링을 위해 스트림을 준비할 수 있습니다.

SRT 서버와 RTMP, HLS, WebRTC 및 NDI 비교

SRT는 모든 비디오 기술을 대체하지 않습니다. 워크플로의 특정 구간을 해결합니다.

프로토콜 수준의 비교는 SRT와 RTMP 비교를 참조하십시오.

SRT 서버를 배포하는 방법

정확한 설정은 소프트웨어, 클라우드 공급자 및 워크플로에 따라 달라지지만 배포 논리는 대체로 동일합니다.

1. 서버 또는 클라우드 인스턴스를 생성 하고 워크플로에 충분한 CPU, 네트워크 용량 및 스토리지를 제공합니다.
2. 필요한 UDP 포트를 개방 하여 클라우드 보안 그룹과 호스트 방화벽에 적용합니다.
3. SRT Listener를 생성 하여 수신 스트림을 받습니다.
4. Stream ID 및 패스프레이즈 규칙을 설정 하여 필요할 때 라우팅과 암호화를 수행합니다.
5. 인코더를 연결 하여 SRT Caller로 Listener 엔드포인트에 스트림을 전송합니다.
6. 라이브 통계를 확인 합니다. 비트레이트, RTT, 패킷 손실, 재전송 및 연결 상태 등이 포함됩니다.
7. 스트림을 다운스트림으로 라우팅 하여 녹화, 재스트리밍, 트랜스코딩 또는 재생에 사용합니다.

Callaba에서 SRT 서버를 사용하는 방법

Callaba에서 SRT 서버는 일반적으로 통제된 인제스트 지점으로 사용됩니다. 원격 소스가 Callaba로 스트림을 전송하면 Callaba가 다음 워크플로 단계에서 해당 스트림을 사용할 수 있게 합니다.

일반적인 Callaba 워크플로:

• SRT 인코더에서 Callaba로 보낸 다음 Twitch 또는 YouTube로 재스트리밍;
• OBS에서 SRT를 통해 Callaba로 보낸 다음 스트림 녹화;
• vMix에서 SRT를 통해 Callaba로 보낸 다음 피드를 다른 대상으로 라우팅;
• 모바일 앱에서 SRT를 통해 Callaba로 보낸 다음 소셜 플랫폼으로 재스트리밍;
• 원격 행사장에서 Callaba로 보낸 다음 브라우저 재생용으로 패키징;
• SRT 입력을 브라우저 멀티뷰, 녹화기, API 라우팅 및 통제된 플레이어 전송에 연결.

SRT 서버에서 모니터링할 항목

SRT 세션이 연결되었다고 해서 스트림이 항상 정상인 것은 아닙니다. 전송 상태와 미디어 상태를 모두 모니터링하십시오.

전송 신호

• 연결 상태: 연결됨, 연결 끊김, 다시 연결 중 또는 실패.
• 수신 비트레이트: 미디어가 예상 속도로 계속 흐르는지 여부.
• RTT: 송신자와 수신자 사이의 왕복 시간.
• 패킷 손실: 경로에서 손실되는 데이터의 양.
• 재전송: SRT가 누락된 패킷을 복구해야 하는 빈도.
• 지터: 패킷 도착 시간의 변동 정도.
• 수신 버퍼 압력: 연결이 복구 한계에 지나치게 가까운지 여부.

미디어 신호

• 검은 화면, 정지 화면, 오디오 누락 또는 무음;
• 잘못된 코덱, 프레임 레이트, 해상도 또는 오디오 형식;
• 잘못된 타임스탬프, 누락된 키프레임 또는 호환되지 않는 스트림 매핑.

일반적인 SRT 서버 문제

SRT 연결이 시작되지 않음

연결 모드, UDP 포트, 공인 IP, 방화벽 규칙, Stream ID 및 암호화 패스프레이즈를 확인하십시오. 대부분의 SRT 핸드셰이크 실패는 잘못된 모드, 차단된 UDP 트래픽, 잘못된 포트 또는 일치하지 않는 보안 설정 때문에 발생합니다.

스트림은 연결되지만 비디오가 불안정함

RTT, 지터, 패킷 손실, 재전송 및 지연 시간 설정을 확인하십시오. 네트워크 경로에 비해 지연 시간이 너무 짧으면 손실된 패킷이 쓸모없어지기 전에 SRT가 복구할 시간이 부족할 수 있습니다.

스트림은 연결되지만 오디오가 없음

인코더를 먼저 확인하십시오. 오디오 소스가 활성화되어 있고 올바른 오디오 디바이스가 선택되었으며 오디오 코덱이 다음 워크플로 단계와 호환되고 수신 애플리케이션이 오디오 트랙을 읽을 수 있는지 확인합니다.

SRT 서버를 디버깅하기 전에 소스에 오디오가 존재하는지 확인하십시오. 네트워크나 서버를 탓하기 전에 OBS, vMix, 하드웨어 인코더의 로컬 모니터링, 헤드폰 또는 디바이스 미리보기를 사용합니다.

SRT 통계는 양호하지만 시청자에게 계속 문제가 발생함

SRT 링크가 정상이지만 시청자에게 멈춤이나 아티팩트가 보인다면 다운스트림에 문제가 있을 수 있습니다. 트랜스코딩, 패키징, 오리진, CDN, 플레이어 동작 및 출력 형식을 확인하십시오. 전체 체인을 확인하기 전에는 SRT 서버를 탓하지 마십시오.

자체 호스팅 및 관리형 SRT 서버

SRT 서버를 직접 운영하거나 관리형 플랫폼을 사용할 수 있습니다. 더 나은 선택은 팀이 어느 정도의 운영 제어를 직접 맡고 싶은지에 따라 달라집니다.

Callaba는 클라우드 또는 자체 호스팅 SRT 워크플로 플랫폼으로 사용할 수 있습니다. AWS에서 실행하거나 자체 서버에 설치하고, SRT 인제스트 지점을 생성한 뒤 해당 스트림을 재스트리밍, 녹화, 라우팅, 브라우저 미리보기, 멀티뷰, 플레이어 전송 및 API 워크플로에 연결할 수 있습니다.

SRT 서버 행사 당일 체크리스트

• 서버 IP 또는 호스트 이름을 확인합니다.
• UDP 포트가 열려 있는지 확인합니다.
• 양쪽의 Caller/Listener/Rendezvous 모드를 확인합니다.
• 사용하는 경우 Stream ID를 확인합니다.
• 사용하는 경우 암호화 패스프레이즈를 확인합니다.
• 예상 비트레이트, 코덱, 프레임 레이트, 해상도 및 오디오 형식을 확인합니다.
• 스트림을 시작하고 수신 비트레이트를 확인합니다.
• RTT, 패킷 손실, 재전송 및 지터를 확인합니다.
• 연결 상태뿐 아니라 실제 비디오와 오디오를 확인합니다.
• 다운스트림 경로(녹화, 재스트리밍, 트랜스코딩 또는 재생)를 확인합니다.
• 시간 동기화를 확인합니다. 문제 해결 시 로그와 녹화물을 연관 지을 수 있도록 서버와 인코더가 NTP 또는 다른 일관된 시간 소스를 사용해야 합니다.
• 이벤트가 시작되기 전에 백업 경로를 테스트합니다.

공식 참고 자료 및 관련 문서

프로토콜 수준의 SRT 세부 정보, Callaba 설정 문서 또는 관련 워크플로 가이드가 필요할 때 이용하십시오.

• SRT 프로토콜 초안
• Haivision SRT Live Transmit 문서
• SRT 프로토콜이란 무엇인가요?
• OBS Studio에서 SRT 스트리밍을 시작하는 방법
• OBS Studio에서 SRT 스트림을 수신하는 방법
• vMix를 통한 SRT 스트림 송수신
• SRT 설정에 적합한 지연 시간 찾기
• SRT 서버 API 문서

자주 묻는 질문

SRT 서버란 무엇인가요?

SRT 서버는 SRT 스트림을 수신, 전송 또는 라우팅하는 라이브 비디오 인제스트 또는 중계 엔드포인트입니다. 일반적으로 인코더, 카메라, 원격 행사장, 스튜디오, 모바일 디바이스 또는 파트너 시스템의 라이브 피드를 통제된 미디어 워크플로로 전달하는 데 사용합니다.

SRT 라이브 서버란 무엇인가요?

SRT 라이브 서버는 실시간 라이브 비디오 콘트리뷰션에 사용하는 SRT 서버입니다. 이벤트가 진행되는 동안 라이브 비디오를 수신하고 스트림을 녹화, 재스트리밍, 트랜스코딩, 스위칭, 라우팅 또는 재생 워크플로로 전달합니다.

SRT 서버와 스트리밍 서버는 같은가요?

항상 같지는 않습니다. SRT 서버는 일반적으로 통제된 엔드포인트 사이의 라이브 인제스트나 전송을 처리합니다. 완전한 스트리밍 플랫폼은 트랜스코딩, 녹화, 시청자 재생, 분석, 접근 제어, API 워크플로 및 CDN 전송도 처리할 수 있습니다.

SRT 서버는 UDP를 사용하나요?

예. SRT는 UDP에서 실행됩니다. 따라서 서버 방화벽, 클라우드 보안 그룹, 라우터 또는 네트워크 정책에서 올바른 UDP 포트를 열어야 합니다.

SRT 서버는 어떤 포트를 사용하나요?

SRT에는 모든 환경에 공통인 고정 포트가 없습니다. 포트는 서버 구성에서 정의합니다. 프로덕션 환경에서는 보통 SRT 인제스트용 UDP 포트나 포트 범위를 명확히 예약하고 각 포트를 사용하는 피드, 테넌트 또는 이벤트를 문서화합니다.

SRT 서버는 Listener와 Caller 중 어느 모드여야 하나요?

대부분의 클라우드 인제스트 워크플로에서는 SRT 서버가 Listener이고 인코더가 Caller입니다. 서버에 공인 IP 또는 DNS 이름, 알려진 UDP 포트 및 명확한 방화벽 규칙이 있을 때 잘 작동합니다.

OBS에서 SRT 서버로 전송할 수 있나요?

예. SRT 출력 URL을 구성하면 OBS에서 SRT 서버로 비디오를 전송할 수 있습니다. 서버가 스트림을 수신해 녹화, 재스트리밍, 트랜스코딩 또는 재생 워크플로로 라우팅할 수 있습니다.

vMix에서 SRT 서버로 전송할 수 있나요?

예. vMix는 SRT 워크플로를 지원하며 SRT 스트림을 전송하거나 수신할 수 있습니다. 일반적인 설정은 vMix에서 Callaba로 SRT를 전송하고 Callaba가 모니터링, 라우팅, 녹화 또는 재스트리밍을 처리하는 방식입니다.

SRT가 RTMP보다 더 좋은가요?

불안정하거나 손실이 있거나 장거리인 네트워크에서 콘트리뷰션할 때는 일반적으로 SRT가 RTMP보다 적합합니다. RTMP는 간단한 퍼블리싱과 플랫폼 인제스트에 여전히 흔히 사용됩니다. 많은 워크플로가 콘트리뷰션에는 SRT를, 소셜 플랫폼으로의 최종 전송에는 RTMP 또는 RTMPS를 사용합니다.

브라우저에서 SRT를 직접 재생할 수 있나요?

일반적인 웹 워크플로에서 브라우저는 SRT를 직접 재생하지 않습니다. SRT 서버가 먼저 스트림을 수신한 다음 플랫폼이 HLS 또는 WebRTC 같은 시청자용 형식으로 변환하거나 패키징합니다.

SRT 스트림은 연결되는데 비디오가 표시되지 않는 이유는 무엇인가요?

SRT 전송 연결이 작동해도 미디어 페이로드가 잘못되었을 수 있습니다. 코덱, 컨테이너, 타임스탬프, 키프레임, 오디오 트랙, 스트림 매핑, 다운스트림 호환성 및 비트레이트가 서버에 실제로 도착하는지 확인하십시오.

SRT 서버의 신뢰성을 높이려면 어떻게 해야 하나요?

안정적인 서버를 사용하고 올바른 UDP 포트를 열며 현실적인 지연 시간을 선택하십시오. RTT와 재전송을 모니터링하고 충분한 대역폭 여유를 유지하며 미디어 페이로드를 검증하고 이벤트 전에 백업 엔드포인트를 테스트하십시오.

SRT는 일반적으로 MPEG-TS를 전달하나요?

라이브 비디오 워크플로에서 SRT는 다중화된 오디오와 비디오가 포함된 MPEG-TS를 전달하는 데 자주 사용되지만 정확한 미디어 컨테이너는 송신자와 워크플로에 따라 달라집니다. 서버는 SRT 연결뿐 아니라 페이로드도 검증해야 합니다.

가장 먼저 확인해야 할 SRT 서버 지표는 무엇인가요?

수신 비트레이트, RTT, 패킷 손실, 재전송 및 연결 상태부터 확인하십시오. 상태가 양호하면 RTT는 20–60 ms 정도일 수 있습니다. RTT가 지속적으로 150 ms를 넘거나 패킷 손실이 1–2%를 넘으면 지연 시간을 늘리거나 비트레이트를 낮추거나 네트워크 경로를 개선하십시오.

다음 단계

• SRT 프로토콜이란 무엇인가요?
• SRT와 RTMP 비교
• OBS Studio에서 SRT 스트리밍을 시작하는 방법
• OBS Studio에서 SRT 스트림을 수신하는 방법
• vMix를 통한 SRT 스트림 송수신
• SRT 설정에 적합한 지연 시간 찾기
• SRT 서버 API 문서

최종 업데이트: 2026년 7월 22일