SRT 소개 | 특징 | 시작하기 | 빌드 지침 | 샘플 앱 및 도구 | 기여 | 라이센스 | 릴리스
SRT(Secure Reliable Transport) 는 초저(1초 미만) 지연 시간의 라이브 비디오 및 오디오 스트리밍은 물론 일반 대량 데이터 전송을 위한 전송 프로토콜입니다 1 . SRT는 GitHub의 코드, 게시된 인터넷 초안 및 점점 늘어나는 SRT 사용자 커뮤니티를 통해 오픈 소스 기술로 제공됩니다.
SRT는 비디오 스트림 워크플로우의 일부로 제공 및 배포 엔드포인트에 적용되어 항상 최고의 품질과 가장 낮은 지연 시간의 비디오를 제공합니다.
안전한 | 비디오 스트림을 암호화합니다. |
믿을 수 있는 | 심각한 패킷 손실로부터 복구 |
운송 | 변화하는 네트워크 조건에 동적으로 적응 |
라이브 스트리밍 구성에서 SRT 프로토콜은 일정한 종단 간 대기 시간을 유지합니다. 이를 통해 라이브 스트림의 신호 특성을 수신기 측에서 재현할 수 있으므로 버퍼링의 필요성이 줄어듭니다. 패킷이 소스에서 대상으로 스트리밍됨에 따라 SRT는 두 엔드포인트 간의 실시간 네트워크 상태를 감지하고 이에 적응합니다. 이는 잡음이 많은 네트워크의 정체로 인한 지터 및 대역폭 변동을 보상하는 데 도움이 됩니다.
SRT는 미디어 스트림의 페이로드를 보호하기 위해 AES 암호화를 구현하고 ARQ(Automatic Repeat reQuest)가 기본 방법인 인터넷 연결에서 일반적으로 발생하는 패킷 손실을 최소화하기 위한 다양한 오류 복구 메커니즘을 제공합니다. ARQ를 사용하면 수신자가 패킷 누락을 감지하면 누락된 패킷의 재전송을 요청하는 경고를 발신자에게 보냅니다. 원활한 스트림 보호 및 무중단 장애 조치를 추가하는 FEC(순방향 오류 수정) 및 연결 본딩도 프로토콜에서 지원됩니다.
프로토콜에 대해 자세히 알아보려면 Innovation Labs 블로그를 구독하세요.
질문을 하려면 #개발 채널 대화에 참여하세요.
? 기능 설명을 확장하려면 ► 버튼을 클릭하세요.
네트워크가 아무리 불안정하더라도 SRT는 심각한 패킷 손실과 지터를 복구하여 비디오 스트림의 무결성과 품질을 보장할 수 있습니다.
SRT의 스트림 오류 수정은 사용자의 배포 조건에 맞게 구성할 수 있습니다. 실시간 IP 통신 개발을 활용하여 기존 네트워크 오류 복구 방식을 확장한 SRT는 TCP/IP보다 대기 시간이 현저히 낮은 미디어를 제공하는 동시에 신뢰성이 크게 향상된 UDP 전송 속도를 제공합니다.
특정 비디오 및 오디오 형식만 지원하는 다른 스트리밍 프로토콜과 달리 SRT는 페이로드에 구애받지 않습니다. SRT는 네트워크 전송 수준에서 작동하여 콘텐츠 주변의 래퍼 역할을 하므로 모든 유형의 비디오 형식, 코덱, 해상도 또는 프레임 속도를 전송할 수 있습니다.
SRT에서 사용하는 핸드셰이킹 프로세스는 방화벽에서 영구적인 외부 포트가 열리는 잠재적인 위험과 위험 없이 아웃바운드 연결을 지원하므로 기업 LAN 보안 정책을 유지하고 IT 개입의 필요성을 최소화합니다.
SRT는 전 세계 정부와 조직이 신뢰하는 128/192/256비트 AES 암호화를 사용하여 귀중한 콘텐츠가 제공에서 배포까지 엔드 투 엔드로 보호되어 승인되지 않은 당사자가 청취할 수 없도록 보장합니다.
SRT 1.4에는 패킷 필터 API 가 도입되었습니다. 이 메커니즘을 사용하면 네트워크 패킷을 전송하기 전에 발신자 측에서, 네트워크에서 수신한 후 수신자 측에서 사용자 정의 처리를 수행할 수 있습니다. API를 사용하면 사용자는 자신만의 플러그인을 작성할 수 있으므로 모든 종류의 다양한 패킷 필터링을 통해 SRT 프로토콜의 기능을 더욱 확장할 수 있습니다. 사용자는 사용자 정의 암호화, 패킷 검사 또는 전송 전 데이터 액세스 등 어떤 방식으로든 결과 패킷 필터 데이터를 조작할 수 있습니다.
패킷 필터 API로 달성할 수 있는 작업의 예로 생성된 첫 번째 플러그인은 FEC(순방향 오류 수정)용으로, 특정 사용 사례에서는 ARQ(자동 반복 요청)보다 대기 시간이 약간 더 낮을 수 있습니다. 이 플러그인은 세 가지 모드를 허용합니다.
ARQ 전용 – 손실된 패킷을 재전송합니다.
FEC 전용 – 수신기 측에서 FEC 복구에 필요한 오버헤드를 제공합니다.
FEC 및 ARQ – FEC가 복구하지 못한 손실된 패킷을 재전송합니다.
관리형 네트워크를 통한 SMPTE-2022-7과 유사하게 연결 본딩은 SRT 프로토콜에 원활한 스트림 보호 및 무중단 장애 조치를 추가합니다. 이 기술은 둘 이상의 IP 네트워크 경로를 사용하여 네트워크 정체 또는 중단 시 라이브 비디오 스트림의 중단을 방지하고 서비스 연속성을 유지합니다.
이는 SRT v1.5에 도입된 소켓 그룹을 사용하여 수행됩니다. 소켓 그룹의 일반적인 개념은 여러 소켓을 포함하는 그룹을 갖는 것을 의미하며, 여기서 하나의 데이터 신호를 보내는 하나의 작업이 그룹에 적용됩니다. 그룹 내의 단일 소켓이 이 작업을 대신하고 신호를 수신기에 전달하는 데 필요한 작업을 수행합니다.
두 가지 모드가 지원됩니다:
브로드캐스트 - 브로드캐스트 모드에서는 데이터가 그룹의 모든 구성원 링크를 통해 중복 전송됩니다. 링크 중 하나가 실패하거나 네트워크 지터 및/또는 패킷 손실이 발생하면 누락된 데이터가 그룹의 다른 링크를 통해 수신됩니다. 중복 패킷은 수신자 측에서 간단히 삭제됩니다.
메인/백업 - 메인/백업 모드에서는 한 번에 하나의 (메인) 링크만 데이터 전송에 사용되고 다른 (백업) 연결은 대기 상태에 있어 메인 링크에 장애가 발생하더라도 전송이 계속되도록 합니다. 기본/백업 모드의 목표는 잠재적인 링크 중단이 발생하기 전에 이를 식별하여 백업 링크 중 하나로 원활하게 전환할 수 있는 시간 창을 제공하는 것입니다.
액세스 제어를 사용하면 업스트림 애플리케이션이 스트림 ID를 개별 SRT 스트림에 할당할 수 있습니다. 자동으로 생성되거나 사용자 정의된 고유한 스트림 ID를 사용하여 업스트림 애플리케이션은 여러 SRT 스트림을 단일 IP 주소 및 UDP 포트로 보낼 수 있습니다. 그런 다음 수신자는 스트림 ID를 사용하여 수집 스트림을 식별 및 구별하고, 사용자 비밀번호 액세스 방법을 적용하고, 경우에 따라 스트림 ID의 이름을 기반으로 자동화를 적용할 수도 있습니다. 예를 들어 기여는 비디오 제작 워크플로우로 전송되고 모니터링은 모니터링 서비스로 전송될 수 있습니다.
방송사의 경우 스트림 ID는 비디오 스트림, 특히 HEVC/H.265 콘텐츠를 수신 비디오용으로 열려 있는 단일 IP 소켓(주소 + 포트)이 있는 클라우드 서비스 또는 CDN으로 수집하기 위해 RTMP를 대체하는 데 핵심입니다.
SRT API | IETF 인터넷 초안 | 샘플 앱 |
SRT 라이브러리 API에 대한 참조 문서 | SRT 프로토콜 인터넷 초안 | 테스트 앱 사용 지침( srt-live-transmit , srt-file-transmit 등) |
SRT 기술 개요 | SRT 배치 가이드 | SRT 요리책 |
초기 초안 기술 개요(인터넷 초안의 전신) | 배포 지침이 포함된 프로토콜의 포괄적인 개요 | SRT 프로토콜에 대한 개발 노트 |
혁신 연구소 블로그 | SRTLab 유튜브 채널 | 느슨하게 |
SRT 관련 기술 기사가 담긴 Medium 블로그 | 유용한 동영상이 포함된 기술 YouTube 채널 | 최신 업데이트를 받고 질문할 수 있는 Slack 채널 Slack에서 SRT Alliance에 가입하세요 |
왜 SRT인가? - Marc Cymontkowski의 SRT에 대한 간략한 역사와 이론적 근거.
RTMP와 SRT: 지연 시간과 최대 대역폭 비교 백서.
SRT API 문서, 기능 설명 등이 포함된 GitHub 문서
SRT 프로토콜 인터넷 초안: Datatracker | 최신 버전 | 최신 작업 사본 | GitHub 레포
리눅스(우분투/CentOS) | 윈도우 | macOS | iOS | 안드로이드 | 패키지 관리자
C++03 이상 호환 컴파일러.
빌드 시스템으로 CMake 2.8.12 이상.
암호화를 활성화하려면 OpenSSL 1.1을 사용하고, 그렇지 않으면 -DENABLE_ENCRYPTION=OFF
사용하여 빌드합니다.
멀티스레딩은 다음 중 하나로 제공됩니다.
C++11: 표준 라이브러리( std
by -DENABLE_STDCXX_SYNC=ON
CMake 옵션),
C++03: Pthread(POSIX 시스템의 경우 내장되어 있고 Windows의 경우 이식된 라이브러리가 있음).
Tcl 8.5는 선택 사항이며 ./configure
스크립트에서 사용됩니다. 그렇지 않으면 CMake를 직접 사용하세요.
빌드 시스템 및 옵션에 대한 자세한 설명은 SRT 빌드 옵션 문서를 읽어보세요.
현재 저장소는 SRT 라이브러리 API의 사용법을 보여주는 샘플 애플리케이션과 코드 예제를 제공합니다. 그 중에는 srt-live-transmit
, srt-file-transmit
및 기타 애플리케이션이 있습니다. 해당 문서는 여기에서 찾을 수 있습니다. 모든 샘플은 교육용으로 제공되며 프로덕션 환경에서 사용해서는 안 됩니다.
srt-xtransmit
유틸리티는 내부 테스트 및 성능 평가에 적극적으로 사용됩니다. 다른 기능 중에서도 더미 페이로드 생성, 트래픽 라우팅 및 연결 결합을 지원합니다. 추가 세부 정보는 srt-xtransmit
저장소 자체에서 확인할 수 있습니다.
개발 중에 유용할 수 있는 Python 도구는 다음과 같습니다.
srt-stats-plotting
- SRT .csv
통계를 기반으로 그래프를 플롯하도록 설계된 스크립트입니다.
lib-tcpdump-processing
- .pcap(ng)
tcpdump 또는 Wireshark 추적 파일을 처리하고 추가 분석을 위해 관심 있는 SRT 패킷을 추출하도록 설계된 라이브러리입니다.
lib-srt-utils
- 실험 구성을 기반으로 SRT 테스트를 실행하기 위한 지원 코드가 포함된 Python 라이브러리입니다.
누구나 기여할 수 있습니다. 참여하기로 결정하셨다면 잠시 시간을 내어 지침을 검토해 보시기 바랍니다.
SRT 개발자 가이드
기여
보고 문제
인터넷 초안 작성에 참여하거나 문제를 제출하는 방법에 대한 자세한 내용을 보려면 다음 저장소로 이동하세요. SRT CookBook에 기여하기 위한 저장소는 여기에서 찾을 수 있습니다.
SRT 프로젝트에 코드를 기여함으로써 귀하는 MPLv2.0 라이선스에 따라 귀하의 기여에 대한 라이선스를 부여하는 데 동의하게 됩니다.
릴리스 노트
SRT 버전 관리
"라이브 스트리밍"이라는 용어는 대기 시간 관리를 통한 지속적인 데이터 전송(MPEG-TS 또는 이와 동등한 것)을 의미합니다. HLS(HTTP 라이브 스트리밍) 프로토콜(RFC8216에 설명됨)과 같은 파일 분할 및 전송을 기반으로 하는 라이브 스트리밍은 이 사용 사례에 포함되지 않습니다. 이 경우 메시지 또는 버퍼 모드에서의 파일 전송을 고려해야 합니다. 자세한 내용은 섹션 7. 인터넷 초안의 SRT를 통한 데이터 전송에 대한 모범 사례 및 구성 팁을 참조하세요. SRT는 콘텐츠에 구애받지 않으며, 이는 모든 유형의 데이터가 페이로드를 통해 전송될 수 있음을 의미합니다. ↩