실시간 스트리밍 프로토콜

Real Time Streaming Protocol

RTSP(Real Time Streaming Protocol)는 적절한 전송 프로토콜을 통해 멀티미디어 전송 스트림(인터랙티브 미디어, 비디오오디오 등)을 다중화하고 패킷화하기 위해 설계된 애플리케이션 수준의 네트워크 프로토콜입니다.RTSP는 엔터테인먼트 및 통신 시스템에서 스트리밍 미디어 서버를 제어하기 위해 사용됩니다.프로토콜은 엔드포인트 간의 미디어 세션을 설정하고 제어하는 데 사용됩니다.미디어 서버의 클라이언트는 재생, 녹음, 일시정지 등의 명령을 발행하여 서버에서 클라이언트로(디맨드 비디오) 또는 클라이언트에서 서버로(음성 녹음) 미디어 스트리밍을 실시간으로 제어할 수 있도록 합니다.

역사

RTSP는 RealNetworks, Netscape[1] Columbia [2]University에 의해 개발되었습니다. 번째 초안은 1996년 10월 넷스케이프와 프로그레시브 네트웍스에 의해 IETF에 제출되었고, 이후 콜롬비아 대학의 헤닝 슐즈린느는 1996년 [3][4]12월에 "RTSP"("RTSP 프라임")를 제출하였다.2개의 초안은 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)의 Multiparty Multimedia Session Control Working Group(MMUSIC WG; 멀티파티 멀티미디어 세션컨트롤 워킹그룹)[5][6]에 의해 표준화를 위해 병합되어 작업 그룹에 의해 추가 초안이 발행되었습니다.RTSP의 표준안은 1998년[7]RFC 2326으로 공표되었습니다.RTSP 2.0은 RTSP 1.0을 대체하여 2016년에 RFC 7826으로 발행되었습니다.RTSP 2.0은 RTSP 1.0을 기반으로 하지만 기본 버전 네고시에이션메커니즘 이외에는 하위 호환성이 없으며 "제안된 표준"[8]으로 유지됩니다.

RTP

스트리밍 데이터 전송 자체는 RTSP의 작업이 아닙니다.대부분의 RTSP 서버는 Real-time Transport Protocol(RTP)과 Real-time Control Protocol(RTCP)을 함께 사용하여 미디어 스트림을 전송합니다.그러나 일부 공급업체는 독점 전송 프로토콜을 구현합니다.예를 들어 RealNetworks의 RTSP 서버 소프트웨어에서도 RealNetworks의 독자적인 Real Data Transport(RDT)가 사용되었습니다.

프로토콜 지침

RTSP는 HTTP와 어떤 면에서는 비슷하지만 멀티미디어 재생 제어에 도움이 되는 제어 시퀀스를 정의합니다.HTTP가 스테이트리스인 반면 RTSP에는 스테이트가 있습니다.동시 세션을 추적하기 위해 필요한 경우 식별자가 사용됩니다.HTTP와 마찬가지로 RTSP는 TCP를 사용하여 엔드 투 엔드 접속을 유지합니다.대부분의 RTSP 제어 메시지는 클라이언트에서 서버로 전송되지만 일부 명령어는 다른 방향(서버에서 클라이언트)으로 전송됩니다.

여기에서는 기본적인 RTSP 요구를 나타냅니다.OPTIONS 요청과 같은 일반적인 HTTP 요청도 사용할 수 있습니다.TCP 와 UDP 의 양쪽 모두의 디폴트 트랜스포트 레이어 포토 번호는 554[7] 로, 제어 요구에는 거의 사용되지 않습니다.

옵션들

OPTIONS 요청은 서버가 받아들일 요청 유형을 반환합니다.
C->S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 1 요건: 암묵적 재생 프록시-Require: gziped-private S-> C: RTSP/1.0 200 OK CSeq: 1 퍼블릭: 설명, 셋업, 티어다운, 재생, 일시정지

묘사하라

