콘솔에서 도메인 이름을 제출하고 관리하려면 먼저 등록(관련 정부 기관에)되어 있어야 합니다. 도메인 이름의 글자 수 제한은 29자이며 대문자는 현재 지원되지 않습니다. 29자를 초과하지 않는 소문자 도메인 이름 주소를 입력하십시오. 자세한 내용은 도메인 이름 관리를 참조하십시오.
재생 도메인 이름과 푸시 도메인 이름은 서로 다른 두 개의 도메인 이름이어야 합니다. 그러나 하위 도메인을 사용하여 구분할 수 있습니다.
예: 스트림 푸시에는 123.abc.com을 사용하고 재생에는 456.abc.com을 사용합니다.
RTMP는 전체 라이브 스트리밍 환경에서 특별히 지배적이지는 않지만 "스트리머"에서 "서버"로 스트림을 푸시하는 주요 프로토콜입니다. 현재 중국의 대부분의 비디오 클라우드 서비스는 주로 RTMP를 주요 푸시 프로토콜로 사용합니다(라이브 스트리밍 SDK의 첫 번째 기능 모듈은 스트림 푸시용이므로 종종 RTMP SDK라고 함).
현재 일반적인 라이브 스트리밍 프로토콜에는 RTMP, FLV, HLS 및 WebRTC가 있습니다.
- RTMP: 푸시 및 스트리밍 모두에 적합한 다목적 프로토콜입니다. 대용량 비디오 및 오디오 프레임을 인터넷 전송을 위해 더 작은 패킷으로 분할하고 암호화를 지원하여 우수한 개인 정보 보호를 제공합니다. 그러나 패킷 분할/조립 프로세스가 복잡하여 높은 동시성에서 안정성 문제가 발생할 수 있습니다.
- FLV: Adobe에서 홍보한 이 프로토콜은 형식이 간단하여 대용량 비디오/오디오 프레임에 헤더 마커만 추가합니다. 따라서 저지연 및 고동시성에 적합합니다. 주요 단점은 모바일 브라우저 지원이 제한적이라는 것이지만 모바일 앱에는 매우 적합합니다.
- HLS: Apple의 솔루션으로 비디오를 m3u8 인덱스 파일로 관리되는 5~10초 청크로 분할합니다. 클라이언트가 전체 청크를 다운로드하므로 재생은 부드럽지만 상당한 지연(일반적으로 10~30초)이 발생합니다. FLV와 비교할 때 HLS는 iPhone 및 대부분의 Android 모바일 브라우저에서 탁월한 지원을 제공하므로 링크 공유(예: QQ/WeChat)에 일반적입니다.
- WebRTC: 웹 실시간 통신(Web Real-Time Communication)을 나타냅니다. 웹 브라우저 내에서 실시간 오디오/비디오 통신을 지원하는 API입니다. 2011년에 오픈 소스화되었으며 W3C 표준입니다. "빠른 라이브 스트리밍"은 WebRTC를 사용하여 기존 프로토콜에 비해 초저지연 경험(밀리초 수준)을 제공하며 온라인 교육, 스포츠 스트리밍 및 라이브 퀴즈와 같은 시나리오에 이상적입니다.
라이브 스트리밍 서비스를 활성화한 신규 사용자는 1년 동안 유효한 국내 표준 라이브 스트리밍용 무료 20GB 트래픽 패키지를 받습니다. 기본 청구 방법은 종량제(일일 정산)입니다. 표준 라이브 스트리밍 재생 테스트에 사용된 트래픽은 이 패키지에서 차감되며 패키지를 초과하는 사용량은 매일 청구됩니다. 부가 가치 기능(예: 워터마크, 트랜스코딩, 녹화, 스크린샷, 콘텐츠 조정)은 기본적으로 비활성화되어 있으며 필요에 따라 활성화할 수 있으며 별도로 청구됩니다. 자세한 청구 항목은 표준 라이브 스트리밍 청구를 참조하십시오.
콘솔에서 도메인 이름을 제출하고 관리하려면 먼저 등록(관련 정부 기관에)되어 있어야 합니다. 도메인 이름의 글자 수 제한은 29자이며 대문자는 현재 지원되지 않습니다. 29자를 초과하지 않는 소문자 도메인 이름 주소를 입력하십시오. 자세한 내용은 도메인 이름 관리를 참조하십시오.
재생 도메인 이름과 푸시 도메인 이름은 서로 다른 두 개의 도메인 이름이어야 합니다. 그러나 하위 도메인을 사용하여 구분할 수 있습니다.
예: 스트림 푸시에는 123.abc.com을 사용하고 재생에는 456.abc.com을 사용합니다.
RTMP는 전체 라이브 스트리밍 환경에서 특별히 지배적이지는 않지만 "스트리머"에서 "서버"로 스트림을 푸시하는 주요 프로토콜입니다. 현재 중국의 대부분의 비디오 클라우드 서비스는 주로 RTMP를 주요 푸시 프로토콜로 사용합니다(라이브 스트리밍 SDK의 첫 번째 기능 모듈은 스트림 푸시용이므로 종종 RTMP SDK라고 함).
현재 일반적인 라이브 스트리밍 프로토콜에는 RTMP, FLV, HLS 및 WebRTC가 있습니다.
- RTMP: 푸시 및 스트리밍 모두에 적합한 다목적 프로토콜입니다. 대용량 비디오 및 오디오 프레임을 인터넷 전송을 위해 더 작은 패킷으로 분할하고 암호화를 지원하여 우수한 개인 정보 보호를 제공합니다. 그러나 패킷 분할/조립 프로세스가 복잡하여 높은 동시성에서 안정성 문제가 발생할 수 있습니다.
- FLV: Adobe에서 홍보한 이 프로토콜은 형식이 간단하여 대용량 비디오/오디오 프레임에 헤더 마커만 추가합니다. 따라서 저지연 및 고동시성에 적합합니다. 주요 단점은 모바일 브라우저 지원이 제한적이라는 것이지만 모바일 앱에는 매우 적합합니다.
- HLS: Apple의 솔루션으로 비디오를 m3u8 인덱스 파일로 관리되는 5~10초 청크로 분할합니다. 클라이언트가 전체 청크를 다운로드하므로 재생은 부드럽지만 상당한 지연(일반적으로 10~30초)이 발생합니다. FLV와 비교할 때 HLS는 iPhone 및 대부분의 Android 모바일 브라우저에서 탁월한 지원을 제공하므로 링크 공유(예: QQ/WeChat)에 일반적입니다.
- WebRTC: 웹 실시간 통신(Web Real-Time Communication)을 나타냅니다. 웹 브라우저 내에서 실시간 오디오/비디오 통신을 지원하는 API입니다. 2011년에 오픈 소스화되었으며 W3C 표준입니다. "빠른 라이브 스트리밍"은 WebRTC를 사용하여 기존 프로토콜에 비해 초저지연 경험(밀리초 수준)을 제공하며 온라인 교육, 스포츠 스트리밍 및 라이브 퀴즈와 같은 시나리오에 이상적입니다.
라이브 스트리밍 서비스를 활성화한 신규 사용자는 1년 동안 유효한 국내 표준 라이브 스트리밍용 무료 20GB 트래픽 패키지를 받습니다. 기본 청구 방법은 종량제(일일 정산)입니다. 표준 라이브 스트리밍 재생 테스트에 사용된 트래픽은 이 패키지에서 차감되며 패키지를 초과하는 사용량은 매일 청구됩니다. 부가 가치 기능(예: 워터마크, 트랜스코딩, 녹화, 스크린샷, 콘텐츠 조정)은 기본적으로 비활성화되어 있으며 필요에 따라 활성화할 수 있으며 별도로 청구됩니다. 자세한 청구 항목은 표준 라이브 스트리밍 청구를 참조하십시오.