리얼 타임 메시징 프로토콜
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
리얼 타임 메시징 프로토콜(RTMP)은 TCP 기반의 실시간 통신 프로토콜로, 데이터 스트림을 조각으로 나누어 전송하며 인터리빙 및 다중화를 통해 효율적인 데이터 전송을 가능하게 한다. HTTP 터널링을 통해 방화벽을 우회할 수 있으며, TLS/SSL 또는 RTMPE를 사용하여 암호화할 수 있다. RTMP는 다양한 메시지 유형을 정의하며, 액션 메시지 포맷(AMF)을 사용하여 RPC를 수행한다. RTMP 클라이언트로는 어도비 플래시 플레이어, VLC, rtmpdump 등이 있으며, 서버 소프트웨어로는 어도비 플래시 미디어 서버, Wowza 미디어 서버, Red5 등이 있다. 어도비는 RTMP 관련 특허를 보유하고 있으며, 과거 Wowza Media Systems와 특허 침해 소송을 벌인 바 있다. 향상된 RTMP(Enhanced RTMP)는 VP9, H.265, AV1 코덱을 지원하며, RTMFP는 UDP 기반의 스트리밍 프로토콜이다.
더 읽어볼만한 페이지
- 인터넷 프로토콜 - IPTV
IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다. - 인터넷 프로토콜 - DNSSEC
DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
| 리얼 타임 메시징 프로토콜 |
|---|
2. 동작
RTMP는 순수 TCP 기반으로 지속적인 연결을 유지하여 실시간 통신을 가능하게 한다. 비디오 및 오디오 스트림을 부드럽게 전달하기 위해 데이터를 여러 조각(fragments)으로 나누며, 조각 크기는 클라이언트와 서버 간에 유동적으로 결정된다. 비디오 및 기타 데이터의 기본 조각 크기는 128바이트, 오디오는 64바이트이다.
여러 스트림이 있을 때 각 스트림의 조각들은 인터리빙(interleaving) 및 다중화되어 하나의 연결 내에서 전송된다. 데이터 덩어리(chunk) 크기가 클 경우, RTMP는 조각 당 1바이트의 헤더만 전송하여 부하를 줄인다. 그러나 실제로는 조각들이 보통 인터리빙되지 않고, 패킷 수준에서 인터리빙과 다중화가 수행된다.
RTMP는 패킷 송수신을 위한 여러 채널을 정의하며, 각 채널은 다른 채널과 독립적으로 동작한다. 예를 들어 원격 프로시저 호출(RPC) 요청 및 응답, 비디오 스트림 데이터, 오디오 스트림 데이터, 아웃-오브-밴드(out-of-band) 제어 메시지(조각 크기 결정 등)를 위한 채널이 있다. 일반적으로 하나의 RTMP 세션 내에 여러 채널이 동시에 활성화될 수 있다.
RTMP 데이터가 패킷화될 때 패킷 헤더가 생성된다. 패킷 헤더는 채널 ID, 타임스탬프(필요한 경우), 패킷 페이로드 크기 등을 포함하며, 이후 실제 패킷 페이로드가 클라이언트와 서버 간 약속된 조각 크기만큼씩 조각으로 쪼개진다. 패킷 헤더 자체는 조각나지 않는다.
상위 레벨에서 RTMP는 MP3, AAC, FLV1 등의 멀티미디어 스트림을 캡슐화하고, 액션 메시지 포맷을 사용하여 RPC를 수행한다.[24]
2. 1. HTTP 터널링
RTMP는 HTTP 터널링을 통해 방화벽을 우회할 수 있다. RTMP Tunneled (RTMPT)와 RTMP Secure (RTMPS)는 각각 HTTP와 HTTPS를 통해 RTMP 데이터를 교환한다. 클라이언트(미디어 플레이어)에서 나오는 메시지는 RTMPT의 경우 서버의 80번 포트(HTTP 기본 포트), RTMPS의 경우 443번 포트(HTTPS 기본 포트)로 들어간다.RTMPT와 RTMPS는 HTTP 헤더가 추가되므로 터널링되지 않은 일반 RTMP보다 패킷 크기가 더 크다. RTMPT는 클라이언트가 방화벽 뒤에 있어 HTTP나 HTTPS 외의 트래픽이 차단되는 경우와 같이 비터널링 RTMP를 사용할 수 없을 때 RTMP 사용을 가능하게 한다.
RTMPT에서 연결을 여는 예시는 다음과 같다.
POST /open/1 HTTP/1.1
2. 2. 암호화
RTMP 세션은 다음 두 가지 방법으로 암호화될 수 있다.- 업계 표준 TLS/SSL 메커니즘을 사용한다. 기본적인 RTMP 세션은 일반적인 TLS/SSL 세션 내에 래핑된다.
- RTMPE를 사용하여 RTMP 세션을 더 가벼운 암호화 계층으로 래핑한다.
3. 패킷 구조
RTMP 프로토콜에서 패킷은 클라이언트와 서버 간에 설정된 TCP 연결을 통해 전송된다. 이 패킷은 헤더와 본문으로 구성되며, 연결 및 제어 명령의 경우 액션 메시지 포맷(AMF)을 사용하여 인코딩된다.[24]
패킷 헤더는 ''기본 헤더''와 ''청크 메시지 헤더''로 나뉜다.
- 기본 헤더: 패킷의 유일한 상수 부분이며, 보통 1바이트로 구성된다. 이 바이트의 상위 2비트는 청크 유형을, 나머지 6비트는 청크 스트림 ID를 나타낸다. 기본 헤더는 스트림 ID에 따라 1~3바이트까지 확장될 수 있다.
- 6비트가 0이면 2바이트 (스트림 ID 64~319)
- 6비트가 1이면 3바이트 (스트림 ID 64~65599)
- 6비트가 2이면 1바이트 (로우 레벨 프로토콜 제어 메시지 및 명령)
- 청크 메시지 헤더: 메시지 크기(바이트 단위), 타임스탬프 델타, 메시지 유형과 같은 메타데이터 정보를 포함한다. 메시지 유형은 패킷이 오디오, 비디오, 명령, 또는 RTMP 핑과 같은 "로우 레벨" RTMP 패킷인지 정의하는 단일 바이트이다.
3. 1. 메시지 유형
RTMP는 다양한 종류의 메시지를 주고받을 수 있도록 여러 채널을 정의한다. 각 채널은 독립적으로 동작하며, 다음과 같은 예시가 있다.[24]- RPC 요청 및 응답 처리 채널
- 비디오 스트림 데이터 채널
- 오디오 스트림 데이터 채널
- 대역 외 제어 메시지(조각 크기 협상 등) 채널
일반적인 RTMP 세션에서는 여러 채널이 동시에 활성화될 수 있다. RTMP 데이터가 패킷으로 만들어질 때, 패킷 헤더가 생성된다. 패킷 헤더는 다음과 같은 정보를 담고 있다.[24]
- 채널 ID
- 타임스탬프 (필요한 경우)
- 패킷 페이로드 크기
패킷 헤더 다음에는 실제 데이터인 패킷 페이로드가 온다. 패킷 페이로드는 클라이언트와 서버 간에 약속된 조각 크기만큼 잘게 쪼개진다. 패킷 헤더 자체는 쪼개지지 않으며, 첫 번째 조각 크기에 헤더 크기가 포함되지 않는다.[24]
패킷은 TCP 연결을 통해 전송되며, 헤더와 본문으로 구성된다. 연결 및 제어 명령은 액션 메시지 포맷(AMF)을 사용하여 인코딩된다. 헤더는 ''기본 헤더''와 ''청크 메시지 헤더''로 나뉜다. 기본 헤더는 일반적으로 단일 바이트로 구성되며, 청크 유형과 스트림 ID를 나타낸다. 기본 헤더의 최하위 6비트가 0이면 2바이트, 1이면 3바이트, 2이면 1바이트로 구성된다. 청크 메시지 헤더에는 메시지 크기, 타임스탬프 델타, 메시지 유형 등의 정보가 포함된다.[24]
다음은 플래시 클라이언트 코드 실행 시 생성되는 청크의 예시이다.
| 16진수 코드 | ASCII |
|---|---|
03 00 0B 68 00 00 19 14 00 00 00 00 02 00 0C 63 72 65 61 74 65 53 74 72 65 61 6D 00 40 00 00 00 00 00 00 00 05 | ␃ ␀ @ I ␀ ␀ ␙ ␔ ␀ ␀ ␀ ␀ ␂ ␀ ␌ c r e a t e S t r e a m ␀ @ ␀ ␀ ␀ ␀ ␀ ␀ ␀ ␅ |
패킷은 기본 헤더(0x03)로 시작하며, 청크 헤더 유형(0)과 청크 스트림 ID(3)를 나타낸다. 헤더 유형은 다음과 같이 4가지가 있다.
- b00 = 12바이트 헤더 (전체 헤더)
- b01 = 8바이트 (메시지 ID 제외)
- b10 = 4바이트 (기본 헤더 및 타임스탬프)
- b11 = 1바이트 (기본 헤더만 포함)
RTMP 헤더의 다음 바이트는 다음과 같이 해석된다.
- 바이트 #1 (0x03): 청크 헤더 유형
- 바이트 #2-4 (0x000b68): 타임스탬프 델타
- 바이트 #5-7 (0x000019): 패킷 길이 (25바이트)
- 바이트 #8 (0x14): 메시지 유형 ID (AMF0 인코딩된 ''명령'' 메시지)
- 바이트 #9-12 (0x00000000): 메시지 스트림 ID (리틀 엔디안)
메시지 유형 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 | 현재 |
제어 메시지는 AMF로 인코딩되지 않으며, 스트림 ID 0x02와 메시지 유형 0x04로 시작한다. 메시지 본문의 처음 두 바이트는 핑 유형을 나타내며, 다음과 같은 값들이 가능하다.
| 핑 유형 | 설명 |
|---|---|
| 유형 0 | 스트림 지우기 |
| 유형 1 | 버퍼 지우기 |
| 유형 2 | 스트림 건조 |
| 유형 3 | 클라이언트의 버퍼 시간 |
| 유형 4 | 스트림 재설정 |
| 유형 6 | 서버에서 클라이언트로 핑 |
| 유형 7 | 클라이언트에서 퐁 응답 |
| 유형 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 연결 유지 설정 |
| 유형 46 | 세그먼트 찾을 수 없음 |
4. 프로토콜
RTMP 프로토콜은 순수 TCP 기반으로 지속적인 접속을 유지하며 실시간 통신을 지원한다. 정보를 효율적으로 전송하기 위해 비디오 및 오디오 스트림을 여러 조각(fragments)으로 나누는데, 이 크기는 클라이언트와 서버 간에 유동적으로 결정되거나 비활성화될 수 있다. 비디오 및 기타 데이터의 기본 조각 크기는 128바이트, 오디오는 64바이트이다.
여러 스트림이 있을 때 각 스트림의 조각들은 인터리빙 및 다중화되어 하나의 접속에서 전송된다. 데이터 덩어리(chunk) 크기가 크면 조각 당 1바이트의 헤더만 전송하여 부하를 줄인다. 그러나 실제로는 패킷 수준에서 인터리빙 및 다중화가 수행되며, 활성화된 여러 채널의 RTMP 패킷들은 각 채널의 대역폭, 지연 시간, 서비스 품질 요구에 맞게 인터리빙된다.
RTMP는 패킷 송수신을 위한 여러 채널을 정의하며, 각 채널은 독립적으로 동작한다. 예를 들어 RPC 요청/응답, 비디오/오디오 스트림, 대역 외 제어 메시지(조각 크기 결정 등) 채널 등이 있다. RTMP 데이터 패킷 헤더는 채널 ID, 타임스탬프(필요시), 패킷 페이로드 크기 등을 포함하며, 헤더 다음에는 실제 페이로드가 온다. 패킷 헤더 자체는 조각나지 않는다.
상위 레벨에서 RTMP는 MP3, AAC, 플래시 비디오 멀티미디어 스트림을 캡슐화하고, 액션 메시지 포맷을 이용해 RPC를 수행한다.[24]
4. 1. 핸드셰이크
TCP 연결이 설정된 후, RTMP 연결이 설정된다. 이때 클라이언트와 서버는 각각 세 개의 패킷(클라이언트: C0-C2, 서버: S0-S2)을 교환하여 핸드셰이크를 수행한다.[1] 이 패킷들은 자체적인 구조를 가지고 있다.[1]
클라이언트는 현재 프로토콜 버전을 나타내는 0x03 상수를 가진 C0 패킷을 전송하여 연결을 초기화한다.[1] 그런 다음 S0을 수신하기를 기다리지 않고 바로 C1을 전송한다.[1] C1은 1536바이트를 포함하며 처음 4바이트는 에포크 타임스탬프, 다음 4바이트는 모두 0이며 나머지는 임의의 값이다.[1] C2와 S2는 각각 S1과 C1의 에코이며, 두 번째 4바이트가 해당 메시지를 수신한 시간이라는 점만 다르다.[1] C2와 S2를 수신하면 핸드셰이크가 완료된 것으로 간주된다.[1]
4. 2. 연결
이 시점에서 클라이언트와 서버는 AMF(Action Message Format)로 인코딩된 메시지를 교환하여 연결을 협상할 수 있다. 여기에는 연결을 설정하는 데 필요한 변수와 관련된 키-값 쌍이 포함된다. 클라이언트에서 보낸 메시지의 예는 다음과 같다.```actionscript3
(호출) "connect"
(트랜잭션 ID) 1.0
(객체1) { app: "sample", flashVer: "MAC 10,2,153,2", swfUrl: null,
tcUrl: "rtmpt://127.0.0.1/sample ", fpad: false,
capabilities: 9947.75 , audioCodecs: 3191, videoCodecs: 252,
videoFunction: 1 , pageUrl: null, objectEncoding: 3.0 }
```
Flash Media Server 및 기타 구현에서는 "app"의 개념을 사용하여 오디오/비디오 및 기타 콘텐츠에 대한 컨테이너를 개념적으로 정의한다. 이 컨테이너는 서버 루트의 폴더로 구현되며, 스트리밍할 미디어 파일이 포함되어 있다. 첫 번째 변수는 이 app의 이름을 "sample"로 포함하는데, 이 이름은 Wowza Server에서 테스트용으로 제공한 이름이다. `flashVer` 문자열은 ActionScript `getversion()` 함수에서 반환하는 것과 같다. `audioCodec` 및 `videoCodec`은 배정밀도 부동 소수점으로 인코딩되며, 그 의미는 원본 사양에서 찾을 수 있다. `videoFunction` 변수도 마찬가지이며, 이 경우에는 자체 설명적인 SUPPORT_VID_CLIENT_SEEK 상수이다. 특히 관심 있는 부분은 `objectEncoding`이며, 나머지 통신에서 확장된 AMF3 형식을 사용할지 여부를 정의한다. 버전 3이 현재 기본값이므로, 요청 시 Flash 클라이언트는 ActionScript 코드에서 AMF0을 사용하도록 명시적으로 지시해야 한다. 그러면 서버는 ServerBW, ClientBW 및 SetPacketSize 메시지 시퀀스로 응답한 다음, Invoke 메시지로 응답한다(예시 메시지 포함).
```actionscript3
(호출) "_result"
(트랜잭션 ID) 1.0
(객체1) { fmsVer: "FMS/3,5,5,2004", capabilities: 31.0, mode: 1.0 }
(객체2) { level: "status", code: "NetConnection.Connect.Success",
description: "Connection succeeded",
data: (array) { version: "3,5,5,2004" },
clientId: 1728724019, objectEncoding: 3.0 }
```
위의 일부 값은 일반 ActionScript 객체의 속성으로 직렬화된 다음, NetConnection 이벤트 리스너에 전달된다. `clientId`는 연결로 시작되는 세션의 번호를 설정한다. 객체 인코딩은 이전에 설정한 값과 일치해야 한다.
4. 3. 비디오 재생
클라이언트는 "createStream" 명령을 전송하고, 이어서 핑 메시지를 전송한 다음, 파일 이름을 인수로 하는 "play" 명령을 전송하여 비디오 스트림을 시작한다. 그러면 서버는 일련의 "onStatus" 명령으로 응답하고, 이어서 RTMP 메시지 안에 캡슐화된 비디오 데이터를 전송한다.[22]연결이 설정된 후, 미디어는 FLV 태그의 내용을 각각 오디오와 비디오에 대해 유형 8 및 9의 RTMP 메시지로 캡슐화하여 전송한다.[22]
5. RTMP 클라이언트 소프트웨어
어도비 플래시 플레이어는 가장 널리 사용되는 RTMP 클라이언트이다. RTMP 서버에서 음성 및 동영상 재생이 가능하다.[12]
리그 오브 레전드 클라이언트도 RTMP로 데이터를 주고받는다.
비디오랜(VLC)은 RTMP를 지원하는 크로스 플랫폼 미디어 플레이어이다.
XBMC는 RTMP를 부분적으로 지원하는 오픈 소스 미디어 플레이어이며, 원시적인 RTMP 스트림을 지원한다. RTMPE는 지원하지 않는다.
rtmpdump는 오픈 소스 RTMP 클라이언트 명령줄 도구로, RTMPE 프로토콜을 포함하여 전체 RTMP 스트림을 재생하거나 디스크에 저장하도록 설계되었다.
FLVstreamer는 RTMPdump의 포크로, 스트림에 암호화(RTMPE)가 활성화되지 않은 경우, RTMP 서버에서 오디오 또는 비디오 콘텐츠 스트림을 디스크에 저장하는 RTMP 클라이언트이다.
6. RTMP 서버 소프트웨어
어도비 플래시 미디어 서버, Wowza 미디어 서버, WebORB 통합 서버(무료. .NET 및 Java, ColdFusion 버전)는 현재까지 완벽하게 구현된 RTMP 서버이다.
자바로 만들어졌고, 2007년에 주요 부분의 기능이 구현된 리버스 엔지니어링된 오픈 소스 프로젝트인 [http://osflash.org/red5 Red5]도 있다. 이 프로젝트는 아직 베타 단계이다. [http://code.google.com/search/#q=RTMP%20Server Google Code]에는 기본 기능만 하는 서버가 올라와 있다.
NGINX 기반의 RTMP 미디어 스트리밍 서버 오픈 소스 프로젝트인 [https://github.com/arut/nginx-rtmp-module NGINX-RTMP]가 있다.
RTMP를 구현하는 서버 목록은 다음과 같다.
| 서버 이름 | 설명 |
|---|---|
| 어도비 미디어 서버 | |
| [http://www.adobe.com/jp/products/livecycle/dataservices/ Adobe LiveCycle Data Services] | |
| 아마존 S3(Amazon S3) & 아마존 클라우드프론트(Amazon Cloudfront) | RTMP를 처리할 수 있다. |
| haXeVideo | 프로그래밍 언어 haXe로 작성된 멀티 스레드 FLV 스트리밍 서버 |
| Helix Universal Server | |
| Onlinelib VCS 비디오 커뮤니케이션 서버 | iPhone 지원 포함 |
| [http://red5.org/ Red5 Media Server] | 자바로 작성된 오픈 소스 서버 |
| [http://erlyvideo.org/ Erlyvideo] | |
| [http://www.umediaserver.net/ Unreal Media Server] | |
| Wowza Media Server | |
| WebORB 통합 서버 | |
| OneTeam 미디어 서버 | |
| [http://rtmpd.com/ crtmpserver] | |
| FreeSWITCH | RTMP 미디어 스트리밍 |
| [http://www.netris.ru/en/products/2009-02-24-12-38-43/ipsoft-istream.html Netris iStream 비디오 서버] | |
| FFmpeg | |
| [http://flazr.com/ Flazr] | 자바 구현 |
7. 특허 및 소송
어도비는 스트리밍 데이터 가로채기와 콘텐츠 보호 기술 조치 회피를 금지하는 두 가지 제한 사항을 제외하고, RTMP 구현에 대해 비독점적이고 로열티가 없는 특허 라이선스를 부여한다.[5] 슈테판 리히터는 어도비가 RTMP에 어떤 특허가 적용되는지 모호하게 언급했지만, 이 그 중 하나로 보인다고 언급했다.[6]
2011년, 어도비는 Wowza Media Systems를 RTMP 특허 침해 등으로 고소했다.[7][8][9] 2015년, 양측은 소송이 합의되고 기각되었다고 발표했다.[10]
8. 향상된 RTMP (Enhanced RTMP)
어도비, 구글, 트위치 등은 향상된 RTMP 사양을 발표했으며,[13] 이는 플래시 비디오 컨테이너 FLV에서 VP9, H.265, AV1 코덱 지원을 추가한다.
다음은 향상된 RTMP를 지원하는 소프트웨어 및 서비스 목록이다.
9. RTMFP
Real Time Media Flow Protocol (RTMFP)는 UDP 위에서 동작하는 스트리밍 프로토콜이다. 음성 채팅, 화상 채팅 등에 사용된다.[1]
참조
[1]
웹사이트
RTMPE
http://help.adobe.co[...]
Adobe
2013-12-29
[2]
간행물
Using RPC services in Flex Data Services 2
https://www.adobe.co[...]
2007-04-16
[3]
간행물
Adobe’s Real Time Messaging Protocol
http://wwwimages.ado[...]
Adobe
2012-12-21
[4]
웹사이트
Real-Time Messaging Protocol (RTMP) specification
https://www.adobe.co[...]
2014-05-08
[5]
문서
RTMP Specification License
http://wwwimages.ado[...]
Published April 2009
[6]
웹사이트
TheRealTimeWeb.com: Adobe Patents RTMP
http://www.therealti[...]
[7]
웹사이트
Wowza Denies Adobe's Allegations of Patent Infringement
http://www.streaming[...]
2011-05-27
[8]
웹사이트
Wowza Fires Back at Adobe in Flash Patent Suit
http://gigaom.com/20[...]
2011-05-31
[9]
웹사이트
ADOBE SYSTEMS INCORPORATE - No. C 11-2243 CW. - 20120907565 - Leagle.com
http://www.leagle.co[...]
[10]
문서
Wowza Media Systems and Adobe Systems Settle Patent Cases
http://www.wowza.com[...]
[11]
문서
Ping
http://trac.red5.org[...]
The Red5 Project (2009)
2011-12-25
[12]
웹사이트
Updates:2009-11-01
http://www.mplayerhq[...]
2009-11-01
[13]
웹사이트
Enhancing RTMP, FLV With Additional Video Codecs And HDR Support
https://veovera.gith[...]
2024-04-01
[14]
웹사이트
Support HEVC VP9 AV1 codec in enhanced flv format
https://git.ffmpeg.o[...]
2024-04-01
[15]
웹사이트
Enable AV1, HEVC via RTMP to YouTube
https://github.com/o[...]
2024-04-01
[16]
웹사이트
Introducing the Enhanced Broadcasting Beta
https://blog.twitch.[...]
2024-04-01
[17]
웹사이트
Unlock the Power of Enhanced RTMP with Ant Media Server
https://antmedia.io/[...]
2024-09-26
[18]
문서
Real-Time Messaging Protocol (RTMP) specification
http://www.adobe.com[...]
Adobe Developer Connection
[19]
문서
Ripping Media Off of the Wire A Step-by-Step Guide
https://www.defcon.o[...]
DEF CON 2010年
[20]
문서
What is RTMPE
https://www.wowza.co[...]
Wowza Media Systems
[21]
웹사이트
RTMPの2021年以降の話 ~ Adobe Flash以外の動画配信での使われ方 {{!}} DevelopersIO
https://dev.classmet[...]
2022-07-24
[22]
간행물
Using RPC services in Flex Data Services 2
http://www.adobe.com[...]
2007-04-16
[23]
간행물
Adobe to Open Flash Platform Messaging Protocol
http://www.adobe.com[...]
2009-02-07
[24]
간행물
Using RPC services in Flex Data Services 2
http://www.adobe.com[...]
2007-04-16
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com