DESCRIBE 요구에는 RTSP URL(rtsp://...) 및 처리할 수 있는 응답 데이터의 유형이 포함됩니다.이 응답에는 프레젠테이션에 대한 설명이 포함됩니다.보통은 Session Description Protocol(SDP) 형식입니다.특히 프레젠테이션 설명에는 집약 URL로 제어되는 미디어 스트림이 나열되어 있습니다.일반적으로 오디오스트림과 비디오스트림에는 각각1개의 미디어 스트림이 있습니다.미디어 스트림 URL은 SDP 제어 필드에서 직접 가져오거나 집약 URL에 SDP 제어 필드를 추가하여 가져옵니다.
C->. S:DESCRIBErtsp://example.com/media.mp4RTSP/1.0 CSeq:2S->. C:RTSP/1.0 200OKCSeq:2Content-Base:rtsp://example.com/media.mp4Content-Type:application/sdp-Length:460m=video 0RTP/AVP 96a=control:streamid=0 a=range:npt=0-7.741000 a=length:npt=7.741000 a=rtpmap:96.MP4V-ES/5544 a=control type:string;"video/MP4V-ES" a=AvgBitRate:integer;304018 a=StreamName:string;"hinted video track" m=hinted 0 RTP/AVP 97 a=control:streamid=1a=range:npt=0-712000=a:npt=a:npt=length.err;65790 a=StreamName:string;"힌트 오디오트랙"

세우다

SETUP 요청은 단일 미디어 스트림을 전송하는 방법을 지정합니다.이 작업은 PLAY 요청을 전송하기 전에 수행해야 합니다.요청에는 미디어 스트림 URL 및 전송 지정자가 포함됩니다.일반적으로 이 지정자에는 RTP 데이터(오디오 또는 비디오)를 수신하는 로컬포트와 RTCP 데이터(메타 정보)를 수신하는 로컬포트가 포함됩니다.서버 응답은 일반적으로 선택된 매개변수를 확인하고 서버의 선택된 포트와 같은 누락된 부분을 채웁니다.집약 재생 요구를 송신하려면 , SETUP 를 사용해 각 미디어 스트림을 설정할 필요가 있습니다.
C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0 CSeq: 3 트랜스포트: RTP/AVP; 유니캐스트; client_port=8000-8001 S->C: RTSP/1.0 200 OK CSeq: 3 트랜스포트: RTPast/UnicABCD 세션: 12345678 C-> S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSeq: 3 트랜스포트: RTP/AVP;unicast;client_port=8002-8003 세션: 12345678 S->C: RTSP/1.0E 트랜스포트: OK 200 CS:ABCD 세션: 12345678

놀고

PLAY 요구에 의해 1개 또는 모든 미디어 스트림이 재생됩니다.재생 요청은 여러 PLAY 요청을 전송하여 쌓을 수 있습니다.URL은 집약 URL(모든 미디어 스트림을 재생하는 경우) 또는 단일 미디어 스트림 URL(그 스트림만 재생하는 경우)입니다.범위를 지정할 수 있습니다.범위를 지정하지 않으면 스트림이 처음부터 재생되어 끝까지 재생됩니다.스트림이 일시 중지된 경우 일시 중지된 지점에서 재개됩니다.
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 범위: npt=5-20 세션: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 세션: 12345678 RTP-Info url=rp///example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012:

멈추다

PAUSE 요구는 1개 또는 모든 미디어 스트림을 일시적으로 중지하므로 나중에 PLAY 요구로 재개할 수 있습니다.요청에는 집약 또는 미디어 스트림 URL이 포함됩니다. PAUSE 요청의 범위 매개 변수는 일시 중지할 시기를 지정합니다.range 파라미터를 생략하면 즉시 무한정 일시중지가 발생합니다.
C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 5 세션: 12345678 S->C: RTSP/1.0 200 OK CSeq: 5 세션: 12345678

기록.

이 메서드는 프레젠테이션 설명에 따라 미디어 데이터 범위의 기록을 시작합니다.타임스탬프는 시작 시간과 종료 시간(UTC)을 반영합니다.시간 범위가 지정되지 않은 경우 프레젠테이션 설명에 제공된 시작 시간 또는 종료 시간을 사용하십시오.세션이 이미 시작된 경우 즉시 기록을 시작합니다.서버는 녹음된 데이터를 요청 URI로 저장할지 다른 URI로 저장할지 결정합니다. 서버가 요청 URI를 사용하지 않을 경우 응답은 201이어야 하며 요청 상태를 설명하고 새 리소스를 참조하는 엔티티와 위치 헤더를 포함해야 합니다.
C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 6 세션: 12345678 S-> C: RTSP/1.0 200 OK CSeq: 6 세션: 12345678

발표하다

AnNOWNE 메서드는 다음 두 가지 목적으로 사용됩니다.

클라이언트에서 서버로 전송될 때 NANCE는 요청 URL로 식별된 프레젠테이션 또는 미디어 개체의 설명을 서버에 게시합니다.서버에서 클라이언트로 전송되면 AnNOWNE은 세션 설명을 실시간으로 업데이트합니다.새로운 미디어 스트림이 프레젠테이션에 추가된 경우(라이브 프레젠테이션 중 등), 컴포넌트를 삭제할 수 있도록 추가 컴포넌트뿐만 아니라 프레젠테이션 설명 전체를 다시 전송해야 합니다.
C->S: NOTNIFY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 7일: 1997년 1월 23일 15:35:06 GMT 세션: 12345678 Content-Type: application/sdp Content-Length: 332 v=0 o=mhandley 2890816464 IP.http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=IN IP4 224.2.17.12/http=2873397496 2873404696 a=recvonly m=http 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 S->C: RTSP 200e OK/1.

분해.

TeARDOWN 요구는 세션을 종료하기 위해 사용됩니다.그러면 모든 미디어 스트림이 중지되고 서버상의 모든 세션 관련 데이터가 해방됩니다.
C->S: 해체 rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 8 세션: 12345678 S-> C: RTSP/1.0 200 OK CSeq: 8

GET_파라미터

GET_PARAMETER 요구는 URI에서 지정된 프레젠테이션 또는 스트림의 파라미터 값을 가져옵니다.회신 및 응답 내용은 구현에 맡겨집니다.엔티티 본문이 없는 GET_PARAMETER를 사용하여 클라이언트 또는 서버의 라이브 테스트("ping")를 수행할 수 있습니다.
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 9 Content-Type: 텍스트/파라미터 세션: 12345678 Content-Length: 15 packets_parameter 지터 C-> S: RTSP/1.0 200 OK CSeq: 9 Content-Length: 46 - Length

SET_파라미터

이 메서드는 URI에 의해 지정된 프레젠테이션 또는 스트림의 파라미터 값을 설정하도록 요구합니다.
C->S: SET_PARAMER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 10 컨텐츠 길이: 20 컨텐츠 유형: 텍스트/파라미터 barparam: barstuff S->C: RTSP/1.0 451 비활성 파라미터 CSeq: 10-Length 텍스트 유형:

리다이렉트

REDIRECT 요청은 클라이언트에 다른 서버 위치에 연결해야 함을 알려줍니다.여기에는 클라이언트가 해당 URL에 대한 요청을 발행해야 함을 나타내는 필수 헤더 Location이 포함되어 있습니다.리다이렉션이 유효하게 되는 시기를 나타내는 파라미터의 Range 를 포함할 수 있습니다.클라이언트가 이 URI에 대해 미디어를 계속 송수신하는 경우 클라이언트는 현재 세션에 대해 해체 요청을 발행하고 지정된 호스트에서 새 세션에 대해 SETUP을 발행해야 합니다.
S->C:REDIRECT rtsp://example.com/media.mp4 RTSP/1.0 CSeq:11 장소:rtsp://bigserver.com:8001 범위: clock=19960213T143205Z-

임베디드(인터리브) 바이너리 데이터

특정 방화벽 설계 및 기타 상황에서는 서버가 RTSP 메서드를 인터리브하여 데이터를 스트리밍해야 할 수 있습니다.일반적으로 이 인터리빙은 클라이언트와 서버의 조작을 복잡하게 하고 추가 오버헤드를 초래하기 때문에 필요한 경우를 제외하고는 피해야 합니다.인터리브 바이너리 데이터는 RTSP가 TCP를 통해 전송되는 경우에만 사용해야 합니다.RTP 패킷등의 스트림 데이터는, ASCII 달러 기호(24 진수)에 의해서 캡슐화 되고, 그 다음에 1 바이트의 채널 ID, 그 다음에 2 바이트의 바이너리 정수로 캡슐화 됩니다.스트림 데이터는 그 직후에 CRLF 없이 상위 계층 프로토콜 헤더를 포함합니다.각 $ 블록은 정확히 하나의 상위 계층 프로토콜 데이터 단위(예: 하나의 RTP 패킷)를 포함합니다.
C->. S:chainrtsp://example.com/media.mp4RTSP/1.0 CSeq:3교통:RTP/AVP/TCP,interleaved=0-1 S->. C:RTSP/1.0 200OKCSeq:3날짜:056월 1997년 18:57:18GMT전송:RTP/AVP/TCP,interleaved=0-1 세션:12345678 C->. S:PLAYrtsp://example.com/media.mp4RTSP/1.0 CSeq:4세션:12345678.  S->. C:RTSP/1.0 200OKCSeq:4세션:12345678 날짜:056월 1997년 18:59시 15분 GMTRTP-Info:url=rtsp://example.com/media.mp4, seq=232433, rtptime=972948234 S->. C:달러 \000{2바이트 길이}{"길이"바이트 데이터,w/RTP 헤더}S->. C:달러 \000{2바이트 길이}{"길이"바이트 데이터,w/RTP 헤더}S->. C:달러 \001{2바이트 길이}{"길이"RTSPpa. bytescket}

환율 조정

RTP 및 RTCP를 사용한RTSP를 사용하면 환율 [9]적응을 구현할 수 있습니다.

실장

서버

  • Darwin Streaming Server: Apple이 관리하는 Quick Time Streaming Server의 오픈 소스 버전.
  • Feng: RFC 준거에 중점을 둔 희박하고 평균적인 스트리밍 서버.
  • GStreamer 기반 RTSP 서버 및 클라이언트.
  • Helix DNA Server: RealNetworks의 스트리밍 서버.오픈 소스 및 독자 사양이 있습니다.
  • Helix Universal Server: RTSP, RTMP, iOS, Silverlight 및 HTTP 스트리밍 미디어 클라이언트용 RealNetworks 상용 스트리밍 서버
  • 라이브 555 미디어 / 오픈 RTSP: VLCmplayer 등의 유명한 클라이언트에서 사용되는 오픈 소스 C++ 서버 및 클라이언트 라이브러리.
  • 모션: Linux용 무료 CCTV 소프트웨어 애플리케이션.
  • Nimble Streamer는 TCP 인터리브 재생 출력을 사용한 RTSP 풀 및 아나운스 입력을 지원합니다.
  • pvServer:이전에 PacketVideo Streaming Server로 불렸던 이 제품은 Alcatel-Lucent의 스트리밍 서버 제품입니다.
  • QuickTime 스트리밍 서버: Mac OS X Server와 함께 제공되는 Apple의 폐쇄 소스 스트리밍 서버입니다.
  • 비디오 LAN: 오픈 소스 미디어 플레이어와 스트리밍 서버.
  • Windows Media 서비스:Windows Media 확장 기능으로 수정된 RTSP를 사용하는 Windows Server에 포함되어 있던 Microsoft 스트리밍 서버
  • Wowza 스트리밍 엔진:RTSP/RTP, RTP, RTP, MPEG-TS, ICY, HTTP(HTTP Live Streaming, HTTP Dynamic Streaming, Smooth Streaming, MPEG-DASH), WebRTC용 다중 형식 스트리밍 서버
  • YouTube는 2007년 6월에 이 [10]프로토콜을 통해 비디오를 제공하는 모바일 웹 프런트 엔드를 구현했습니다.

많은 CCTV/보안 카메라(일명 IP 카메라)도 RTSP 스트리밍을 지원하며, 특히 ONVIF 프로파일이 G, S, T인 카메라도 지원합니다.

고객

레퍼런스

  1. ^ InfoWorld Media Group, Inc. (2 March 1998). InfoWorld. InfoWorld Media Group, Inc. p. 18. ISSN 0199-6649.
  2. ^ Rafael Osso (1999). Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. p. 42. ISBN 978-1-4200-4962-6.
  3. ^ Rao, Anup; Lanphier, Rob. "Real Time Streaming Protocol (RTSP)". tools.ietf.org. Retrieved 2021-02-23.
  4. ^ 'RTSP prime' 헤닝 슐즈린, 컬럼비아 대학교(http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps) 1996년 12월
  5. ^ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1997-02-24). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)". tools.ietf.org. Retrieved 2021-02-23.{{cite web}}: CS1 maint :url-status (링크)
  6. ^ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1998-01-15). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)". tools.ietf.org. Retrieved 2021-02-23.{{cite web}}: CS1 maint :url-status (링크)
  7. ^ a b RFC 2326, RTSP, IETF, 1998
  8. ^ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob; Westerlund, Magnus; Stiemerling, Martin (December 2016). "Real-Time Streaming Protocol Version 2.0". tools.ietf.org. Retrieved 2021-02-23.{{cite web}}: CS1 maint :url-status (링크)
  9. ^ Santos, Hugo; Cruz, Rui Santos; Nunes, Mário Serafim (2010), "Rate Adaptation Techniques for WebTV", Rate Adaption Techniques for WebTV, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol. 40, pp. 161–168, doi:10.1007/978-3-642-12630-7_19, ISBN 978-3-642-12629-1
  10. ^ "YouTube Mobile A Bust! (Getting 3GP/RTSP to work on WM5)". Chris Duke. 2007-06-23. Retrieved 29 May 2021.
  11. ^ cURL : 변경사항
  12. ^ "FFmpeg Documentation". The FFmpeg project. September 11, 2012. Section 20.19. Retrieved 2012-09-11.

외부 링크