실시간 메시징 프로토콜

이 글은 일반적인 참고문헌 목록을 포함하고 있지만, 그에 상응하는 인라인 인용구가 충분하지 않기 때문에 대체로 검증되지 않은 상태로 남아 있다. 보다 정확한 인용구를 도입하여 이 기사를 개선할 수 있도록 도와주십시오. (2014년 8월) (이 템플릿 메시지를 제거하는 방법 및 시기 알아보기)

실시간 메시징 프로토콜(RTMP)은 인터넷을 통해 오디오, 비디오, 데이터를 스트리밍하기 위한 통신 프로토콜이다.원래 Flash Player와 서버 간의 스트리밍을 위해 Macromedia에 의해 독점 프로토콜로 개발되었던 Adobe(Macromedia를 인수한)는 공공 사용을 위한 프로토콜 규격의 불완전한 버전을 발매했다.

RTMP 프로토콜은 다음과 같은 여러 가지 변형을 가진다.

1. RTMP right, TCP(Transmission Control Protocol) 위에서 작동하며 기본적으로 포트 번호 1935를 사용하는 "플레인" 프로토콜.
2. TLS/SSL(Transport Layer Security) 연결을 통한 RTMP인 RTMPS.
3. 어도비 자체 보안 메커니즘을 사용하여 암호화된 RTMPE.구현의 세부사항은 독점적이지만, 메커니즘은 산업 표준 암호 원형을 사용한다.^[1]
4. 방화벽을 통과하기 위해 HTTP 요청 내에 캡슐화된 RTMPT.RTMPT는 대부분의 기업 트래픽 필터링을 우회하기 위해 TCP 포트 80과 443의 클리어텍스트 요청을 활용하는 경우가 많다.캡슐화된 세션은 내부에 일반 RTMP, RTMPS 또는 RTMPE 패킷을 포함할 수 있다.
5. RTMFP, 즉 TCP 대신 UDP(User Datagram Protocol)를 통한 RTMP로, RTMP Chunk Stream을 대체한다.Secure Real-Time Media Flow Protocol 제품군은 Adobe Systems에 의해 개발되었으며 최종 사용자가 직접 연결하고 서로 통신할 수 있도록 한다(P2P).

RTMP의 주된 동기는 플래시 비디오를 재생하기 위한 프로토콜이었지만, Adobe LiveCycle Data Services ES와 같은 일부 다른 애플리케이션에서도 사용된다.

기본조작

RTMP는 지속적인 연결을 유지하고 낮은 지연 시간 통신을 허용하는 TCP 기반 프로토콜이다.스트림을 원활하게 전달하고 가능한 많은 정보를 전송하기 위해 스트림을 조각조각 분할하고, 클라이언트와 서버 사이에서 그 크기를 동적으로 협상한다.때로는 변경되지 않고 유지되기도 한다. 기본 조각 크기는 오디오 데이터의 경우 64바이트, 비디오 데이터 및 기타 대부분의 데이터 유형의 경우 128바이트가 된다.그런 다음 서로 다른 스트림의 파편을 인터리브하고 단일 연결로 멀티플렉싱할 수 있다.따라서 데이터 청크가 길면 프로토콜은 조각당 1바이트 헤더만 전송하므로 오버헤드가 거의 발생하지 않는다.그러나 실제로 개별 조각은 일반적으로 인터리빙되지 않는다.대신, 인터리빙과 멀티플렉싱은 패킷 수준에서 이루어지며, 여러 다른 활성 채널의 RTMP 패킷은 각 채널이 대역폭, 지연 시간 및 기타 서비스 품질 요건을 충족하도록 인터리빙된다.이러한 방식으로 인터리빙된 패킷은 분리할 수 없는 것으로 취급되며, 단편적인 수준에서 인터리빙되지 않는다.

