SRT 송출 대상으로 라이브 방송을 보내는 방법
SRT 송출 대상은 RTMP보다 몇 가지 정보가 더 필요합니다. 모드, 호스트와 포트, 그리고 흔히 스트림 ID, 암호문(passphrase), 지연 시간(latency)까지요. srt:// URL의 각 부분이 무엇을 뜻하는지, 방송을 어떻게 연결하는지 알아봅니다.
읽는 데 약 5분
이 페이지의 내용
SRT 송출 대상으로 라이브 방송을 보내려면, 수신 측에서 srt:// 주소를 받고, 어느 쪽이 대기(listen)하고 어느 쪽이 호출(call)하는지 확인한 뒤, 수신 측이 기대하는 스트림 ID, 암호문, 지연 시간을 맞추면 됩니다. 그다음 수신 측의 UDP 포트를 열고, 송신을 시작하고, 본격적으로 의지하기 전에 영상이 도착하는지 확인하세요.
SRT 설정은 작은 불일치 하나로도 깨지므로, 모든 세부 값을 정확히 맞추세요. 이 프로토콜이 처음이라면 SRT 스트리밍이란 무엇인가부터 시작하세요.
핵심 요약
- SRT 연결에서는 한쪽이 UDP 포트에서 대기하고, 다른 쪽이 그곳을 호출합니다.
- srt:// URL에는 호스트와 포트, 그리고 mode, streamid, passphrase 같은 옵션이 담깁니다.
- 대부분의 실패는 닫힌 포트, 양쪽 모두 호출자인 경우, 또는 암호문이나 스트림 ID 불일치에서 옵니다.
- 24시간 방송을 실제 운영 수신기로 보내기 전에 로컬에서 먼저 테스트하세요.
SRT 송출 대상은 실제로 누가 사용하나
일반적인 소셜 플랫폼으로 SRT를 보내는 경우는 드뭅니다. SRT 송출 대상은 보통 방송사, 기업, 파트너가 운영하는 시스템입니다.
- 방송 송출(플레이아웃)과 제작. 스튜디오는 SRT로 들어오는 중계 신호를 하드웨어 디코더, 스위처, 플레이아웃 시스템으로 받습니다.
- 미디어 서버. 자체 호스팅 및 상용 미디어 서버는 SRT를 받아 플레이어, 녹화, 추가 배포용으로 다시 포장합니다.
- 파트너 전달. 방송망, 행사장 스크린, 배급사에 프로그램을 공급하는 채널은 SRT로 전달하는 경우가 많습니다.
- 클라우드 영상 서비스. 일부 전문 플랫폼은 RTMP와 함께 SRT 인제스트를 제공합니다.
어느 경우든 수신 측 운영자가 정확히 맞춰야 할 연결 정보를 알려 줍니다. 상대편이 RTMP만 제공한다면 대신 사용자 지정 RTMP 서버 가이드를 따르세요.
caller, listener, rendezvous 모드
모든 SRT 연결에는 기다리는 쪽과 연결을 거는 쪽이 하나씩 필요합니다.
- Listener(리스너)는 UDP 포트에 바인딩하고 연결을 기다립니다. 외부에서 접근 가능한 주소와 열린 방화벽 포트가 필요합니다.
- Caller(콜러)는 리스너의 호스트와 포트로 연결합니다. 연결이 밖으로 나가는 방향이라 대부분의 방화벽 뒤에서도 작동합니다.
- Rendezvous(랑데부)는 양쪽이 약속한 포트로 동시에 서로를 호출하는 방식으로, 어느 쪽도 인바운드 트래픽을 받지 않을 때 도움이 됩니다.
모드는 영상이 흐르는 방향과는 관계가 없습니다. 클라우드 서비스나 인코더가 여러분의 서버로 전달할 때는 보통 송신 측이 콜러, 수신 측이 리스너가 됩니다.
대표적인 실수는 양쪽 모두 콜러이거나 양쪽 모두 리스너인 경우입니다. 뚜렷한 오류 없이 양쪽이 서로를 기다리기만 하므로, 수신 측 운영자와 모드를 확인하세요.
srt:// URL을 하나씩 읽어 보기
SRT 주소는 보통 다음과 같은 모습입니다.
srt://ingest.example.com:9000?mode=caller&streamid=channel-main&passphrase=YOUR-LONG-SECRET
- 호스트와 포트. 수신 측의 호스트 이름 또는 IP 주소와 대기 중인 UDP 포트입니다. 모두에게 통하는 기본 포트는 없으므로, 받은 포트를 사용하세요.
- mode. 내 쪽의 역할입니다. caller, listener, rendezvous 중 하나입니다.
- streamid. 일부 수신기가 신호를 라우팅하거나 인증하는 데 쓰는 식별자로, 스트림 키와 비슷합니다. 형식은 수신기에 따라 다릅니다.
- passphrase. AES 암호화를 위한 공유 비밀값으로, 보통 10자에서 79자 사이여야 합니다. 양쪽이 정확히 일치해야 합니다.
- pbkeylen. 선택 항목인 키 길이로 16, 24, 32바이트이며, 각각 AES-128, 192, 256을 뜻합니다.
- latency. 복구용 버퍼입니다. 일부 도구는 밀리초 단위를 쓰지만 FFmpeg 기반 소프트웨어는 흔히 마이크로초 단위를 기대하므로, 다른 설정에서 숫자를 복사하기 전에 확인하세요.
수신 측 준비하기
수신기를 직접 운영한다면, 무엇이든 보내기 전에 준비해 두세요.
- 리스너를 설정하세요. 미디어 서버, 디코더, 플레이아웃 소프트웨어에서 고정된 UDP 포트로 설정합니다.
- 그 UDP 포트를 여세요. 서버 방화벽과 앞단의 클라우드 보안 그룹이나 라우터 모두에서 엽니다. TCP 규칙은 SRT에 적용되지 않습니다.
- 암호문을 정하세요. 소프트웨어가 스트림 ID로 라우팅한다면 이 신호용 ID도 정합니다.
- 지연 시간을 정하세요. 경로에 맞게 고르며, 길거나 불안정한 경로일수록 더 필요합니다.
- 형식을 확인하세요. SRT는 보통 H.264 영상과 AAC 오디오가 담긴 MPEG-TS를 전송하므로, 수신기가 이를 받아들이는지 확인하세요.
- 로컬에서 테스트하세요. 다른 컴퓨터의 OBS나 FFmpeg로 짧은 신호를 보내 봅니다.
수신기가 승인된 주소만 받는다면, 송신 측 주소도 허용해 두세요.
시작되지 않는 SRT 연결 문제 해결
SRT 오류는 모호한 경우가 많으니, 증상별로 진단하세요.
- 연결 시간 초과. UDP 포트가 닫혀 있거나 포워딩되지 않았거나, 호스트가 틀렸거나, 양쪽이 같은 모드를 쓰고 있습니다.
- 연결 거부. 대개 암호문 불일치, 한쪽에만 설정된 암호문, 또는 수신기가 인식하지 못하는 스트림 ID 때문입니다.
- 연결된 뒤 끊기거나 멈칫거림. 네트워크 경로에 비해 지연 시간이 너무 낮거나, 대역폭이 비트레이트와 재전송 오버헤드를 합친 값보다 부족합니다. 먼저 지연 시간을 올리세요.
- 연결은 되지만 화면이나 소리가 없음. 수신기가 다른 컨테이너나 코덱을 기대하는 것이며, 로그에 대개 무엇인지 나옵니다.
작동하게 되면 연결에 성공한 모든 값을 기록해 두세요. 24시간 방송을 온라인으로 유지하기의 전반적인 습관은 SRT 송출 대상에도 똑같이 적용됩니다.
StreamHouse 방송에 SRT 송출 대상 추가하기
StreamHouse에서 SRT는 기본 제공 플랫폼과 나란히 있는 사용자 지정 송출 대상입니다. 수신 측의 전체 srt:// URL을 암호문 등 필요한 옵션까지 포함해 붙여 넣으세요. 스트림 ID나 키를 따로 받았다면 스트림 ID 입력란에 넣으세요. URL에 streamid가 없으면 StreamHouse가 이를 streamid 파라미터로 추가합니다. URL에 모드가 없으면 StreamHouse는 콜러로 연결하므로, 수신기는 대기(listen) 상태여야 합니다.
미리 인코딩된 영상의 반복 재생목록을 24시간 내내 수신기로 보내거나, 같은 방송에 YouTube, Twitch 등 다른 RTMP 송출 대상과 나란히 SRT를 추가할 수 있으며, 이때 방송 슬롯을 더 쓰지 않습니다. 클라우드에서 돌아가며 문제가 생겨도 자동으로 다시 연결됩니다. 시작 가이드에서 첫 방송 과정을 단계별로 안내합니다.
자주 묻는 질문
SRT는 어떤 포트를 사용하나요?
정해진 표준 포트는 없습니다. 리스너는 사용 가능한 어떤 UDP 포트든 쓸 수 있으며, 수신 측 운영자가 어느 포트인지 알려 줍니다. 그 포트는 송신 측과 리스너 사이의 모든 방화벽에서 UDP 트래픽용으로 열려 있어야 합니다.
SRT 송신 측은 콜러여야 하나요, 리스너여야 하나요?
보통은 송신 측이 호출하고 수신 측이 대기합니다. 수신기는 대개 고정 주소와 열린 포트를 갖고 있고, 송신 측은 방화벽 뒤에 있기 때문입니다. 양쪽이 반대 모드를 쓰거나 둘 다 랑데부를 쓴다면 기술적으로는 어느 쪽이든 작동합니다.
SRT 스트리밍의 지연 시간은 얼마로 설정해야 하나요?
흔한 출발점은 송신 측과 수신 측 사이 왕복 시간(RTT)의 몇 배이며, 손실이 많거나 장거리인 링크라면 더 늘립니다. 넉넉하게 시작해서 패킷 손실을 지켜보며 점차 낮추세요. 도구가 밀리초를 기대하는지 마이크로초를 기대하는지 확인하세요.
같은 방송에서 SRT와 RTMP를 함께 보낼 수 있나요?
도구가 여러 출력을 지원한다면 가능합니다. 클라우드 서비스는 공개 플랫폼에는 RTMP를, 비공개 수신기에는 SRT를 동시에 보낼 수 있으며, 여러분의 회선에서 추가 업로드도 필요 없습니다. 다만 각 송출 대상마다 올바른 세부 정보가 따로 필요합니다.