RTMP는 패킷을 보내고 받을 수 있고 서로 독립적으로 작동하는 여러 가상 채널을 정의한다.예를 들어 RPC 요청 및 응답을 처리하는 채널, 비디오 스트림 데이터 채널, 오디오 스트림 데이터 채널, 대역 외 제어 메시지 채널(프레지션 크기 협상 등) 등이 있다.일반적인 RTMP 세션 동안, 주어진 시간에 여러 채널이 동시에 활성화될 수 있다.RTMP 데이터가 인코딩되면 패킷 헤더가 생성된다.패킷 헤더는 패킷이 전송될 채널의 ID, 패킷이 생성된 시점의 타임스탬프(필요한 경우), 패킷의 페이로드 크기를 지정한다.그런 다음, 이 헤더는 패킷의 실제 페이로드 콘텐츠에 따르며, 패킷은 연결을 통해 전송되기 전에 현재 합의된 조각 크기에 따라 단편화된다.패킷 헤더 자체는 결코 단편화되지 않으며, 그 크기는 패킷의 첫 조각에 있는 데이터에 반영되지 않는다.즉, 실제 패킷 페이로드(미디어 데이터)만 단편화 대상이 된다.

더 높은 레벨에서 RTMP는 MP3 또는 AAC 오디오와 FLV1 비디오 멀티미디어 스트림을 캡슐화하며, 액션 메시지 포맷을 사용하여 원격 프로시저 호출(RPC)을 할 수 있다.필요한 모든 RPC 서비스는 실시간 통신이 필요하지 않은 단일 클라이언트/서버 요청/응답 모델을 사용하여 비동기적으로 만들어진다.^{[clarification needed][2][3]}

암호화

RTMP 세션은 다음 두 가지 방법 중 하나를 사용하여 암호화될 수 있다.

• 산업 표준 TLS/SSL 메커니즘 사용.기본 RTMP 세션은 일반 TLS/SSL 세션 내에서 간단히 포장된다.
• RTMP 세션을 더 가벼운 암호화 계층으로 감싸는 RTMPE 사용.

HTTP 터널링

RTMP Tunneled(RTMPT)에서는 RTMP 데이터를 캡슐화하고 HTTP를 통해 교환하며, 클라이언트(이 경우 미디어 플레이어)로부터의 메시지는 서버의 포트 80(HTTP의 기본값)으로 어드레싱된다.

While the messages in RTMPT are larger than the equivalent non-tunneled RTMP messages due to HTTP headers, RTMPT may facilitate the use of RTMP in scenarios where the use of non-tunneled RTMP would otherwise not be possible, such as when the client is behind a firewall that blocks non-HTTP and non-HTTPS outbound traffic.

이 프로토콜은 POST URL을 통해 명령을 전송하고 POST 본체를 통해 AMF 메시지를 전송하는 방식으로 작동한다.예를 들면 다음과 같다.

POST /open/1 HTTP/1.1

연결 고리를 열어야 한다.

명세서 및 특허 라이선스

Adobe는 2012년 12월 21일자 프로토콜 버전 1.0의 사양을 발표했다.^[4]해당 사양으로 이어지는 웹 랜딩 페이지에는 "컨텐츠 보호를 원하는 고객에게 혜택을 주기 위해 오픈 RTMP 사양에는 Adobe의 고유한 보안 RTMP 대책이 포함되지 않는다"^[5]는 내용이 적혀 있다.

Adobe 규격에 첨부된 문서는 프로토콜의 모든 구현에 대해 "비독점, 로열티, 전송 불가, 비필수, 개인, 전세계" 특허 사용권을 부여하며, 두 가지 제한 사항: 스트리밍 데이터 가로채기("스트리밍 비디오, 오디오 및/또는 데이터 콘텐츠를 가로채는 모든 기술)기기나 매체에서의 노후화), 그리고 또 다른 것은 "Adobe의 안전한 RTMP 조치를 포함한 오디오, 비디오 및/또는 데이터 콘텐츠 보호를 위한 기술적 조치"^[6]의 우회적 사용을 금지한다.

특허 및 관련 소송

플래시에 관한 일부 서적의 저자 스테판 리히터는 2008년 어도비(Adobe)가 RTMP에 어떤 특허가 적용되는지 모호하지만 미국 특허 7,246,356은 그 중 하나로 보인다고 언급했다.^[2]

2011년에 Adobe는 Wowza Media Systems를 상대로 RTMP 특허를 침해했다고 주장했다.^[7][8][9]2015년 어도비와 와우자는 편견을 갖고 소송이 해결되고 기각됐다고 발표했다.^[10]

패킷 구조

RTMP 패킷 다이어그램

패킷은 클라이언트와 서버 사이에 먼저 설정된 TCP 연결을 통해 전송된다.연결 및 제어 명령의 경우 동작 메시지 형식(AMF)을 사용하여 인코딩되는 헤더와 본문을 포함한다.헤더는 기본 헤더(그림에서 나머지 헤더와 분리된 것으로 표시됨)와 청크 메시지 헤더로 분할된다.기본 헤더(Basic Header)는 패킷의 유일한 상수 부분이며, 일반적으로 단일 복합 바이트로 구성되며, 여기서 가장 중요한 두 비트는 청크 유형(규격의 fmt)이고 나머지는 스트림 ID이다.전자의 값에 따라 메시지 헤더의 일부 필드는 생략할 수 있으며, 후자의 값에 따라 기본 헤더는 1~2바이트의 추가 바이트(총 3바이트(c)가 있는 다이어그램의 경우처럼)로 확장할 수 있다.If the value of the remaining six bits of the Basic Header (BH) (least significant) is 0 then the BH is two bytes and represents from Stream ID 64 to 319 (64+255); if the value is 1, then the BH is three bytes (with last two bytes encoded as 16bit Little Endian) and represents from Stream ID 64 to 65599 (64+65535); if the value is 2, then BH is one 바이트이며, 낮은 수준의 프로토콜 제어 메시지와 명령을 위해 예약된다.청크 메시지 헤더에는 메시지 크기(바이트 단위로 측정), 타임스탬프 델타 및 메시지 유형과 같은 메타데이터 정보가 포함되어 있다.이 마지막 값은 단일 바이트로 패킷이 오디오, 비디오, 명령인지 또는 RTMP Ping과 같은 "로우 레벨" RTMP 패킷인지 여부를 정의한다.

플래시 클라이언트가 다음 코드를 실행할 때 캡처된 예는 아래와 같다.

시합을 하다 물줄기가 흐르다:넷스트림 = 새로운 넷스트림(connectionObject); 

이렇게 하면 다음 청크가 생성된다.

패킷은 단일 바이트(0x03)의 기본 헤더로 시작하여 여기서 가장 중요한 두 비트(b00000011)는 청크 헤더 유형을 0으로 정의하고 나머지 비트(b00000011)는 청크 스트림 ID를 3으로 정의한다.헤더 유형의 가능한 네 가지 값과 그 중요도는 다음과 같다.

• b00 = 12바이트 헤더(전체 헤더)
• b01 = 8바이트 - like 유형 b00, 메시지 ID(4 last 바이트)를 포함하지 않음.
• b10 = 4바이트 - 기본 헤더 및 타임스탬프(3바이트)가 포함됨
• b11 = 1바이트 - 기본 헤더만 포함됨

위의 예에서 두 번째 메시지가 0xC3(b11000011)의 ID로 시작하고 모든 메시지 헤더 필드가 스트림 ID가 3(바로 위의 메시지)인 메시지에서 파생되어야 하는 집계 메시지의 경우 마지막 유형(b11)이 항상 사용된다.스트림 ID를 형성하는 6개의 최하위 비트는 3에서 63 사이의 값을 가질 수 있다.어떤 값은 확장 ID 형식을 나타내는 1과 같이 특별한 의미를 가지며, 이 경우 그 뒤에 2바이트가 있게 된다.2의 값은 Ping 및 클라이언트 대역폭 설정과 같은 낮은 수준의 메시지에 대한 값이다.

RTMP 헤더의 다음 바이트(위의 예시 패킷의 값 포함)는 다음과 같이 디코딩된다.

• 바이트 #1(0x03) = 청크 헤더 유형.
• 바이트 #2-4(0x000b68) = 타임스탬프 델타.
• 바이트 #5-7(0x000019) = 패킷 길이 - 이 경우 0x000019 = 25바이트.
• 바이트 #8(0x14) = 메시지 유형 ID - 0x14(20)는 AMF0 인코딩 명령 메시지를 정의한다.
• 바이트 #9-12(0x00000000) = 메시지 스트림 ID.이것은 소인배 순서로 되어 있다.

메시지 유형 ID 바이트는 패킷에 오디오/비디오 데이터, 원격 개체 또는 명령이 포함되어 있는지 여부를 정의한다.에 대해 가능한 몇 가지 값은 다음과 같다.

• 0x01 = 패킷 크기 메시지 설정.
• 0x02 = 중단.
• 0x03 = 승인.
• 0x04 = 제어 메시지.
• 0x05 = 서버 대역폭
• 0x06 = 클라이언트 대역폭.
• 0x07 = 가상 제어.
• 0x08 = 오디오 패킷.
• 0x09 = 비디오 패킷.
• 0x0F = 데이터 확장.
• 0x10 = 컨테이너 확장.
• 0x11 = 명령 확장(AMF3 유형 명령)
• 0x12 = 데이터(Invoke(OnMetaData 정보는 이와 같이 전송됨)
• 0x13 = 컨테이너.
• 0x14 = 명령(AMF0 유형 명령).
• 0x15 = UDP
• 0x16 = 집계
• 0x17 = 현재

헤더를 따라 0x02는 크기가 0x000C이고 값이 0x63 0x72...0x6D("Stream 만들기" 명령).그 다음에 우리는 값 2.0의 트랜잭션 ID인 0x00(숫자)을 가지고 있다.마지막 바이트는 0x05(null)로 인수가 없음을 의미한다.

메시지 구조 호출(0x14, 0x11)

Ping 및 Set Client/Server Bandwidth와 같이 위에 표시된 메시지 유형 중 일부는 AMF 인코딩 형식을 사용하지 않는 낮은 수준의 RTMP 프로토콜 메시지로 간주된다.반면, AMF0(메시지 유형 0x14) 또는 AMF3(0x11)의 명령 메시지는 형식을 사용하며 다음과 같은 일반 형식을 가진다.

(현) <명령명> (숫자) <트랜잭션 아이디> (혼합) <논쟁> ex.Null, 문자열, 개체:{key1:value1, key2:value2 ...}

트랜잭션 ID는 회신이 가능한 명령에 사용된다.값은 위의 예와 같은 문자열 또는 하나 이상의 개체 중 하나일 수 있으며, 각 개체는 키가 항상 문자열로 인코딩되는 키/값 쌍 집합으로 구성되며, 값은 배열과 같은 복잡한 유형을 포함한 모든 AMF 데이터 유형일 수 있다.

제어 메시지 구조(0x04)

제어 메시지는 AMF 인코딩되지 않는다.이들은 전체 (유형 0) 헤더를 의미하는 0x02의 스트림 Id로 시작하고 메시지 유형이 0x04이다.헤더 뒤에 6바이트가 뒤따르며, 다음과 같이 해석된다.

• #0-1 - 제어 유형.
• #2-3 - 두 번째 매개변수(특정 제어 유형에 의미가 있음)
• #4-5 - 세 번째 매개 변수(동일)

메시지 본문의 처음 2바이트는 Ping Type을 정의하는데, Ping Type은 6개의 가능한 값을 가질 수 있다^[11].

• 유형 0 - 스트림 지우기:연결이 설정되고 추가 데이터가 없을 때 전송됨
• 유형 1 - 버퍼 지우기
• 유형 2 - 스트림 드라이
• 유형 3 - 클라이언트의 버퍼 시간.세 번째 파라미터는 밀리초 단위의 값을 가진다.
• 유형 4 - 스트림 재설정
• 유형 6 - 서버에서 클라이언트 ping.두 번째 파라미터는 현재 시간이다.
• 유형 7 - 클라이언트의 Pong 응답.두 번째 매개 변수는 클라이언트가 Ping을 수신하는 시간이다.
• 유형 8 - UDP 요청.
• 유형 9 - UDP 응답.
• 유형 10 - 대역폭 제한
• 유형 11 - 대역폭.
• 유형 12 - 스로틀 대역폭
• 유형 13 - 스트림이 작성됨
• 유형 14 - 스트림 삭제됨
• 유형 15 - 읽기 액세스 설정
• 유형 16 - 쓰기 액세스 설정
• 유형 17 - 스트림 메타 요청
• 유형 18 - 스트림 메타 응답
• 유형 19 - 세그먼트 경계 가져오기
• 유형 20 - 세그먼트 경계 설정
• 유형 21 - 연결 해제 시
• 유형 22 - 중요 링크 설정
• 유형 23 - 연결 끊기
• 유형 24 - 해시 업데이트
• 유형 25 - 해시 시간 초과
• 유형 26 - 해시 요청.
• 유형 27 - 해시 응답.
• 유형 28 - 대역폭 확인
• 유형 29 - 오디오 샘플 액세스 설정
• 유형 30 - 비디오 샘플 액세스 설정
• 유형 31 - 스로틀 시작
• 유형 32 - 스로틀 끝
• 유형 33 - DRM 알림
• 유형 34 - RTMFP 동기화
• 유형 35 - 쿼리 IHELLo.
• 타입 36 - 포워드 IHELLO.
• 유형 37 - 리디렉션 IHello.
• 유형 38 - EOF 알림
• 유형 39 - 프록시 계속
• 유형 40 - 프록시 업스트림 제거
• 41타입 - RTMFP 세트 Keepalives.
• 유형 46 - 세그먼트를 찾을 수 없음

Pong은 Ping에 대한 회신을 위한 이름이며, 위에서 본 값과 같이 사용된다.

ServerBw/ClientBw 메시지 구조(0x05, 0x06)

이는 클라이언트 업스트림 및 서버 다운스트림 비트 전송률과 관련된 메시지와 관련이 있다.본체는 대역폭 값을 표시하는 4바이트로 구성되며, 1바이트의 확장이 가능하여 Limit Type을 설정할 수 있다.이것은 세 가지 가능한 값 중 하나를 가질 수 있다: 하드, 소프트 또는 다이내믹(소프트 또는 하드).

청크 크기 설정(0x01)

본문의 4바이트 단위로 받은 값.128바이트의 기본값이 존재하며, 변경사항이 필요할 때만 메시지가 전송된다.

프로토콜

RTMP 핸드셰이크 다이어그램

악수

TCP 연결을 설정한 후에는 RTMP 연결이 먼저 설정되어 양쪽에서 3개의 패킷(공식 문서에서는 청크라고도 함)의 교환을 통해 핸드셰이크를 수행한다.이것들은 공식 규격에서 각각 전송된 클라이언트의 경우 C0-2,서버 측의 경우 S0-2로 언급되며, 핸드셰이크가 완료된 후에만 교환이 가능한 RTMP혼동해서는 안 된다 패킷과.이러한 패킷은 자체 구조를 가지고 있으며 C1에는 "에포치" 타임스탬프를 설정하는 필드가 포함되어 있지만, 제3자 구현에서와 같이 0으로 설정할 수 있으므로 패킷을 단순화할 수 있다.클라이언트는 현재 프로토콜 버전을 나타내는 상수 값 0x03의 C0 패킷을 전송하여 연결을 초기화한다.그것은 1536바이트가 들어 있는 S0이 먼저 수신되기를 기다리지 않고 C1로 직행하며, 첫 번째 4개는 epoch 타임스탬프를 나타내고, 두 번째 4개는 모두 0이며, 나머지는 랜덤(그리고 제3자 구현에서 0으로 설정할 수 있음)이다.C2와 S2는 각각 S1과 C1의 메아리로, 두 번째 4바이트는 각각의 메시지가 수신된 시간(0 대신)인 것을 제외하고 말이다.C2와 S2를 받은 후에는 핸드셰이크가 완료된 것으로 간주된다.

연결하다

이 시점에서 클라이언트와 서버는 AMF로 인코딩된 메시지를 교환하여 연결을 협상할 수 있다.여기에는 연결에 필요한 변수와 관련된 키 값 쌍이 포함된다.클라이언트가 보낸 예제 메시지:

(호출하다) "연결" (거래 아이디) 1.0 (객체1) { 앱.: "sample", 플래시버: "MAC 10,2,153,2", swfUrl: 무효의,               tcurl: "rtmpt://190.0.1/190", 패드를 붙이다: 거짓의,               능력: 9947.75 , 오디오코덱스: 3191, 비디오코덱스: 252,               비디오 기능: 1 , 페이지울: 무효의, objectEncoding: 3.0 } 

Flash Media 서버 및 기타 구현에서는 "앱" 개념을 사용하여 스트리밍할 미디어 파일을 포함하는 서버 루트의 폴더로 구현된 오디오/비디오 및 기타 컨텐츠용 컨테이너를 개념적으로 정의한다.첫 번째 변수에는 Wowza Server가 테스트를 위해 제공한 이름인 "샘플"로 이 앱의 이름이 포함되어 있다.그flashVer문자열은 Action-script에서 반환된 문자열과 동일함getversion()기능을 하다그audioCodec그리고videoCodec복식으로 암호화되어 있고 그 의미는 원래의 스펙에서 찾을 수 있다.이도 마찬가지다.videoFunction변수. 이 경우 자체 설명 Support_VID_CLIENT_SEEK 상수가 된다.특별한 관심이 있는 것은objectEncoding나머지 통신이 확장 AMF3 형식을 사용할지 여부를 정의한다.버전 3은 현재 기본값이므로, AMF0이 요청될 경우 조치 스크립트 코드에 플래시 클라이언트를 명시적으로 알려야 한다.그런 다음 서버는 ServerBW, ClientBW 및 SetPacketSize 메시지 시퀀스로 응답하고, 마지막으로 호출에 이어 예제 메시지로 응답한다.

(호출하다) "_vmx" (거래 아이디) 1.0 (객체1) { fmsVer: "FMS/3,5,2004", 능력: 31.0, 모드: 1.0 } (오브젝트) { 수평을 이루다: "상태", 부호를 붙이다: "넷커넥션.연결하다성공",                    설명: "연결 성공",                    자료: (배열하다) { 버전: "3,5,5,2004" },                    clientId: 1728724019, objectEncoding: 3.0 } 

위의 값 중 일부는 일반 동작 스크립트 개체의 속성으로 직렬화되며, 이 속성은 NetConnection 이벤트 수신기로 전달된다.그clientId연결에 의해 시작될 세션을 위한 번호를 설정한다.개체 인코딩은 이전에 설정한 값과 일치해야 한다.

비디오 재생

비디오 스트림을 시작하려면 클라이언트가 "Stream 만들기" 호출에 이어 ping 메시지를 보내고 파일 이름을 인수로 하는 "재생" 호출이 이어진다.그러면 서버는 일련의 "onStatus" 명령으로 응답한 후 RTMP 메시지 내에 캡슐화된 비디오 데이터로 응답한다.

연결이 설정되면 FLV 태그의 내용을 오디오와 비디오를 위해 각각 타입 8과 9의 RTMP 메시지로 캡슐화하여 미디어를 보낸다.

HTTP 터널링(RTMPT)

이것은 프로토콜의 HTTP 터널링 버전을 가리킨다.포트 80을 통해 통신하며, HTTP POST 요청 및 응답 내 AMF 데이터를 전달한다.연결 순서는 다음과 같다.

POST /fcs/ident2 HTTP/1.1 컨텐츠 유형: 애플리케이션/x-fcs\r\n HTTP/1.0 404 찾을 수 없음

POST /open/1 HTTP/1.1 컨텐츠 유형: 애플리케이션/x-fcs\r\n HTTP/1.1 200 OK 컨텐츠 유형: 애플리케이션/x-fcs\r\n 1728724019

첫 번째 요청은/fcs/ident2경로, 올바른 답장은 404 Not Found 오류 입니다.그런 다음 클라이언트는 서버가 해당 통신의 세션 식별자로 사용될 임의의 번호를 추가하여 200 ok로 회신해야 하는 /open/1 요청을 전송한다.이 예에서 1728724019는 대응 본체에 반환된다.

포스트 /190/1728724019/0 HTTP/1.1 HTTP/1.1 200 OK    0x01 

앞으로 더./idle/<session id>/<sequence #>세션 ID가 생성되어 서버에서 반환되는 폴링 요청이며, 시퀀스는 요청마다 1씩 증가하는 숫자일 뿐이다.적절한 응답은 200 OK이며, 체내에서 정수가 반환되어 간격 시간을 나타낸다.AMF 데이터가 전송됨/send/<session id>/<sequence #>

소프트웨어 구현

RTMP는 다음 세 가지 단계에서 구현된다.

• 라이브 비디오 인코더
• 라이브 및 주문형 미디어 스트리밍 서버
• 라이브 및 온디맨드 클라이언트

rtmpdump

오픈소스 RTMP 클라이언트 명령줄 툴 rtmpdump는 Adobe가 암호화에 사용하는 RTMPE 프로토콜을 포함하여 전체 RTMP 스트림을 재생하거나 디스크에 저장하도록 설계되었다.RTMPdump는 Linux, Android, Solaris, Mac OS X 및 대부분의 다른 Unix에서 파생된 운영 체제와 Microsoft Windows에서 실행된다.원래 Windows 98을 포함한 32비트 Windows의 모든 버전을 지원하는 버전 2.2부터 소프트웨어는 Windows XP 이상에서만 실행된다(이전 버전은 완전한 기능을 유지함에도 불구하고

rtmpdump 소프트웨어 제품군의 패키지는 주요 오픈 소스 리포지토리(리눅스 배포)에서 이용할 수 있다.여기에는 프런트 엔드 앱 "rtmpdump", "rtmpsrv", "rtmpsuck" 등이 포함된다.

RTMPdump의 개발은 2009년 10월, 미국 이외의 지역에서 MPlayer 사이트에서 다시 시작되었다.^[12]현재 버전은 기능성이 크게 향상되었으며, C 프로그래밍 언어의 장점을 활용하기 위해 다시 작성되었다.특히, 주요 기능성은 다른 어플리케이션에서도 쉽게 사용할 수 있는 라이브러리(librtmp)에 내장되었다.또한 RTMPdump 개발자들은 MPlayer, FFmpeg, XBMC, cURL, VLC 및 기타 여러 오픈 소스 소프트웨어 프로젝트에 대한 지원을 문서화했다.Librtmp를 사용하면 추가 개발 노력 없이 모든 변종에서 RTMP를 완벽하게 지원할 수 있다.

FLVstreamer

FLVstreamer는 코드가 없는 RTMPdump의 포크로, Adobe는 미국의 DMCA를 위반한다고 주장한다.이는 2008년 어도비가 RTMPdump를 억제하려는 시도에 대한 대응으로 개발됐다.FLVstreamer는 스트림에서 암호화(RTMPE)가 활성화되지 않은 경우 모든 RTMP 서버에서 디스크로 오디오 또는 비디오 컨텐츠 스트림을 저장하는 RTMP 클라이언트다.

참고 항목

• RTMPS 및 RTMPE에 대한 보호된 스트리밍 정보
• 주문형 비디오(VoD)
• MSE(미디어 소스 확장)
• 웹소켓

참조

외부 링크

• Adobe Developer 페이지 - RTMP - 공식 사양