KR20210100176A

KR20210100176A - 미디어 스트림 송신 방법, 장치, 시스템, 및 디바이스

Info

Publication number: KR20210100176A
Application number: KR1020217021677A
Authority: KR
Inventors: 나이창 챠오; 쥔 저우; 밍리 장; 이 카이
Original assignee: 후아웨이 테크놀러지 컴퍼니 리미티드
Priority date: 2019-04-23
Filing date: 2020-04-23
Publication date: 2021-08-13
Also published as: KR102457526B1; JP2022517854A; US20220174104A1; EP3890265A1; WO2020216277A1; US11848973B2; US11330028B2; EP3890265A4; CN111835697A; US20210337001A1; JP7259056B2; EP3890265B1; CN111835697B

Abstract

미디어 스트림 송신 방법, 장치, 및 시스템, 그리고 디바이스가 개시된다. 이 방법은 라이브 방송룸에 진입하는 클라이언트에 대해 라이브 미디어 스트림을 제공한다. 방법은 다음을 포함한다: 프록시 서버는 동일한 프록시 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 수신하고; 프록시 서버는 미디어 서버에 의해 프록시 서버를 통해 제1 클라이언트로 송신되는 제1 라이브 미디어 스트림 및 미디어 서버에 의해 프록시 서버를 통해 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림을 수신하고; 그리고 제1 클라이언트의 역할은 마스터 사용자이고, 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정하는 경우, 프록시 서버는 제1 라이브 미디어 스트림만을 프록시 클라이언트로 송신하여, 프록시 클라이언트가 제1 라이브 미디어 스트림을 제1 클라이언트 및 제2 클라이언트로 송신하도록 한다. 이 방법에 따르면, 동일한 라이브 방송룸 내의 모든 클라이언트에 대해, 프록시 서버는 하나의 라이브 미디어 스트림만을 프록시 클라이언트 및 상기 제2 클라이언트로 송신하면 되고, 하나의 라이브 미디어 스트림을 전송하기 위한 광역 네트워크 대역폭이 소비된다. 이는 WAN 네트워크 링크 부하를 줄이고 리소스 오버헤드를 줄인다.

Description

미디어 스트림 송신 방법, 장치, 시스템, 및 디바이스

이 출원은 비디오 재생 분야에 관한 것으로서, 특히, 미디어 스트림 송신 방법, 장치, 및 시스템, 그리고 디바이스에 관한 것이다.

사용자는 라이브 방송 모드 또는 주문형 비디오 모드에서 비디오를 볼 수 있다. 주문형 비디오 모드에서는, 비디오를 볼 때, 사용자는 언제든지 비디오 콘텐츠를 빨리 감거나 되감을 수 있지만, 라이브 방송 모드에서는 비디오 콘텐츠를 빨리 감거나 되감을 수 없다. 라이브 방송은 일반적으로 데이터의 모든 프레임이 시간 순서 태그로 라벨링된 다음 스트리밍되는 프로세스로 이해될 수 있다. 구체적으로, 카메라 또는 마이크와 같은 수집 장치가 연속적으로 오디오 또는 비디오 정보를 수집한 후, 인코딩, 캡슐화(encapsulation), 및 스트림 푸싱(stream pushing)과 같은 정보 처리를 수행한 후 전달 네트워크를 통해 정보를 전송한다. 재생측은 연속적으로 데이터를 다운로드하고, 재생 시간 순서에 따라 데이터를 디코딩한다. 비디오 라이브 방송의 전체 절차는, 수집, 인코딩, 스트림 푸싱, 트랜스 코딩, 전달, 디코딩/렌더링 등의 일련의 프로세스를 포함한다.

인터넷 비디오 라이브 방송의 주류 공급 업체는 일반적으로 비디오 전송을 위해 유니캐스트 전송 프로토콜을 사용한다. 따라서, N 명의 사용자가 동영상을 시청하고 있다면, N 채널의 동영상 스트림이 있다. 또한, 기업용 라이브 영상 방송의 경우, 제시된 문서 공유 및 텍스트 코멘트 작성과 같은 기능이 영상 라이브 방송 중에 지원되어야 한다. 즉, 기업 라이브 방송의 웹 페이지에 영상 콘텐츠가 표시되는 동안 공유 문서와 텍스트 코멘트가 표시되어, 사용자 요구 사항을 충족하고 사용자 경험을 향상할 수 있다.

사용자 경험을 향상하고 백본 네트워크 대역폭을 절약하기 위해, 라이브 콘텐츠 전달 네트워크(Content Delivery Network, CDN)는 통상적으로 라이브 방송 플랫폼에 배치된다. 라이브 CDN은 분산된 콘텐츠 전달 플랫폼이며 다중-레이어 아키텍처를 지원한다. 라이브 CDN 플랫폼에서 캐싱용 서버는 상이한 레이어에 배포되어, 상이한 지역의 사용자에게 가까운 서비스를 제공할 수 있다.

라이브 CDN을 통해 오디오 및 비디오 스트림을 전달하는 과정에서, 실시간 메시지 전송 프로토콜이라고도 지칭되는 실시간 메시지 프로토콜(Real Time Messaging Protocol, RTMP)이 통상적으로 비디오 스트림 푸싱 및 스트림 배포 프로세스에 사용되고; 그리고 전달 프로세스에는, RTMP, HLS(HTTP Live Streaming) 프로토콜, 및 하이퍼텍스트 전송 프로토콜(Hyper Text Transfer Protocol, HTTP)-플래시 비디오(Flash Video, FLV)의 3가지 프로토콜이 통상적으로 사용되며, 여기서 하이퍼텍스트 전송 프로토콜-플래시 비디오는 줄여서 "HTTP-FLV"로 지칭된다. HLS 프로토콜은 Apple Inc.에서 개발한 HTTP-기반 스트리밍 미디어 전송 프로토콜이다. HLS 프로토콜은 주로 iPhone, iPad, iPod touch, 및 Mac OS X를 포함하는 iOS 장치에 적용되어, 오디오 및 비디오 라이브 서비스와 녹화된 콘텐츠(VOD) 서비스를 제공한다. HLS 프로토콜은 다음과 같은 장점이 있다: HLS 프로토콜에 따르면, 클라이언트는 한 번에 완전한 데이터 스트림을 요청하지 않으며; 대신, 스트리밍 미디어 데이터는 서버단에서 더 짧은 기간으로 더 작은 파일로 분할되고 더 작은 파일은 인덱스 파일에 기초하여 순서대로 액세스된다. 서버에서 수신한 작은 파일을 클라이언트가 연속적으로 그리고 순차적으로 재생함으로써 오디오 및 비디오가 재생될 수 있다.

도 1에 도시된 바와 같이, 라이브 CDN에서, 컨텐츠 소스(content source)는 RTMP를 사용하여 엔터프라이즈 데이터 센터(Enterprise Data Center, EDC)로 오디오 및 비디오 미디어 스트림을 송신하며, 여기서 EDC는 웹 서버(Web server) 및 복수의 미디어 서버(Media server)를 포함한다. EDC의 웹 서버는 클라이언트(PC)로부터의 라이브 프로그램 시청 요청에 응답하고, 사용자를 인증하고, 사용자의 위치에 기초하여 가장 가까운 미디어 서버를 할당하여 사용자에게 서비스를 제공한다. 선택된 미디어 서버는 미리 설정된 정책에 따라 오디오 및 비디오 미디어 스트림을 하위-레벨 지역 데이터 센터(Region Data Center, RDC)로 송신한다. 미디어 스트림(live content)을 수신한 후, RDC의 미디어 서버는, 미리 설정된 정책에 따라, 서버 룸(Server Room, SR)의 하위-레벨 미디어 서버로 미디어 스트림을 전달한다. 마지막으로, 서버 룸의 미디어 서버는 상위-레벨 미디어 서버에 의해 전달되는 미디어 스트림(live content)을 캐시하고, 사용자에게 직접 라이브 방송 서비스를 제공한다.

이 과정에서, 상위-레벨 RDC의 미디어 서버는 라이브 방송룸에서 미디어 스트림을 요청하는 각각의 클라이언트에게 라이브 미디어 스트림을 송신해야 하므로, 상위-레벨 RDC의 미디어 서버는 라이브 방송룸의 각 사용자에게 라이브 미디어 스트림을 전송해야 한다.. 라이브 방송룸에 진입하는 사용자가 많을 경우, 라이브 미디어 스트림 전송을 위해 다량의 WAN(Wide Area Network) 리소스가 요구되므로, 결과적으로 네트워크 오버헤드가 증가한다.

본 출원의 실시예는, 미디어 서버에 의해 동일한 라이브 방송룸 내의 클라이언트에 미디어 스트림을 송신하기 위한 리소스 오버헤드를 줄이는, 미디어 스트림 송신 방법, 장치, 및 시스템, 그리고 디바이스를 제공한다. 구체적으로, 본 출원의 실시예는 다음과 같은 기술적 해결 수단을 개시한다.

제1 측면에 따르면, 본 출원은 미디어 스트림 송신 방법을 제공하며, 여기서 방법은 라이브 방송룸에 진입하는 클라이언트에게 라이브 미디어 스트림을 제공한다. 방법은 다음을 포함한다: 프록시 서버는 상기 라이브 방송룸 입장을 요청하는데 사용되고 동일한 프록시 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 수신하며, 여기서, 상기 제1 라이브 방송룸 요청 메시지는 제1 클라이언트로부터 온 것이고, 상기 제2 라이브 방송룸 요청 메시지는 제2 클라이언트로부터 온 것이다. 상기 프록시 서버는 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 전송되는 제1 라이브 미디어 스트림 및 상기 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제2 클라이언트로 전송되는 제2 라이브 미디어 스트림을 수신한다. 상기 프록시 서버는 상기 제1 라이브 방송룸 요청 메시지에 기초하여 상기 제1 클라이언트의 역할을 결정하고, 상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할을 결정한다. 상기 제1 클라이언트의 역할은 마스터 사용자이고, 상기 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정하는 경우, 상기 프록시 서버는 상기 제1 라이브 미디어 스트림만을 상기 프록시 클라이언트로 송신하여, 상기 프록시 클라이언트가 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신하도록 한다.

이 측면에서 제공되는 방법에 따르면, 상기 슬레이브 사용자의 역할을 하는 제2 클라이언트가 라이브 미디어 스트림을 획득하는 것을 요청하는 경우, 상기 프록시 클라이언트는 상기 마스터 사용자의 역할을 하는 제1 클라이언트에 의해 요청된 상기 로컬로 캐시된 제1 라이브 미디어 스트림만을 상기 제2 클라이언트로 직접 전송하면 되므로, 상기 프록시 서버는 상기 라이브 미디어 스트림을 상기 프록시 클라이언트으로 다시 송신할 필요가 없고, 상기 프록시 서버는 상기 라이브 미디어 스트림을 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 각각의 클라이언트로 송신할 필요가 없다. 이 방법은 상기 프록시 서버와 상기 프록시 클라이언트 사이의 미디어 스트림 전송을 위한 트래픽을 줄이고, 송신 대역폭을 효과적으로 줄이며, 리소스 오버헤드를 줄인다.

제1 측면을 참조로, 상기 제1 측면의 가능한 구현예로서, 상기 제1 라이브 방송룸 요청 메시지는 상기 프록시 클라이언트의 식별자를 포함하고, 상기 제2 라이브 방송룸 요청 메시지는 상기 프록시 클라이언트의 식별자를 포함한다. 상기 방법은, 상기 프록시 서버가, 상기 제1 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자 및 상기 제2 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자에 기초하여, 상기 제1 라이브 방송룸 요청 메시지 및 상기 제2 라이브 방송룸 요청 메시지는 상기 동일한 프록시 클라이언트로부터 온 것으로 결정하는 것을 포함한다. 이 측면에서, 상기 프록시 클라이언트의 식별자는 상기 제1 라이브 방송룸 요청 메시지 또는 상기 제2 라이브 방송룸 요청 메시지에서 전달되어, 상기 프록시 서버는 포워딩 메시지 및 응답을 포워딩하는 경우 수신단을 결정할 수 있고, 이에 따라 메시지 수신 및 송신을 용이하게 한다.

제1 측면을 참조로, 상기 제1 측면의 다른 가능한 구현예로서, 상기 프록시 서버가 상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할을 결정하는 것은, 다음을 포함한다: 상기 프록시 서버는, 상기 제2 라이브 방송룸 요청 메시지가 수신되는 경우, 상기 라이브 방송룸에서 역할이 마스터 사용자이고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트가 상기 라이브 방송룸 내에 있는지 여부를 결정하고; 그리고 상기 라이브 방송룸에서 역할이 마스터 사용자이고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트가 상기 라이브 방송룸 내에 있으면, 상기 프록시 서버는 상기 제2 클라이언트의 역할이 상기 슬레이브 사용자인 것으로 결정한다. 이 구현예에서, 단일의 마스터 사용자가 있는 기술적 시나리오에서, 상기 프록시 서버는 상기 라이브 방송룸에 마스터 사용자가 있는지 여부만을 결정할 필요가 있으므로, 상기 프록시 서버는 상기 라이브 방송룸에 진입하는 클라이언트의 ID 역할(identity role)을 결정할 수 있다. 따라서, 클라이언트의 역할은 신속히 식별되고 마킹될 수 있다.

이에 상응하여, 마스터 사용자 역할을 하는 클라이언트가 없으면, 상기 프록시 서버는 상기 제2 클라이언트의 역할이 마스터 사용자인 것으로 결정한다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 프록시 서버가 상기 제1 라이브 미디어 스트림을 상기 프록시 클라이언트로 송신한 후, 상기 방법은 다음을 포함한다: 상기 프록시 서버가 상기 프록시 클라이언트에 의해 송신되는 그리고 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하고-여기서, 상기 라이브 방송룸을 나가기 위한 요청 메시지는 상기 제1 클라이언트에게 상기 라이브 방송룸을 나갈 것을 요청하는데 사용됨-; 상기 제2 클라이언트를 새로운 마스터 사용자로 결정하는 경우, 상기 프록시 서버는 상기 제2 클라이언트의 역할을 상기 슬레이브 사용자로부터 마스터 사용자로 변경하고; 그리고 상기 프록시 서버는 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 상기 제2 라이브 미디어 스트림으로 스위칭한다. 이 구현예에서, 상기 마스터 사용자의 역할을 하는 제1 클라이언트가 상기 라이브 방송룸을 나가는 경우, 상기 새로운 마스터 사용자의 역할을 하는 제2 클라이언트의 ID(identity)가 상기 미디어 서버로부터 라이브 미디어 스트림을 요청하고 획득하는데 사용되어, 상기 라이브 방송룸에서 여전히 미디어 컨텐츠를 시청하는 제2 클라이언트는 영향을 받지 않고, 상기 라이브 방송룸에서 상기 제2 클라이언트의 사용자의 라이브 방송을 시청하는 사용자 경험을 보장한다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 프록시 서버에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 프록시 서버에 의해 상기 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 인접한 프레임이다. 상기 프록시 서버가 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 상기 제2 라이브 미디어 스트림으로 스위칭하기 전에, 상기 방법은 다음을 더 포함한다: 상기 프록시 서버는, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 기초하여, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하며, 여기서 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임이다.

상기 프록시 서버는, 상기 제1 I 프레임 및 상기 제2 I 프레임에 기초하여, 서로 인접하고 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하고, 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임을 상기 제2 클라이언트로 송신되는 상기 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임으로 각각 사용한다. 상기 프록시 서버가 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임을 결정한 후, 상기 방법은, 상기 프록시 서버는 상기 라이브 방송룸을 나가기 위한 요청 메시지를 상기 제1 클라이언트로부터 상기 미디어 서버로 포워딩하는 것을 포함한다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 프록시 서버가 상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할을 결정하는 것은, 상기 프록시 서버가 상기 제2 라이브 방송룸 요청 메시지를 수신하는 경우 상기 프록시 서버는 마스터 사용자의 역할을 하고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하는지 여부를 결정하는 것을 포함하며, 여기서 상기 미리 정해진 상한치는 2보다 크거나 같다. 상기 마스터 사용자의 역할을 하고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트의 수량이 상기 미리 정해진 상한치에 도달하면, 상기 프록시 서버는 상기 제2 클라이언트의 역할이 상기 슬레이브 사용자인 것으로 결정한다. 이 구현예에서, 복수의 마스터 사용자가 있는 기술적 시나리오에서, 즉, 하나의 주-마스터 사용자 및 복수의 부-마스터 사용자가 있는 시나리오에서, 상기 라이브 방송룸에서 마스터 사용자로서 서빙하는 클라이언트의 수량이 계산되고 상기 미리 정해진 상한치와 비교하어, 클라이언트의 역할을 결정한다. 클라이언트의 역할은 대안적으로 다른 방식으로 결정될 수 있음을 이해할 수 있다. 예를 들어, 클라이언트의 역할은 라이브 방송룸 요청의 수량에 기초하여 결정될 수 있다. 이는 본 실시예에서 제한되지 않는다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 라이브 방송룸에서 마스터 사용자의 역할을 하는 클라이언트의 수량이 0이 아니고 상기 미리 정해진 상한치에 도달하지 않으면, 상기 프록시 서버는 상기 제2 클라이언트의 역할이 부-마스터 사용자인 것으로 결정한다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 제1 클라이언트가 주-마스터 사용자이고, 상기 제2 클라이언트가 슬레이브 사용자인 경우, 상기 방법은 다음을 포함한다: 상기 프록시 서버는, 상기 제1 클라이언트로부터, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하고; 상기 제2 클라이언트를 새로운 부-마스터 사용자로 결정하는 경우, 상기 프록시 서버는 상기 제2 클라이언트의 역할을 상기 슬레이브 사용자로부터 부-마스터 사용자로 변경하고; 그리고 상기 프록시 서버는 상기 수신되는 제2 라이브 미디어 스트림을 화상 그룹 GOP으로 캐싱한다. 이 구현예에서, 상기 제2 클라이언트가 상기 부-마스터 사용자인 경우, 상기 프록시 서버는 상기 제2 라이브 미디어 스트림을 상기 미디어 서버로부터 수신하고, 상기 제2 라이브 미디어 스트림을 로컬로 저장하여, 사용자 역할이 후에 변경되는 경우 상기 라이브 방송룸 내의 클라이언트에 대해 상기 캐시된 제2 라이브 미디어 스트림을 제공한다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 제1 클라이언트가 주-마스터 사용자이고, 상기 제2 클라이언트가 부-마스터 사용자인 경우, 상기 방법은 다음을 더 포함한다: 상기 프록시 서버는 상기 수신되는 제2 라이브 미디어 스트림을 GOP로 캐시하고; 그리고 상기 프록시 서버는, 상기 제1 라이브 미디어 스트림 및 상기 캐시된 제2 라이브 미디어 스트림에 기초하여, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하며, 여기서 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임이다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 방법은 다음을 더 포함한다: 상기 프록시 서버는, 상기 제1 클라이언트로부터, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하고; 상기 제2 클라이언트를 새로운 주-마스터 사용자로 결정하는 경우, 상기 프록시 서버는 상기 제2 클라이언트의 역할을 상기 부-마스터 사용자로부터 주-마스터 사용자로 변경하고; 상기 프록시 서버는, 상기 제1 I 프레임 및 상기 제2 I 프레임에 기초하여, 서로 인접하고 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하고; 그리고 상기 프록시 서버는, 상기 제2 클라이언트으로 송신되는 상기 제1 라이브 미디어 스트림을, 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임에 기초하여 상기 제2 라이브 미디어 스트림으로 스위칭하며, 여기서, 상기 프록시 서버에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임은 상기 제1 스위칭 프레임이고, 상기 프록시 서버에 의해 상기 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 상기 제2 스위칭 프레임이다. 이 구현예에서, 상기 제2 클라이언트의 역할이 상기 부-마스터 사용자로부터 상기 주-마스터 사용자로 변경되는 경우, 상기 프록시 서버는 상기 제2 라이브 미디어 스트림을 상기 미디어 서버로부터 수신 및 캐시하고, 상기 캐시된 제2 라이브 미디어 스트림을 복제하고, 복제된 캐시된 제2 라이브 미디어 스트림을 상기 라이브 방송룸 내의 모든 클라이언트로 전달하여, 상기 라이브 방송룸 내의 다른 클라이언트는 영향을 받지 않고 상기 라이브 방송 컨텐츠를 정상적으로 시정할 수 있도록 한다.

제1 측면을 참조로, 상기 제1 측면의 또 다른 가능한 구현예로서, 상기 프록시 서버는 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림을 GOP에 의해 캐싱한다. 선택사항으로서, 상기 프록시 서버는, 상기 제1 라이브 미디어 스트림의 3개의 GOP 및 상기 제2 라이브 미디어 스트림의 3개의 GOP를 로컬로 캐싱한다.

제2 측면에 따르면, 본 출원의 실시예는 미디어 스트림 송신 방법을 추가로 제공한다. 이 방법은 라이브 방송룸에 진입하는 클라이언트에 대해 라이브 미디어 스트림을 제공한다. 이 방법은, 다음을 포함한다: 프록시 클라이언트는 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제1 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지, 및 상기 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제2 클라이언트에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신하고; 상기 프록시 클라이언트는 상기 제1 라이브 방송룸 요청 메시지 및 상기 제2 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신하고; 상기 프록시 클라이언트는 상기 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하며-여기서, 상기 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 전송되는 제1 라이브 미디어 스트림은 미디어 스트림이고, 상기 제1 클라이언트의 역할은 마스터 사용자이고, 상기 제2 클라이언트의 역할은 슬레이브 사용자임-; 그리고 상기 프록시 클라이언트는 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신한다.

이 측면에서 제공되는 방법에 따르면, 동일한 프록시 클라이언트를 통해 상기 라이브 방송룸에 액세스하는 모든 사용자에 대해, 상기 프록시 서버는 하나의 라이브 미디어 스트림만을 상기 프록시 클라이언트로 송신하면 되고, 즉, 상기 프록시 클라이언트는 상기 프록시 서버에 의해 송신되는 하나의 라이브 미디어 스트림을 수신하기 위해 광역 네트워크 대역폭을 소비한다. 상기 미디어 서버가 상기 라이브 방송룸 내의 각각의 클라이언트로 상기 라이브 미디어 스트림을 전송하는 경우 차지하는 전송 리소스와 비교하여, 이는 WAN 네트워크 링크 부하를 줄이고 전송 오버헤드를 줄인다.

제2 측면을 참조로, 상기 제2 측면의 가능한 구현예로서, 상기 프록시 클라이언트가 상기 제1 라이브 방송룸 요청 메시지를 상기 프록시 서버를 통해 상기 미디어 서버로 송신하기 전에, 상기 방법은 다음을 더 포함하고: 상기 프록시 클라이언트는 상기 프록시 클라이언트의 식별자를 상기 제1 라이브 방송룸 요청 메시지에 추가하고; 그리고 상기 프록시 클라이언트가 상기 제2 라이브 방송룸 요청 메시지를 상기 프록시 서버를 통해 상기 미디어 서버로 송신하기 전에, 상기 방법은 다음을 더 포함한다: 상기 프록시 클라이언트는 상기 프록시 클라이언트의 상기 식별자를 상기 제2 라이브 방송룸 요청 메시지에 추가한다.

제2 측면을 참조로, 상기 제2 측면의 다른 가능한 구현예로서, 상기 프록시 클라이언트가 상기 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신한 후, 상기 방법은 다음을 더 포함한다: 상기 프록시 클라이언트는 상기 제1 라이브 미디어 스트림을 화상 그룹 GOP로 캐시한다.

제2 측면을 참조로, 상기 제2 측면의 또 다른 가능한 구현예로서, 상기 프록시 클라이언트가 상기 제1 라이브 미디어 스트림을 상기 제2 클라이언트로 송신하기 전에, 상기 방법은 다음을 더 포함한다: 상기 프록시 클라이언트는 상기 제1 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 상기 프록시 클라이언트에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프가 0임을, 그리고 상기 제2 클라이언트로 송신되는 상기 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 충족한다.

제2 측면을 참조로, 상기 제2 측면의 또 다른 가능한 구현예로서, 상기 제1 클라이언트가 상기 라이브 방송룸을 나갈 것을 요청하는 경우, 상기 방법은 다음을 더 포함한다: 상기 프록시 클라이언트는 상기 프록시 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신하며-여기서, 상기 제2 라이브 미디어 스트림은 상기 미디어 서버에 의해 상기 프록시 클라이언트를 통해 상기 제2 클라이언트로 송신되는 미디어 스트림이고, 상기 제2 클라이언트는 상기 슬레이브 사용자로부터 마스터 사용자로 역할이 변경되는 클라이언트임-; 그리고 상기 프록시 클라이언트는 상기 제2 라이브 미디어 스트림을 상기 제2 클라이언트로 송신한다.

제2 측면을 참조로, 상기 제2 측면의 또 다른 가능한 구현예로서, 상기 프록시 클라이언트가 상기 제2 라이브 미디어 스트림을 상기 제2 클라이언트로 송신하기 전에, 상기 방법은 다음을 더 포함한다: 상기 프록시 클라이언트는 상기 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 상기 프록시 클라이언트에 의해 상기 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임 및 상기 프록시 클라이언트에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 충족한다.

제3 측면에 따르면, 본 출원의 실시예는 미디어 스트림 송신 장치를 제공한다. 상기 장치는, 상기 제1 측면 또는 상기 제1 측면의 구현예 중 어느 하나에 따른 방법 단계를 수행하도록 구성되는 유닛을 포함한다. 구체적으로, 상기 장치는 수신 유닛, 처리 유닛, 및 송신 유닛을 포함한다. 또한, 상기 장치는 다른 모듈 또는 유닛, 예를 들어, 저장 유닛을 더 포함할 수 있다.

선택사항으로서, 상기 장치는 프록시 서버이다.

제4 측면에 따르면, 본 출원의 실시예는 미디어 스트림 송신 장치를 제공한다. 상기 장치는, 상기 제2 측면 또는 상기 제2 측면의 구현예 중 어느 하나에 따른 방법 단계를 수행하도록 구성되는 유닛을 포함한다. 구체적으로, 상기 장치는 수신 유닛, 처리 유닛, 및 송신 유닛을 포함한다. 또한, 상기 장치는 다른 모듈 또는 유닛, 예를 들어, 저장 유닛을 더 포함할 수 있다.

선택사항으로서, 상기 장치는 프록시 클라이언트이다.

제5 측면에 따르면, 본 출원의 실시예는, 송수신기, 프로세서, 및 메모리를 포함하는 네트워크 디바이스를 추가로 제공한다. 상기 프로세서는 상기 메모리에 연결되고; 그리고 상기 메모리는 명령을 저장하도록 구성된다. 상기 프로세서는, 상기 명령을 호출하여 상기 네트워크 디바이스가 상기 제1 측면 또는 상기 제1 측면의 구현예 중 어느 하나에 따른 미디어 스트림 송신 방법를 수행하게 하도록, 또는 상기 명령을 호출하여 상기 네트워크 디바이스가 상기 제2 측면 또는 상기 제2 측면의 구현예 중 어느 하나에 따른 미디어 스트림 송신 방법를 수행하게 하도록 구성된다.

선택사항으로서, 상기 네트워크 디바이스는 프록시 서버 또는 프록시 클라이언트이다.

또한, 이 측면의 가능한 구현예로서, 상기 네트워크 디바이스가 프록시 서버인 경우, 상기 송수신기는, 상기 라이브 방송룸 입장을 요청하는데 사용되고 동일한 프록시 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 수신하도록; 그리고 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 전송되는 제1 라이브 미디어 스트림 및 상기 미디어 서버에 의해 상기 프록시 서버를 통해 제2 클라이언트로 전송되는 제2 라이브 미디어 스트림을 수신하도록 구성되며, 여기서, 상기 제1 라이브 방송룸 요청 메시지는 상기 제1 클라이언트로부터 온 것이고, 상기 제2 라이브 방송룸 요청 메시지는 상기 제2 클라이언트로부터 온 것이다. 상기 프로세서는, 상기 제1 라이브 방송룸 요청 메시지에 기초하여 상기 제1 클라이언트의 역할을 결정하도록, 그리고 상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할하도록 구성된다. 상기 송수신기는, 상기 제1 클라이언트의 역할이 마스터 사용자이고 상기 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정되는 경우, 상기 제1 라이브 미디어 스트림만을 상기 프록시 클라이언트로 송신하여, 상기 프록시 클라이언트가 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신하도록, 추가적으로 구성된다.

선택사항으로서, 이 측면의 다른 가능한 구현예로서, 상기 네트워크 디바이스가 프록시 클라이언트인 경우, 상기 송수신기는, 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제1 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지, 및 상기 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제2 클라이언트에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신하도록; 상기 제1 라이브 방송룸 요청 메시지 및 상기 제2 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신하도록, 구성된다. 상기 송수신기는, 상기 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하도록, 그리고 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신하도록, 추가적으로 구성된다. 상기 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 전송되는 제1 라이브 미디어 스트림은 미디어 스트림이고, 상기 제1 클라이언트의 역할은 마스터 사용자이고, 상기 제2 클라이언트의 역할은 슬레이브 사용자이다.

제6 측면에 따르면, 본 출원의 실시예는 컴퓨터-판독 가능한 저장 매체을 추가로 제공한다. 상기 저장 매체는 명령을 저장한다. 상기 명령이 컴퓨터 또는 프로세서 상에서 실행되는 경우, 상기 제1 측면 또는 상기 제1 측면의 구현예 중 어느 하나에 따른 방법 또는 상기 제2 측면 또는 상기 제2 측면의 구현예 중 어느 하나에 따른 방법이 수행된다.

제7 측면에 따르면, 본 출원의 실시예는 컴퓨터 프로그램 제품을 추가로 제공한다. 상기 컴퓨터 프로그램 제품은 컴퓨터 명령을 포함한다. 상기 명령이 컴퓨터 또는 프로세서에 의해 실행되는 경우, 상기 제1 측면 또는 상기 제1 측면의 구현예 중 어느 하나에 따른 방법 또는 상기 제2 측면 또는 상기 제2 측면의 구현예 중 어느 하나에 따른 방법이 구현될 수 있다.

제8 측면에 따르면, 본 출원의 실시예는 미디어 스트림 송신 시스템을 추가로 제공한다. 상기 시스템은 적어도 하나의 클라이언트, 프록시 클라이언트, 프록시 서버, 및 미디어 서버를 포함한다. 각각의 클라이언트는 상기 프록시 클라이언트를 통해 라이브 방송룸에 액세스한다. 상기 시스템은, 상기 프록시 클라이언트 및 상기 프록시 서버를 통해, 상기 제1 측면, 상기 제2 측면, 상기 제1 측면의 구현예, 또는 상기 제2 측면의 구현예 중 어느 하나에 따른 미디어 스트림 송신 방법을 구현한다. 상기 프록시 클라이언트는 상기 제2 측면 또는 상기 제2 측면의 구현예 중 어느 하나에 따른 방법에 따른 미디어 스트림 송신 방법을 수행하도록 구성되고, 상기 프록시 서버는 상기 제1 측면 또는 상기 제1 측면의 구현예 중 어느 하나에 따른 방법에 따른 미디어 스트림 송신 방법을 수행하도록 구성된다.

선택사항으로서, 상기 프록시 서버는 상기 제3 측면 또는 상기 제3 측면의 구현예 중 어느 하나에 따른 미디어 스트림 송신 장치이고, 상기 프록시 클라이언트는 상기 제4 측면 또는 상기 제4 측면의 구현예 중 어느 하나에 따른 미디어 스트림 송신 장치이다.

제8 측면을 참조로, 상기 제8 측면의 가능한 구현예로서, 상기 프록시 서버 및 상기 미디어 서버는 지역 데이터 센터 RDC에 위치한다. 상기 RDC는 웹 서버를 더 포함하고, 상기 웹 서버는 상기 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트에 미디어 서버를 할당하도록 구성된다.

제8 측면을 참조로, 상기 제8 측면의 다른 가능한 구현예로서, 상기 시스템은 엔터프라이즈 데이터 센터 EDC 및 컨텐츠 소스를 더 포함한다.

선택사항으로서, 상기 미디어 스트림 송신 시스템은 컨텐츠 전달 네트워크 CDN 시스템이다.

또한, 본 출원의 실시예는 칩 시스템을 추가로 제공한다. 상기 칩 시스템은 프로세서와 인터페이스 회로를 포함한다. 상기 인터페이스 회로는 상기 프로세서에 연결된다. 상기 프로세서는, 컴퓨터 프로그램 또는 명령을 실행하여, 상기 제1 측면 또는 상기 제1 측면의 구현예 중 어느 하나에 따른 방법을 구현하거나 상기 제2 측면 또는 상기 제2 측면의 구현예 중 어느 하나에 따른 방법을 구현하도록 구성된다. 상기 인터페이스 회로는 상기 칩 시스템 외부의 다른 모듈과 통신하도록 구성된다.

본 출원에서 제공되는 방법에 따르면, 상기 프록시 클라이언트 및 상기 프록시 서버가 상기 마스터 사용자로서 서빙하는 상기 클라이언트에 의해 요청되는 라이브 미디어 스트림을 획득하는 경우, 상기 미디어 스트림의 일부 세그먼트는 상기 프록시 클라이언트 내에 로컬로 캐시된다. 다른 클라이언트가 상기 라이브 방송룸에 진입하고 상기 라이브 미디어 스트림을 요청하는 경우, 상기 프록시 클라이언트는 상기 로컬로 캐시된 미디어 스트림을 이러한 클라이언트로 직접 송신하여, 상기 프록시 서버는 상기 라이브 미디어 스트림을 상기 프록시 클라이언트 및 상기 제2 클라이언트로 다시 송신할 필요가 없다. 이 방법에서, 상기 마스터 사용자로서 서빙하는 상기 클라이언트에 의해 요청되는 라이브 미디어 스트림만이 상기 프록시 서버와 상기 프록시 클라이언트 사이에서 송신되며, 달리 말하면, 상기 라이브 미디어 스트림을 전송하기 위한 광역 네트워크 대역폭만이 소비된다. 상기 미디어 서버가 상기 프록시 서버를 통해 상기 라이브 미디어 스트림을 각각의 클라이언트로 송신하는 경우 차지하는 전송 리소스와 비교하여, 이는 상기 미디어 스트림을 송신하기 위한 트래픽을 줄이고, WAN 네트워크 링크 부하를 줄이고, 그리고 리소스 오버헤드를 줄인다.

또한, 상기 프록시 클라이언트가 라이브 미디어 스트림을 상기 라이브 방송룸 내의 모든 클라이언트로 송신하는 경우, 상기 프록시 클라이언트는 상기 라이브 미디어 스트림의 타임스탬프를 또한 조정한다. 예를 들어, 상기 마스터 사용자로서 서빙하는 제1 클라이언트가 상기 라이브 방송룸을 나가는 경우, 상기 프록시 클라이언트는, 원래 상기 제2 클라이언트로 송신되는 상기 제1 라이브 미디어 스트림을 상기 제2 라이브 미디어 스트림으로 스위칭하고, 상기 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 상기 프록시 클라이언트가 상기 제2 라이브 미디어 스트림을 상기 제2 클라이언트로 송신하는 경우, 상기 제2 라이브 미디어 스트림은 원래 재생 중인 제1 라이브 미디어 스트림의 미디어 컨텐츠에 끊어지지 않고 연결될 수 있다. 상기 제1 클라이언트의 이탈로 인해 초래되는, 상기 제2 클라이언트에서 시청되는 미디어 컨텐츠에 대한 비디오 정지 또는 다른 영향을 피할 수 있다. 따라서, 이 방법에 따르면, 상기 프록시 클라이언트에 의한 타임스탬프의 조정은 또한 시청에 대한 사용자 경험을 보장한다.

도 1은 본 출원에 따른 라이브 방송 시스템의 아키텍처의 개략도이다.
도 2는 본 출원의 실시예에 따른 비디오 라이브 방송을 위한 양방향 프록시 시스템의 아키텍처의 개략도이다.
도 3은 본 출원의 실시예에 따른 미디어 스트림 송신 방법의 흐름도이다.
도 4는 본 출원의 실시예에 따른 다른 미디어 스트림 송신 방법의 흐름도이다.
도 5a 내지 도 5d는 본 출원의 실시예에 따른 미디어 스트림 송신 방법의 시그널링 흐름도이다.
도 6a 및 도 6b는 본 출원의 실시예에 따른 다른 미디어 스트림 송신 방법의 시그널링 흐름도이다.
도 7a 내지 도 7c는 본 출원의 실시예에 따른 또 다른 미디어 스트림 송신 방법의 시그널링 흐름도이다.
도 8a 내지 도 8c는 본 출원의 실시예에 따른 또 다른 미디어 스트림 송신 방법의 시그널링 흐름도이다.
도 9는 본 출원의 실시예에 따른 미디어 스트림 송신 장치의 개략적인 구조도이다.
도 10은 본 출원의 실시예에 따른 네트워크 디바이스의 개략적인 구조도이다.

통상의 기술자가 본 출원의 실시예의 기술적 해결 수단을 더 잘 이해하고 본 출원의 실시예의 목적, 특징, 및 이점을 더 명확하게 하기 위해, 다음은 본 출원의 실시예의 기술적 해결 수단을 첨부된 도면을 참조하여 더욱 상세하게 설명한다.

본 출원의 실시예의 기술적 해결 수단을 설명하기 전에, 첨부된 도면을 참조하여 본 출원의 실시예의 응용 시나리오를 먼저 설명한다.

본 출원의 기술적 해결 수단은 컨텐츠 전달 네트워크(content delivery network, CDN) 시스템에 적용될 수 있고, 시스템에 새로이 추가된 디바이스는 프록시 서버(proxy server) 및 프록시 클라이언트(proxy client)를 포함한다.

프록시 서버는, 사용자의 비디오 베어러 프로토콜에 대한 프록시로서 작용하도록, 프록시 서버를 통해 라이브 방송룸에 진입하는 모든 클라이언트의 역할을 식별하도록, 미디어 서버로부터 적어도 하나의 라이브 미디어 스트림을 획득하도록, 그리고 마스터 사용자로서 서빙하는 클라이언트의 라이브 미디어 스트림을 프록시 클라이언트로 송신하도록 구성된다. 또한, 마스터 사용자 역할을 하는 클라이언트가 라이브 방송룸을 나가는 경우, 프록시 서버는 라이브 방송룸 내의 다른 사용자의 역할을 업데이트하도록 그리고 라이브 미디어 스트림을 새로운 라이브 미디어 스트림으로 스위칭하도록 추가적으로 구성된다. 프록시 클라이언트는, 사용자의 비디오 베어러 프로토콜에 대한 프록시로서 작용하도록, 그리고 마스터 사용자 역할을 하는 클라이언트의 그리고 프록시 서버에 의해 송신되는 라이브 미디어 스트림을 수신하고, 라이브 미디어 스트림을 복제하고 복제된 라이브 미디어 스트림을 프록시 클라이언트를 통해 라이브 방송룸에 액세스하는 라이브 방송룸 내의 모든 클라이언트로 전달하도록, 구성된다.

선택사항으로서, 프록시 서버는 지역 데이터 센터(Region Data Center, RDC)에 위치할 수 있다. 구체적으로, 프록시 서버는 서버 상에 배치되거나, 네트워크 기능 가상화(Network Functions Virtualization, NFV)를 통해 범용 고객 댁내 장비(Universal Customer Premise Equipment, uCPE)에 배치될 수 있다.

선택사항으로서, 프록시 클라이언트는 근거리 네트워크의 에지에 위치한 디바이스일 수 있으며, 근거리 네트워크의 클라이언트는 프록시 클라이언트를 통해 라이브 방송룸에 진입하고 프록시 클라이언트를 통해 라이브 미디어 스트림을 획득한다. 프록시 클라이언트는 서버 상에 배치되거나, NFV를 통해 uCPE 상에 배치될 수 있다.

또한, 도 2에 도시된 바와 같이, 실시예는 비디오 CDN 시스템를 제공한다. 시스템은, 컨텐츠 소스(content source)(101), 엔터프라이즈 데이터 센터(enterprise data center, EDC)(102), RDC(103), 프록시 클라이언트(104), 및 예를 들어, 제1 클라이언트 C1(105), 제2 클라이언트 C2(106), 및 제3 클라이언트 C3(107)와 같은 적어도 하나의 클라이언트(client, C)를 포함한다. EDC(102)는 복수의 미디어 서버(media server) 및 웹 서버(Web server)를 포함한다. RDC(103)는 프록시 서버, 복수의 미디어 서버, 웹 서버, 등을 포함한다. 프록시 서버 및 프록시 클라이언트는 WAN 네트워크를 통해 서로 연결되며, 프록시 클라이언트 및 프록시 클라이언트와 연관된 적어도 하나의 클라이언트는 근거리 네트워크(local area network, LAN)를 통해 서로 연결된다.

또한, 라이브 방송 CDN은 분산 컨텐츠 전달 플랫폼이고 다중-레벨 아키텍처를 지원한다. 라이브 방송 CDN 플랫폼에서, 복수의 미디어 서버는, 상이한 지역의 사용자에게 근거리 서비스(nearby service)를 제공하도록, 상이한 레이어에 배치될 수 있다. EDC의 사용자가 라이브 방송룸에서 라이브 방송을 시청하는 경우, 할당되는 미디어 서버는 RDC에 배치될 수 있으며, 전송되는 라이브 미디어 스트림은 다중-프로토콜 레이블 스위칭(Multi-Protocol Label Switching, MPLS) 사설 라인을 통해 RDC 및 프록시 클라이언트에 도달한다.

또한, 전술한 디바이스 또는 네트워크 엘리먼트의 기능에 대한 일반적인 설명은 다음 표 1에 설명되어 있다.

네트워크 엘리먼트 이름		기능
컨텐츠 소스		라이브 미디어 스트림(라이브 방송 컨텐츠)의 생산단이다.
EDC	웹 서버	클라이언트로부터의 라이브 방송을 시청하기 위한 요청에 응답하고, 사용자를 인증하고, 사용자의 위치에 기초하여 가장 가까운 미디어 서버를 사용자에게 할당한다.
	미디어 서버	컨텐츠 소스에 의해 송신되는 미디어 스트림을 저장하고 미디어 스트림을 하위-레벨 미디어 서버로 송신하거나; 또는 미디어 스트림을 클라이언트로 직접 송신하여 사용자에 대해 서비스를 제공한다.
RDC	웹 서버	클라이언트로부터의 라이브 방송을 시청하기 위한 요청에 응답하고, 사용자를 인증하고, 사용자의 위치에 기초하여 가장 가까운 미디어 서버를 사용자에게 할당한다.
	미디어 서버	상위-레벨 미디어 서버에 의해 송신되는 미디어 스트림(라이브 방송 컨텐츠)를 저장하고 미디어 스트림을 하위-레벨 미디어 서버로 송신하거나; 또는 미디어 스트림을 클라이언트로 직접 송신하여 사용자에 대해 서비스를 제공한다.
	프록시 서버	사용자의 비디오 베어러 프로토콜에 대한 프록시로서 작용하고, 사용자의 역할을 식별하고, 미디어 서버에 미디어 스트림 요청을 개시하고, 미디어 서버에 의해 송신되는 적어도 하나의 라이브 미디어 스트림을 수신하고, 그리고 마스터 사용자 역할을 하는 클라이언트에 의해 요청된 라이브 미디어 스트림만을 프록시 클라이언트로 송신한다.
프록시 클라이언트		사용자의 비디오 베어러 프로토콜에 대한 프록시로서 작용하고, 마스터 사용자 역할을 하는 클라이언트의 그리고 프록시 서버에 의해 송신되는 라이브 미디어 스트림을 수신하고, 라이브 미디어 스트림을 복제하고, 그리고 복제된 라이브 미디어 스트림을 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 다른 클라이언트로 전달한다.
클라이언트 PC		라이브 방송을 시청하는 사용자이다.

또한, 본 출원의 본 실시예로 기술된 시스템, 프록시 서버는 하나 이상의 프록시 클라이언트에 대응할 수 있다는 점에 유의해야 한다. 예를 들어, 프록시 서버는 프록시 클라이언트 1 및 프록시 클라이언트 2에 대응한다. 근거리 네트워크 1의 클라이언트는 프록시 클라이언트 1 및 프록시 서버를 통해 라이브 방송룸에 진입한다. 근거리 네트워크 2의 클라이언트는 프록시 클라이언트 2 및 프록시 서버를 통해 라이브 방송룸에 진입한다. 또한, 프록시 서버는, 다음 구현예 A 또는 구현예 B에서, 프록시 서버를 통해 라이브 방송룸에 진입하는 각각의 클라이언트의 역할을 결정할 수 있다.

구현예 A: 동일한 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 클라이언트의 역할은 중앙에서 결정된다. 예를 들어, 프록시 서버는 프록시 클라이언트 1 및 프록시 클라이언트 2에 대응한다. 프록시 서버는 프록시 클라이언트 1를 통해 라이브 방송룸에 진입하는 클라이언트로부터 적어도 하나의 마스터 사용자를 결정하고, 다른 클라이언트를 슬레이브 사용자로 결정하며; 그리고 프록시 클라이언트 2를 통해 라이브 방송룸에 진입하는 클라이언트로부터 적어도 하나의 마스터 사용자를 결정하고, 다른 클라이언트를 슬레이브 사용자로 결정한다. 구현예 A에서 클라이언트의 역할을 결정하는 경우, 이에 상응하여, 프록시 서버는 마스터 사용자 역할을 하는 클라이언트의 라이브 미디어 스트림을 프록시 클라이언트로 송신하고, 그런 다음 프록시 클라이언트는 라이브 미디어 스트림을 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 클라이언트로 송신한다. 구현예 A가 클라이언트의 역할을 결정하는데 사용되는 경우, 각각의 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트는 마스터 사용자 역할을 하는 클라이언트를 포함함을 이해할 수 있다. 프록시 서버에 의해 임의의 프록시 클라이언트로 송신되는 미디어 스트림는 마스터 사용자 역할을 하고 라이브 방송룸에 진입하는 클라이언트의 미디어 스트림이다.

구현예 B: 프록시 서버를 통해 라이브 방송룸에 진입하는 모든 클라이언트의 역할은 중앙에서 결정된다. 예를 들어, 프록시 서버는 프록시 클라이언트 1 및 프록시 클라이언트 2에 대응하며, 적어도 하나의 마스터 사용자는 프록시 클라이언트 1 및 프록시 클라이언트 2를 통해 라이브 방송룸에 진입하는 모든 클라이언트로부터 결정되고, 다른 클라이언트는 슬레이브 사용자로 결정된다. 구현예 B에서 클라이언트의 역할을 결정하는 경우, 이에 상응하여, 프록시 서버는 마스터 사용자 역할을 하는 클라이언트의 라이브 미디어 스트림을 시스템 내의 프록시 서버에 대응하는 각각의 프록시 클라이언트로 송신하고, 그런 다음 각각의 프록시 클라이언트는 라이브 미디어 스트림을 각각의 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 클라이언트로 송신한다.

설명의 편의상, 실시예에서, 마스터 사용자 역할을 하는 클라이언트는 마스터 사용자로서 서빙하는 클라이언트로 간단히 지칭될 수 있다. 이와 유사하게, 슬레이브 사용자 역할을 하는 클라이언트는 슬레이브 사용자로서 서빙하는 클라이언트로 간단히 지칭될 수 있다.

구체적으로, 도 3은 실시예에서 제공되는 미디어 스트림 송신 방법을 도시한다. 이 방법은 동일한 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 클라이언트에 대해 라이브 미디어 스트림을 제공한다. 구체적으로, 이 방법은 다음 단계를 포함한다:

단계 101: 프록시 서버는 라이브 방송룸 입장을 요청하는데 사용되고 동일한 프록시 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 수신하며, 여기서, 제1 라이브 방송룸 요청 메시지는 제1 클라이언트로부터 온 것이고, 제2 라이브 방송룸 요청 메시지는 제2 클라이언트로부터 온 것이다.

제1 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자를 포함하고, 제2 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자를 포함하며, 여기서, 식별자는 프록시 클라이언트의 IP 주소, 포트 번호, 등일 수 있다. 프록시 서버는, 제1 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자에 기초하여, 제1 라이브 방송룸 요청 메시지를 포워딩하는 프록시 클라이언트를 결정할 수 있고; 제2 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자에 기초하여, 제2 라이브 방송룸 요청 메시지를 포워딩하는 프록시 클라이언트를 결정할 수 있고; 그리고 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지는 동일한 프록시 클라이언트로부터 오는 것임을 추가로 결정할 수 있다.

단계 102: 프록시 서버는 미디어 서버에 의해 프록시 서버를 통해 제1 클라이언트로 전송되는 제1 라이브 미디어 스트림 및 미디어 서버에 의해 프록시 서버를 통해 제2 클라이언트로 전송되는 제2 라이브 미디어 스트림을 수신한다.

구체적으로, 제1 클라이언트에 의해 송신되는 제1 미디어 요청 메시지를 수신한 후, 프록시 서버는 제1 미디어 요청 메시지를 미디어 서버로 포워딩하고, 제1 미디어 요청 메시지에 기초하여 미디어 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신한다. 제2 클라이언트에 의해 송신되는 제2 미디어 요청 메시지를 수신한 후, 프록시 서버는 제2 미디어 요청 메시지를 미디어 서버로 포워딩하고, 제2 미디어 요청 메시지에 기초하여 미디어 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신한다.

단계 103: 프록시 서버는 제1 라이브 방송룸 요청 메시지에 기초하여 제1 클라이언트의 역할을 결정하고, 제2 라이브 방송룸 요청 메시지에 기초하여 제2 클라이언트의 역할을 결정한다.

구체적으로, 단계 103은 전술한 "구현예 A"에서 구현될 수 있다.

또한, 가능한 구현예에서, 단일의 마스터 사용자가 있는 기술적 시나리오에서, 프록시 서버가 라이브 방송룸 요청 메시지(예를 들어, 제2 라이브 방송룸 요청 메시지)를 수신할 때마다, 프록시 서버는 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 마스터 사용자 역할을 하는 클라이언트가 라이브 방송룸에 있는지 여부를 결정한다. 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 마스터 사용자 역할을 하는 클라이언트가 라이브 방송룸에 있으면, 프록시 서버는 라이브 방송룸 요청 메시지를 송신하는 클라이언트(예를 들어, 제2 클라이언트)의 역할이 슬레이브 사용자(slave user)인 것으로 결정한다. 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 마스터 사용자 역할을 하는 클라이언트가 라이브 방송룸에 있지 않으면, 프록시 서버는 클라이언트의 역할이 마스터 사용자(master user)인 것으로 결정한다.

다른 가능한 구현예에서, 복수의 마스터 사용자가 있는, 예를 들어, 하나의 주-마스터 사용자와 적어도 하나의 부-마스터 사용자가 있는, 기술적 시나리오에서, 단계 103는 구체적으로, 프록시 서버가 라이브 방송룸 요청 메시지 (예를 들어, 제2 라이브 방송룸 요청 메시지)를 수신할 때마다, 프록시 서버는 현재의 라이브 방송룸에서 마스터 사용자의 역할을 하고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하는지 여부를 결정하는 것을 포함하며, 여기서 미리 정해진 상한치는 2보다 크거나 같다. 수량이 미리 정해진 상한치에 도달하면, 프록시 서버는 라이브 방송룸 요청 메시지를 송신하는 클라이언트(예를 들어, 제2 클라이언트)의 역할이 슬레이브 사용자인 것으로 결정한다. 수량이 미리 정해진 상한치에 도달하지 않고 수량이 0이 아니면, 프록시 서버는 클라이언트의 역할이 부-마스터 사용자(secondary-master user)인 것으로 결정한다. 수량이 미리 설정된 상한에 도달하지 않고 수량이 0이 아닌 경우 프록시 서버는 클라이언트의 역할이 보조 마스터 사용자 (보조 마스터 사용자)라고 결정한다. 수량이 0이면, 프록시 서버는 클라이언트의 역할이 주-마스터 사용자(main-master user)인 것으로 결정한다.

구체적으로, 단계 103는 "구현예 B"로서 구현될 수 있으며, 구체적인 구현예는 "구현예 A"의 전술한 구체적인 구현예에 유사하다. 단일의 마스터 사용자가 있는 기술적 시나리오에서, "구현예 A"와 비교하여, 유일한 차이는, 마스터 사용자 역할을 하고 프록시 서버를 통해 라이브 방송룸에 진입하는 클라이언트가 라이브 방송룸에 있는지 여부가 결정된다는 것이다. 복수의 마스터 사용자가 있는 기술적 시나리오에서, "구현예 A"와 비교하여, 유일한 차이는, 라이브 방송룸에서 마스터 사용자 역할을 하고 프록시 서버를 통해 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하는지 여부가 결정된다는 것이다.

또한, 방법은 다음을 더 포함한다: 프록시 서버는 제1 라이브 미디어 스트림을 화상 그룹(group of picture, GOP)으로 캐싱한다. GOP는 2개의 I 프레임 사이의 화상 시퀀스를 말할 수 있다. I 프레임(frame)은 인트라 화상(intra picture)으로도 또한 지칭되고, 일반적으로 동영상 전문가 그룹(moving picture experts group, MPEG) 기술 처리를 통해 획득되는 각각의 GOP의 첫 번째 프레임을 말한다. 또한, MPEG 기술 처리는, 다른 화상을 참조하지 않고 랜덤 액세스에 대한 참조로서 I 프레임이 사용될 수 있도록, 비디오 화상을 적절히 압축하는 것을 포함한다.

선택사항으로서, 프록시 서버는 3개의 GOP를 로컬로 캐시하고, 각각의 GOP의 지속시간은 5 초이다.

단계 104: 제1 클라이언트의 역할이 마스터 사용자이고 제2 클라이언트의 역할은 슬레이브 사용자임을 결정하는 경우, 프록시 서버는 제1 라이브 미디어 스트림만을 프록시 클라이언트로 송신하여, 프록시 클라이언트가 제1 라이브 미디어 스트림을 제1 클라이언트 및 제2 클라이언트로 송신하도록 한다.

구체적으로, 제1, 프록시 서버는 단계 101에서 제1 라이브 방송룸 요청 메시지를 수신하고, 단계 102에서 제1 라이브 미디어 스트림을 수신하고, 단계 103에서 제1 클라이언트의 역할을 마스터 사용자로 결정한다. 제1 클라이언트의 역할은 마스터 사용자이므로, 프록시 서버는 단계 104에서 제1 클라이언트의 라이브 미디어 스트림(즉, 제1 라이브 미디어 스트림)을 프록시 클라이언트로 송신한다. 이에 상응하여, 프록시 클라이언트는 제1 라이브 미디어 스트림을 제1 클라이언트로 송신한다. 그 다음, 프록시 서버는 단계 101에서 제2 라이브 방송룸 요청 메시지를 수신하고, 단계 102에서 제2 라이브 미디어 스트림을 수신하고, 단계 103에서 제2 클라이언트의 역할을 슬레이브 사용자로 결정한다. 제2 클라이언트의 역할이 슬레이브 사용자이고 제2 클라이언트와 제1 클라이언트는 동일한 프록시 클라이언트에 대응하므로, 프록시 서버는 제2 클라이언트의 미디어 스트림(즉, 제2 라이브 미디어 스트림)을 프록시 클라이언트로 송신하지 않는다. 이에 상응하여, 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신한 후, 프록시 클라이언트는 제1 라이브 미디어 스트림을 제1 클라이언트로 송신할 뿐만 아니라, 제1 라이브 미디어 스트림을 복제하고, 복제된 제1 라이브 미디어 스트림을 제2 클라이언트로 송신한다. 라이브 방송룸에 더 많은 클라이언트가 있으면, 프록시 클라이언트는 제1 라이브 미디어 스트림의 복수의 복사본을 만들고, 제1 라이브 미디어 스트림의 복사본을 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 클라이언트로 송신한다는 것을 이해할 수 있다.

복수의 마스터 사용자가 있는 기술적 시나리오에서, 제1 클라이언트의 역할은 구체적으로 주-마스터 사용자일 수 있고, 제2 클라이언트는 슬레이브 사용자 또는 부-마스터 사용자일 수 있음에 유의해야 한다. 제1 클라이언트가 주-마스터 사용자인 것으로 결정하는 경우, 제2 클라이언트의 역할이 슬레이브 사용자 또는 부-마스터 사용자인지 여부에 무관하게, 프록시 서버는 제1 클라이언트가 획득하기 위해 요청하는 제1 라이브 미디어 스트림만을 프록시 클라이언트로 송신한다.

또한, 프록시 서버가 복수의 클라이언트에 대응하고, 클라이언트의 역할이 전술한 "구현예 B"에서 결정되면, 프록시 서버는 이에 대응하여 제1 라이브 미디어 스트림을 다른 프록시 클라이언트로 추가로 송신하고, 다른 프록시 클라이언트는 수신되는 제1 라이브 미디어 스트림을 복제하고 수신되는 제1 라이브 미디어 스트림의 복사본을 대응하는 클라이언트로 전달한다.

이 실시예에서, "구현예 A"가 클라이언트의 역할을 결정하는데 사용되는 예시가 다음에서 설명을 위해 사용된다.

본 실시예에서 제공되는 방법에 따르면, 슬레이브 사용자의 역할을 하는 제2 클라이언트가 라이브 미디어 스트림을 획득하는 것을 요청하는 경우, 프록시 클라이언트는, 마스터 사용자의 역할을 하는 제1 클라이언트에 의해 요청되는 로컬로 캐시된 제1 라이브 미디어 스트림만을 제2 클라이언트로 송신할 필요가 있으므로, 프록시 서버는 라이브 미디어 스트림을 프록시 클라이언트으로 다시 송신할 필요가 없고, 프록시 서버는 라이브 미디어 스트림을 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 각각의 클라이언트로 송신할 필요가 없다. 이 방법은 프록시 서버와 프록시 클라이언트 사이에 미디어 스트림을 송신하기 위한 트래픽, 송신 대역폭을 효과적으로 줄이며, 리소스 오버헤드를 줄인다.

또한, 본 실시예는 클라이언트의 역할을 변경하는 프로세스를 추가로 포함한다. 구체적으로, 단일의 마스터 사용자가 있는 기술적 시나리오의 경우, 제1 클라이언트가 마스터 사용자이고, 제2 클라이언트가 슬레이브 사용자인 경우, 방법은 다음을 더 포함한다: 프록시 서버는 프록시 클라이언트에 의해 송신되는 그리고 라이브 방송룸을 나가기 위한 요청 메시지를 수신하고-여기서, 라이브 방송룸을 나가기 위한 요청 메시지는 제1 클라이언트에게 라이브 방송룸을 나갈 것을 요청하는데 사용됨-; 제2 클라이언트를 새로운 마스터 사용자로 결정하는 경우, 프록시 서버는 제2 클라이언트의 역할을 슬레이브 사용자로부터 마스터 사용자로 변경(slave-to-master)하고, 프록시 서버는, 프록시 클라이언트로 송신되는 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 스위칭하여, 프록시 클라이언트는 제2 라이브 미디어 스트림을 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트(제2 클라이언트를 포함)로 송신한다.

또한, 프록시 서버에 의해 프록시 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 프록시 서버에 의해 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 인접한 프레임이다.

마지막 프레임과 첫 번째 프레임이 인접한 프레임임을 보장하기 위해, 프록시 서버가 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 스위칭하기 전에, 이 방법은 미디어 스트림을 정렬하는 단계를 더 포함한다. 미디어 스트림을 정렬하는 단계는, 구체적으로, 다음을 포함한다: 프록시 서버는, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 기초하여, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하고-, 여기서, 제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임임-; 그리고 프록시 서버는, 제1 I 프레임 및 제2 I 프레임에 기초하여, 서로 인접하고 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하고, 제1 스위칭 프레임 및 제2 스위칭 프레임을 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임으로서 각각 사용한다.

또한, 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정한 후, 프록시 서버는, 제1 클라이언트로부터의, 라이브 방송룸을 나가기 위한 요청 메시지를 미디어 서버로 포워딩한다.

이와 유사하게, 복수의 마스터 사용자가 있는 기술적 시나리오에서, 대응하는 클라이언트가 라이브 방송룸을 나가는 프로세스는 다음을 포함한다: 제1 클라이언트가 주-마스터 사용자이고, 제2 클라이언트가 슬레이브 사용자인 경우, 제1 클라이언트는 라이브 방송룸을 나갈 것을 요청하고, 프록시 서버는 라이브 방송룸을 나가기 위한 요청 메시지를 제1 클라이언트로부터 수신하고, 프록시 서버는 제2 클라이언트를 새로운 부-마스터 사용자로 사용할 것을 결정하고, 그리고 제2 클라이언트의 역할을 슬레이브 사용자로부터 부-마스터 사용자로 변경하고; 그리고 프록시 서버는, 미디어 서버에 의해 송신되는 제2 라이브 미디어 스트림을 실시간으로 수신하고, 제2 라이브 미디어 스트림을 GOP로 캐시한다. 이 실시예에서, 부-마스터 사용자로서 서빙하는 클라이언트에 대해, 프록시 서버는 부-마스터 사용자의 제2 라이브 미디어 스트림을 획득하고, 제2 라이브 미디어 스트림을 로컬로 캐시하여, 부-마스터 사용자 역할을 하는 클라이언트가 주-마스터 사용자로 변경되는 경우 제2 라이브 미디어 스트림이 직접 사용될 수 있다. 이는 미디어 스트림 전송 효율을 향상한다.

또한, 선택사항으로, 제1 클라이언트가 주-마스터 사용자이고, 제2 클라이언트가 부-마스터 사용자인 경우, 제1 클라이언트가 라이브 방송룸을 나가는 절차는 다음을 포함한다: 프록시 서버는, 제1 클라이언트로부터, 라이브 방송룸을 나가기 위한 요청 메시지를 수신하고; 제2 클라이언트를 새로운 주-마스터 사용자로 사용할 것으로 결정하는 경우, 프록시 서버는 제2 클라이언트의 역할을 부-마스터 사용자로부터 주-마스터 사용자로 변경(secondary-master to main-master)하고, 그리고 프록시 클라이언트로 송신되는 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 스위칭한다.

미디어 스트림 스위칭 효율을 향상하기 위해, 프록시 서버가 부-마스터 사용자 역할을 하는 새로운 클라이언트를 결정할 때마다, 프록시 서버는 클라이언트의 수신되는 미디어 스트림을 캐시하고, 클라이언트의 수신되는 미디어 스트림 및 현재 주-마스터 사용자 역할을 하는 클라이언트의 미디어 스트림을 정렬하며, 구체적으로, 주-마스터 사용자 역할을 하는 클라이언트의 미디어 스트림 및 부-마스터 사용자 역할을 하는 클라이언트의 캐시된 미디어 스트림에 기초하여, 두 미디어 스트림에 속하는 동일한 비디오 프레임을 식별한다. 예를 들어, 제1 클라이언트로부터, 라이브 방송룸을 나가기 위한 요청 메시지를 수신하기 전에, 프록시 서버는 수신되는 제2 라이브 미디어 스트림을 GOP로 캐시하고; 그리고 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 기초하여, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하며, 여기서 제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임이다. 또한, 제1 클라이언트로부터, 라이브 방송룸을 나가기 위한 요청 메시지를 수신한 후, 프록시 서버는, 제1 I 프레임 및 제2 I 프레임에 기초하여, 인접하고 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정한다. 프록시 서버는, 제2 클라이언트으로 송신되는 제1 라이브 미디어 스트림을, 제1 스위칭 프레임 및 제2 스위칭 프레임에 기초하여 제2 라이브 미디어 스트림으로 스위칭하며, 여기서, 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임은 제1 스위칭 프레임이고, 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 제2 스위칭 프레임이다.

또한, 본 출원의 실시예는 미디어 스트림 송신 방법을 추가로 제공한다. 이 방법은 프록시 클라이언트에 적용될 수 있다. 구체적으로, 도 4에 도시된 바와 같이, 방법은 다음 단계를 포함한다.

단계 201: 프록시 클라이언트는 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제1 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제2 클라이언트에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신한다.

단계 202: 프록시 클라이언트는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신한다.

프록시 클라이언트는 추가적으로, 제1 라이브 방송룸 요청 메시지를 프록시 서버로 포워딩하기 전에 프록시 클라이언트의 식별자를 제1 라이브 방송룸 요청 메시지에 추가할 수 있고, 제2 라이브 방송룸 요청 메시지를 프록시 서버로 포워딩하기 전에 프록시 클라이언트의 식별자를 제2 라이브 방송룸 요청 메시지에 추가할 수 있다. 선택사항으로서, 프록시 클라이언트의 식별자는 프록시 클라이언트의 IP 주소이다.

단계 203: 프록시 클라이언트는 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하며, 여기서, 미디어 서버에 의해 프록시 서버를 통해 제1 클라이언트로 전송되는 제1 라이브 미디어 스트림은 미디어 스트림이고, 제1 클라이언트의 역할은 마스터 사용자이고, 제2 클라이언트의 역할은 슬레이브 사용자이다.

단계 204: 프록시 클라이언트는 제1 라이브 미디어 스트림을 제1 클라이언트 및 제2 클라이언트로 송신한다.

프록시 클라이언트가 제1 라이브 미디어 스트림을 송신하기 전에, 방법은 다음을 더 포함한다: 프록시 클라이언트는 제1 라이브 미디어 스트림을 GOP로 캐시하고, 제1 라이브 미디어 스트림의 타임스탬프를 조정한다.

구체적으로, 제1, 프록시 클라이언트는 단계 201에서 제1 클라이언트의 제1 라이브 방송룸 요청 메시지를 수신하고, 단계 202에서 제1 라이브 방송룸 요청 메시지를 프록시 서버로 포워딩한다. 프록시 서버는 제1 클라이언트를 마스터 사용자로 결정하므로, 프록시 클라이언트는 단계 203에서 제1 클라이언트(즉, 제1 라이브 미디어 스트림)의 라이브 미디어 스트림을 수신하고, 단계 204에서 제1 라이브 미디어 스트림을 제1 클라이언트로 송신한다.

그 다음, 프록시 클라이언트는 단계 201에서 제2 클라이언트의 제2 라이브 방송룸 요청 메시지를 수신하고, 단계 202에서 제2 라이브 방송룸 요청 메시지를 프록시 서버로 포워딩한다. 프록시 서버는 제2 클라이언트를 슬레이브 사용자로 결정하므로, 프록시 클라이언트는 제2 클라이언트의 라이브 미디어 스트림(즉, 제2 라이브 미디어 스트림)을 수신하지 않고, 단계 204를 직접 수행하여 제1 라이브 미디어 스트림을 복제하고 복제된 제1 라이브 미디어 스트림을 제2 클라이언트로 송신한다. 제1 라이브 미디어 스트림을 복제하고 복제된 제1 라이브 미디어 스트림을 제2 클라이언트로 송신하는 경우, 프록시 클라이언트는 제1 라이브 미디어 스트림의 타임스탬프를 추가적으로 조정하여, 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림은, 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프가 0임을, 그리고 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 충족하도록 한다. "연속적"은 제1 라이브 미디어 스트림의 인접한 프레임의 시간 길이가 동일함을 의미하며, 여기서 시간 길이는 프레임 레이트 f의 역수이다.

또한, 방법은, 제1 클라이언트가 라이브 방송룸을 나가는 경우, 제1 클라이언트로부터의, 라이브 방송룸을 나가기 위한 요청 메시지를 프록시 클라이언트 포워딩하는 관련 절차를 포함하며, 이는 구체적으로 다음을 포함한다: 프록시 클라이언트는 제1 클라이언트로부터, 라이브 방송룸을 나가기 위한 요청 메시지를 수신하고, 라이브 방송룸을 나가기 위한 요청 메시지를 프록시 서버로 송신하고; 그리고 라이브 방송룸을 나가기 위한 요청 메시지에 기초하여 프록시 서버에 의해 송신되는 라이브 방송룸을 나가기 위한 응답 메시지를 수신하고, 라이브 방송룸을 나가기 위한 응답 메시지를 제1 클라이언트로 송신한다.

방법은 다음을 더 포함한다: 프록시 클라이언트는 제1 라이브 방송룸 요청 메시지를 수신하는 경우 제1 클라이언트의 역할을 작동(working)으로 마킹하고; 프록시 클라이언트는 제2 라이브 방송룸 요청 메시지를 수신하는 경우 제2 클라이언트의 역할을 작동으로 마킹하고; 그리고 프록시 클라이언트는 제1 클라이언트에 의해 송신되는, 라이브 방송룸을 나가기 위한 요청 메시지를 수신하는 경우 제1 클라이언트의 역할을 이탈(exiting)로 마킹한다. 또한, 프록시 클라이언트는 제1 클라이언트의 역할 표시를 "라이브-방송-룸 사용자 상관 관계 테이블"에 업데이트한다.

또한, 제1 클라이언트가 라이브 방송룸을 나갈 것을 요청하는 경우, 방법은 다음을 더 포함한다: 프록시 클라이언트는 프록시 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신하며-여기서, 제2 라이브 미디어 스트림은 미디어 서버에 의해 프록시 클라이언트를 통해 제2 클라이언트로 송신되는 미디어 스트림이고, 제2 클라이언트는 슬레이브 사용자로부터 마스터 사용자로 역할이 변경되는 클라이언트임-; 및 프록시 클라이언트는 제2 라이브 미디어 스트림을 제2 클라이언트로 송신한다.

구체적으로, 프록시 클라이언트가 제2 라이브 미디어 스트림을 제2 클라이언트로 송신하기 전에, 방법은 다음을 더 포함한다: 프록시 클라이언트는 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임 및 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 충족하도록 한다. 또한, 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 인접한 프레임이다.

또한, 프록시 클라이언트가 라이브 방송룸 내의 클라이언트(예를 들어, 제2 클라이언트)의 라이브 미디어 스트림의 타임스탬프를 조정하는 프로세스는, 공식

에 따라 미디어 스트림의 타임스탬프를 조정하는 것을 포함하며, 여기서, y는 조정 후의 타임스탬프를 나타내고, x 조정 전의 타임스탬프를 나타내고,

는 시간 차이를 나타낸다.

미디어 스트림이 클라이언트가 라이브 방송룸에 진입한 후 수신되는 라이브 미디어 스트림의 첫 번째 채널이면, 예를 들어, 단계 204에서, 제1 라이브 미디어 스트림이 제2 클라이언트가 라이브 방송룸에 진입한 후 수신되는 라이브 미디어 스트림의 첫 번째 채널이면, 프록시 서버는 미디어 스트림의 타임스탬프를 공식에 따라 조정하여, 조정된 타임스탬프가 다음 제약 조건을 충족하도록 한다.

1. 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프는 0이다.

2. 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 라이브 미디어 스트림의 인접한 프레임의 타임스탬프는 연속적이며, 즉, 송신되는 라이브 비디오 스트림의 인접한 프레임의 시간 길이는 동일하고, 시간 길이는 라이브 비디오 스트림의 프레임 레이트 f의 역수이다.

라이브 미디어 스트림은 제2 클라이언트가 라이브 방송룸에 진입한 후 수신되는 라이브 미디어 스트림의 첫 번째 채널이므로,

는 프록시 클라이언트에 의해 제2 클라이언트로 송신되는 라이브 미디어 스트림의 첫 번째 프레임의, 조정 전의, 타임스탬프의 반대 수(opposite number)를 나타낸다.

예를 들어, 하나의 마스터 사용자 및 복수의 슬레이브 사용자가 있는 시나리오에서, 프록시 클라이언트에 의해 캐시된 제1 라이브 미디어 스트림의 GOP의 시간 길이는 5 초이고, 3개의 GOP가 로컬로 캐시되고, 3개의 GOP의 컨텐츠이 실시간으로 업데이트됨을 가정한다. 제1 클라이언트(간단히 클라이언트 C1으로 지칭함)가 라이브 방송룸에 처음 진입하는 클라이언트이면, 0 초에서 클라이언트 C1의 역할은 마스터 사용자이고, 클라이언트 C1은 60초에 이를 때까지 라이브 방송룸에서 제1 라이브 미디어 스트림을 연속적으로 시청한다. 이 경우, 프록시 클라이언트에 의해 로컬로 캐시된 비디오 미디어 스트림의 3개의 GOP는 다음과 같다: 45초로부터 50초까지의 미디어 컨텐츠, 50초로부터 55초까지의 미디어 컨텐츠, 및 55초로부터 60초까지의 미디어 컨텐츠. 3개의 GOP는 미디어 서버에 의해 클라이언트 C1으로 프록시 서버를 통해 송신되는 미디어 스트림의 세그먼트이고, 각각의 대응하여 송신되는 프레임의 타임스탬프는 클라이언트 C1의 상대 시간이다.

제2 클라이언트(간단히 클라이언트 C2로 지칭함)는 60초에 라이브 방송룸에 진입하고, 클라이언트 C2의 역할은 슬레이브 사용자이다. 프록시 클라이언트는, 클라이언트 C1으로 송신되는 그리고 로컬로 캐시된 최근 제1 라이브 미디어 스트림을 클라이언트 C2로 송신해야 한다. 이 경우, 60초에 가장 가까운 라이브 미디어 스트림은 세번째 GOP 세그먼트의 미디어 컨텐츠, 즉, 캐시된 55초로부터 60초까지의 미디어 컨텐츠이다. 55초는 미디어 서버에 의해 송신되는 프레임의 타임스탬프이고, 따라서, 조정되어야 하는 시간 차이는

이며, 즉, 프록시 클라이언트는, 전술한 제약 조건을 충족하기 위해, 제1 라이브 미디어 스트림을 클라이언트 C2로 송신하는 경우 타임스탬프를 55 초 줄여야 한다. 이러한 방식으로, 라이브 방송룸에 진입하는 각각의 클라이언트 C2는 대기할 필요 없이 0초에 라이브 방송 비디오를 시청할 수 있고, 라이브 방송룸 내의 클라이언트 C1 및 클라이언트 C2는 "동기적으로" 비디오를 시청할 수 있다.

또한, 방법은 다음을 더 포함한다: 클라이언트 C1이 라이브 방송룸을 나갈 것을 요청하는 경우, 프록시 서버는 클라이언트 C2로 송신되는 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 스위칭해야 한다. 이 경우, 클라이언트 C2의 역할은 마스터 사용자로 변경되고, 제2 라이브 미디어 스트림은 미디어 서버에 의해 클라이언트 C2로 송신되는 미디어 스트림이다. 이에 상응하여, 프록시 클라이언트는 미디어 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신하고, 제2 라이브 미디어 스트림의 타임스탬프를 조정한다.

예를 들어, 클라이언트 C1이 비디오 재생의 120초에 라이브 방송룸을 나가면, 프록시 서버는 클라이언트 C2의 역할을 마스터 사용자로 변경할 것을 결정한다. 그 다음, 프록시 서버는 클라이언트 C2의 제2 라이브 미디어 스트림을 프록시 클라이언트로 송신한다. 프록시 클라이언트는 제2 라이브 미디어 스트림을 수신하고 캐시한다. 120초에서, 프록시 클라이언트에 의해 로컬로 캐시된 3개의 GOP의 미디어 컨텐츠는 다음과 같음을 가정한다: 105초로부터 110초까지의 미디어 컨텐츠, 110초로부터 115초까지의 미디어 컨텐츠, 및 115초로부터 120초까지의 미디어 컨텐츠. 10초가 지난 후, 프록시 클라이언트에 의해 캐시된 최근 GOP 1는 115초로부터 120초까지의 비디오 컨텐츠이고, GOP 1의 프레임의 타임스탬프는 클라이언트 C1의 상대 시간이다. 클라이언트 C1이 라이브 방송룸을 나간 후, 프록시 클라이언트는, GOP 2 및 GOP 3, 즉, 0초로부터 5초까지의 미디어 컨텐츠 및 5초로부터 10초까지의 미디어 컨텐츠를 로컬로 캐시한다. 2개의 GOP의 타임스탬프는 클라이언트 C2의 상대 시간이다. 따라서, 조정된 시간 차이는

로 계산되며, 즉, 프록시 클라이언트에 의해 새로운 마스터 사용자로서 서빙하는 클라이언트 C2로 송신되는 제2 라이브 미디어 스트림의 프레임의 타임스탬프는 65초 증가되어야 한다.

결론적으로, 프록시 클라이언트가 타임스탬프를 조정하는 경우, 시간 차이를 계산하는 2가지 경우가 있을 수 있다. 세부 사항은 다음과 같다.

사례 1: 클라이언트가 미디어 스트림을 수신하지 않았으면, 즉, 현재의 미디어 스트림이 클라이언트가 라이브 방송룸에 진입한 후 클라이언트에 의해 수신되는 미디어 스트림의 첫 번째 채널이면, 시간 차이는

이며, 여기서, t2는 프록시 클라이언트에 의해 프록시 서버로부터 수신되는 그리고 클라이언트로 포워딩되어야 하는 미디어 스트림의 첫 번째 프레임의 타임스탬프를 나타낸다.

사례 2: 클라이언트 미디어 스트림을 수신하였으면, 즉, 프록시 클라이언트에 의해 클라이언트로 송신되는 미디어 스트림이 이전의 마스터 사용자의 미디어 스트림으로부터 현재의 마스터 사용자의 미디어 스트림으로 스위칭되면, 시간 차이는

이며, 여기서, t2는 미디어 스트림 스위칭 후에 프록시 클라이언트에 의해 클라이언트로 송신되는 미디어 스트림(즉, 현재의 마스터 사용자의 미디어 스트림)의 첫 번째 프레임의 조정 전의 타임스탬프를 나타내고, t1은 미디어 스트림 스위칭 전에 프록시 클라이언트에 의해 클라이언트로 송신되는 미디어 스트림(즉, 이전의 마스터 사용자의 미디어 스트림)의 마지막 프레임의 조정 후의 타임스탬프를 나타낸다. 대응하는 다음 비디오 프레임의 타임스탬프는

이고,

이다. 예를 들어, f = 20 fps이고, 송신되는 비디오 프레임의 시간 길이는 m = 1s/20 = 0.05초, 즉, 50 ms이다.

본 실시예에서 제공되는 방법에 따르면, 프록시 클라이언트 및 프록시 서버가 마스터 사용자로서 서빙하는 클라이언트에 의해 요청되는 라이브 미디어 스트림을 획득하는 경우, 미디어 스트림의 일부 세그먼트는 프록시 클라이언트 내에 로컬로 캐시된다. 다른 클라이언트가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 요청하는 경우, 프록시 클라이언트는 로컬로 캐시된 미디어 스트림을 이러한 클라이언트로 직접 송신하여, 프록시 서버는 라이브 미디어 스트림을 프록시 클라이언트 및 제2 클라이언트로 다시 송신할 필요가 없다. 이 방법에서, 마스터 사용자로서 서빙하는 클라이언트에 의해 요청되은 라이브 미디어 스트림만이 프록시 서버와 프록시 클라이언트 사이에서 송신되며, 달리 말하면, 라이브 미디어 스트림을 전송하기 위한 광역 네트워크 대역폭만이 소비된다. 미디어 서버가 프록시 서버를 통해 라이브 미디어 스트림을 각각의 클라이언트로 송신하는 경우 차지하는 전송 리소스와 비교하여, 이는 미디어 스트림을 송신하기 위한 트래픽을 줄이고, WAN 네트워크 링크 부하를 줄이고, 그리고 리소스 오버헤드를 줄인다.

또한, 프록시 클라이언트가 라이브 미디어 스트림을 라이브 방송룸 내의 모든 클라이언트로 송신하는 경우, 프록시 클라이언트는 라이브 미디어 스트림의 타임스탬프를 또한 조정한다. 예를 들어, 마스터 사용자로서 서빙하는 제1 클라이언트가 라이브 방송룸을 나가는 경우, 프록시 클라이언트는, 원래 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 스위칭하고, 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 프록시 클라이언트가 제2 라이브 미디어 스트림을 제2 클라이언트로 송신하는 경우, 제2 라이브 미디어 스트림은 원래 재생 중인 제1 라이브 미디어 스트림의 미디어 컨텐츠에 끊어지지 않고 연결될 수 있다. 상기 제1 클라이언트의 이탈로 인해 초래되는, 상기 제2 클라이언트에서 시청되는 미디어 컨텐츠에 대한 비디오 정지 또는 다른 영향을 피할 수 있다. 따라서, 이 방법에 따르면, 상기 프록시 클라이언트에 의한 타임스탬프의 조정은 또한 시청에 대한 사용자 경험을 보장한다.

다음은 본 출원의 실시예들에서 제공되는 방법을 구체적으로 설명한다.

실시예 1

이 실시예는 라이브 비디오 미디어 스트림 송신 방법를 제공한다. 이 방법은 도 2에 도시된 비디오 라이브 방송 시스템에 적용될 수 있다. 이 방법은, 프록시 서버가 동일한 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 제1 클라이언트 및 제2 클라이언트에 대해 라이브 미디어 스트림을 제공하는 것을 포함하며, 여기서 라이브 미디어 스트림은 컨텐츠 소스로부터 오고 RDC의 미디어 서버에 의해 포워딩된다. 또한, 도 5a 내지 도 5d에 도시된 바와 같이, 이 방법은, S1 내지 S39의 총 39개의 단계(step, S)를 포함한다.

S1 내지 S18은 제1 클라이언트(이하 "클라이언트 C1"로 지칭됨)가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 획득하는 프로세스이다. S19 내지 S39은 제2 클라이언트(이하 "클라이언트 C2"로 지칭됨)가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 획득하는 프로세스이다.

구체적으로, 클라이언트 C1이 라이브 방송룸에 진입하고 라이브 미디어 스트림을 획득하는 프로세스는 다음 단계를 포함한다.

S1: 컨텐츠 소스는 제1 라이브 미디어 스트림을 EDC의 미디어 서버로 송신한다.

S2: EDC의 미디어 서버는 제1 라이브 미디어 스트림을 수신하고, 제1 라이브 미디어 스트림을 하위-레벨 RDC의 미디어 서버로 송신한다. 제1 라이브 미디어 스트림이 송신되기 전에, 방법은 EDC의 웹 서버가 하위-레벨 RDC의 미디어 서버를 인증하는 단계를 더 포함하고, 인증이 성공하는 경우에만 RDC의 미디어 서버는 제1 라이브 미디어 스트림을 RDC의 미디어 서버로 송신한다.

선택사항으로서, S2는, 프록시 서버(proxy server)가, 제1 라이브 미디어 스트림의 서비스 피처에 기초하여, 프록시 서버에 의해 서빙되는 클라이언트에 대응하는 전송 프로토콜을 식별하는 것을 더 포함한다. 서비스 피처는 웹 서버의 IP 주소 및 포트 번호를 포함한다. 예를 들어, 하이퍼텍스트 전송 프로토콜(Hyper Text Transfer Protocol, HTTP)의 경우, 구성될 수 있는 서비스 피처는 웹 서버의 IP 주소 및 포트 번호를 포함한다. 또한, 프록시 서버는, HTTP 프로토콜에 대응하는 전송 프로토콜은 미디어 스트림 전송을 위한 전송 제어 프로토콜(Transmission Control Protocol, TCP)인 것으로 추가로 결정할 수 있다.

S3: 클라이언트 C1은 클라이언트 C1에 의해 액세스될 수 있는 미디어 서버에 대한 요청 메시지를 RDC의 웹 서버로 송신한다. 또한, 요청 메시지는 클라이언트 C1의 사용자 이름 및 IP 주소, 라이브 방송룸의 이름, 및 클라이언트 C1이 성공적으로 인증된 후 획득되는 키 토큰과 같은 정보를 포함하며, 여기서 IP 주소는 클라이언트 C1의 위치를 결정하는데 사용된다. 구체적으로, 클라이언트 C1은 요청 메시지를 프록시 클라이언트로 송신하고, 프록시 클라이언트는 요청 메시지를 수신한 후 요청 메시지를 프록시 서버로 송신하고, 프록시 서버는 요청 메시지를 RDC의 웹 서버로 포워딩한다.

S4: RDC의 웹 서버는 요청 메시지를 수신하고, 클라이언트 C1에 의해 액세스될 수 있는 미디어 서버에 대한 응답 메시지를 클라이언트 C1으로 송신하며, 여기서, 응답 메시지는 클라이언트 C1에 의해 액세스될 수 있는 미디어 서버를 클라이언트 C1에게 통보하는데 사용된다. 구체적으로, 웹 서버는, 요청 메시지에 기초하여, 클라이언트 C1에 대해 미디어 스트림 서비스를 제공할 수 있는 타깃 미디어 서버를 결정하고-여기서, 타깃 미디어 서버는 RDC의 복수의 미디어 서버 중 하나임-; 그리고 다음으로 응답 메시지를 클라이언트 C1으로 송신하며, 여기서, 응답 메시지는, 예를 들어, 타깃 미디어 서버의 균일한 리소스 로케이터(Uniform Resource Locator, URL) 정보, IP 주소, 및 포트 번호와 같은, 타깃 미디어 서버의 관련 정보를 포함한다.

구체적으로, RDC의 웹 서버는 응답 메시지를 프록시 서버로 송신하고, 프록시 서버는 응답 메시지를 프록시 클라이언트로 송신하고, 프록시 클라이언트는 응답 메시지를 클라이언트 C1으로 포워딩한다.

웹 서버는, 클라이언트 C1에 의해 송신되는, 클라이언트 C1에 의해 액세스될 수 있는 미디어 서버에 대한 요청 메시지에서 전달되는 IP 주소에 기초하여, 클라이언트 C1의 위치를 결정하고; 그리고 위치 정보에 기초하여 클라이언트 C1에 가장 가까운 미디어 서버를 타깃 미디어 서버로 선택한다.

S5: 응답 메시지는, 예를 들어, 타깃 미디어 서버의 URL 정보, IP 주소, 및 포트 번호와 같은, 타깃 미디어 서버의 관련 정보를 전달한다. 따라서, 응답 메시지를 포워딩하는 경우, 프록시 서버 및 프록시 클라이언트는 클라이언트 C1에 의해 액세스될 수 있는 미디어 서버에 관한 정보를 획득하며, 즉, 프록시 서버 및 프록시 클라이언트는 타깃 미디어 서버의 관련 정보를 획득한다.

S6: 클라이언트 C1은 라이브 방송룸에 진입하는 것을 요청하기 위한 제1 라이브 방송룸 요청 메시지를 프록시 클라이언트로 송신하며, 여기서 제1 라이브 방송룸 요청 메시지는 클라이언트 C1이 라이브 방송룸에 진입할 것을 요청한다는 것을 나타낸다. 제1 라이브 방송룸 요청 메시지는, 클라이언트 C1의 사용자 이름, IP 주소, 및 포트 번호, 라이브 방송룸의 이름, 인증이 성공한 후 획득되는 토큰, 등을 포함한다.

S7: 프록시 클라이언트는 클라이언트 C1에 의해 송신되는 제1 라이브 방송룸 요청 메시지를 수신하고, 클라이언트 C1의 역할을 작동(working) 상태로 설정한다. 프록시 클라이언트는 "라이브-방송-룸 사용자 상관 관계 테이블"을 또한 구성하고, 클라이언트 C1에 관한 엔트리를 라이브-방송-룸 사용자 상관 관계 테이블에 추가한다. 구체적으로, 엔트리의 내용은, 클라이언트 C1의 IP 주소, 포트 번호, 사용자 상태, 및 사용자 이름, RDC 내의 선택된 타깃 미디어 서버의 IP 주소 및 포트 번호, 및 라이브 방송룸의 이름과 같은 정보를 포함한다. 클라이언트 C1의 사용자 상태는 작동 상태이다. 클라이언트 C1의 IP 주소는 데이터베이스에 저장된 기본 키(primary key)일 수 있다.

또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 프록시 클라이언트의 식별자를 제1 라이브 방송룸 요청 메시지에 추가하며, 여기서 프록시 클라이언트의식별자는 프록시 클라이언트의 IP 주소, 포트 번호, 등이다.

S8: 프록시 클라이언트는 프록시 클라이언트의 식별자가 추가된 제1 라이브 방송룸 요청 메시지를 프록시 서버로 송신하며, 여기서, 수정된 제1 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자, 클라이언트 C1의 사용자 이름, 라이브 방송룸의 이름, 및 인증이 성공한 후 획득되는 토큰과 같은 정보를 포함한다.

S9: 프록시 서버는 수정된 제1 라이브 방송룸 요청 메시지를 수신하고, 제1 라이브 방송룸 요청 메시지에 기초하여 클라이언트 C1의 역할을 결정하고, 그리고 라이브-방송-룸 사용자 상관 관계 테이블을 리프레시한다. 구체적으로, 클라이언트 C1의 역할을 결정하는 단계는 다음을 포함한다: 제1 라이브 방송룸 요청 메시지를 수신하는 경우, 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 마스터 사용자 역할을 하는 클라이언트가 있는지 여부를 결정하는 단계; 및 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 마스터 사용자 역할을 하는 클라이언트가 있으면, 클라이언트 C1이 슬레이브 사용자인 것으로 결정하는 단계, 또는 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 마스터 사용자 역할을 하는 클라이언트가 없으면, 클라이언트 C1이 마스터 사용자인 것으로 결정하는 단계. 이 실시예에서, 클라이언트 C1은 프록시 클라이언트를 통해 라이브 방송룸에 처음 진입하는 사용자이므로, 마스터 사용자가 없다. 따라서, 제1 라이브 방송룸 요청 메시지를 수신하는 경우, 프록시 서버는 클라이언트 C1의 역할이 마스터 사용자인 것으로 결정하고, 클라이언트 C1의 역할을 마스터 사용자로 식별한다.

또한, 방법은 다음을 더 포함한다: 클라이언트 C1의 역할을 결정한 후, 프록시 서버는 "라이브-방송-룸 사용자 상관 관계 테이블"을 리프레시하고, 클라이언트 C1의 역할을 마스터 사용자로 마킹한다. 당연히, 프록시 서버는, 동일한 프록시 클라이언트를 통해 송신되는 수신되는 라이브 방송룸 요청 메시지에 기초하여 "라이브-방송-룸 사용자 상관 관계 테이블"을 실시간으로 업데이트하여, 라이브 방송 내의 각각의 클라이언트의 역할과 상태를 실시간으로 기록할 수 있다. 선택사항으로서, 프록시 서버는 프록시 클라이언트의 레코드 식별자(IP 주소 및 포트 번호)를 "라이브-방송-룸 사용자 상관 관계 테이블"에 추가로 기록할 수 있다.

이 실시예에서, 라이브 방송룸에서 마스터 사용자의 역할을 하는 클라이언트의 수량은 1로 설정된다. 달리 말하면, 라이브 방송룸에 하나의 마스터 사용자만이 있으며 다른 클라이언트는 슬레이브 사용자이다. 이 기술적 시나리오는 단일의 마스터 사용자가 있는 시나리오로 지칭될 수 있다.

S10: 프록시 서버는 제1 라이브 방송룸 요청 메시지를 RDC의 미디어 서버로 송신한다. 제1 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자를 포함하지 않는다.

단계 S9는 단계 S10 이전에 수행될 수 있거나 또는 단계 S9는 단계 S10 이후에 수행될 수 있다. 이는 본 실시예에서 엄격하게 제한되지 않는다.

S11: RDC의 미디어 서버는 제1 라이브 방송룸 요청 메시지를 수신하고, 제1 라이브 방송룸 응답 메시지를 클라이언트 C1으로 송신한다. 제1 라이브 방송룸 응답 메시지는 클라이언트 C1이 라이브 방송룸에 성공적으로 진입하였음을 클라이언트 C1에게 통보하는데 사용된다. 구체적으로, 제1, 미디어 서버는 제1 라이브 방송룸 응답 메시지를 프록시 서버를 통해 프록시 클라이언트로 포워딩하고, 그런 다음 프록시 클라이언트는 제1 라이브 방송룸 응답 메시지를 클라이언트 C1으로 포워딩한다.

S12: 클라이언트 C1은 제1 미디어 요청 메시지를 프록시 클라이언트로 송신하며, 여기서 제1 미디어 요청 메시지는 미디어 서버로부터 제1 라이브 미디어 스트림을 획득하는 것을 요청하는데 사용된다. 선택사항으로서, 제1 미디어 요청 메시지는 클라이언트 C1의 제1 식별자를 전달하며, 여기서 제1 식별자는 클라이언트 C1을 고유하게 식별하는데 사용된다. 이 실시예에서, 제1 식별자는 클라이언트 C1의 IP 주소, 사용자 이름, 등을 포함한다.

구체적으로, 제1 미디어 요청 메시지를 수신한 후, 프록시 클라이언트는 제1 미디어 요청 메시지를 프록시 서버로 포워딩하고, 프록시 서버는 제1 미디어 요청 메시지를 RDC의 미디어 서버로 송신한다.

S13: 제1 미디어 요청 메시지를 수신한 후, 미디어 서버는 제1 미디어 응답 메시지를 클라이언트 C1으로 송신한다. 제1 미디어 응답 메시지는 클라이언트 C1이 제1 라이브 미디어 스트림을 획득하도록 허용됨을 클라이언트 C1에게 통보하는데 사용된다. 구체적으로, 미디어 서버는 제1 미디어 응답 메시지를 프록시 서버로 송신하고, 프록시 서버는 제1 미디어 응답 메시지를 프록시 클라이언트로 포워딩하고, 마지막으로 프록시 클라이언트는 제1 미디어 응답 메시지를 클라이언트 C1으로 포워딩한다.

S14: 미디어 서버는 제1 라이브 미디어 스트림을 프록시 서버로 송신한다.

S15: 프록시 서버는, 실시간으로, 미디어 서버에 의해 송신되는 제1 라이브 미디어 스트림을 획득한 다음, 제1 라이브 미디어 스트림을 로컬로 캐시한다. 구체적으로, 프록시 서버는 제1 라이브 미디어 스트림의 세그먼트를 GOP로 로컬로 캐시하며, 예를 들어, 3개의 최근 GOP(t1-t2, t2-t3, 및 t3-t4)의 미디어 스트림 세그먼트를 캐시한다.

S16: 프록시 서버는 제1 라이브 미디어 스트림의 캐시된 세그먼트를 프록시 클라이언트로 송신하여, 프록시 클라이언트는 제1 라이브 미디어 스트림을 클라이언트 C1으로 송신한다.

S17: 프록시 클라이언트는 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하고, 제1 라이브 미디어 스트림을 GOP로 로컬로 캐시한다. 프록시 클라이언트는 제1 라이브 미디어 스트림의 몇가지 최근 세그먼트만을 캐시한다.

S18: 프록시 클라이언트는 캐시된 제1 라이브 미디어 스트림을 클라이언트 C1으로 송신한다.

선택적으로 프록시 클라이언트가 클라이언트 C1에 첫 번째 라이브 미디어 스트림을 보내는 프로세스에서 프록시 클라이언트는 첫 번째 라이브 미디어 스트림의 타임 스탬프를 추가로 조정하여 조정된 타임 스탬프가 첫 번째 프레임의 타임 스탬프를 충족하도록해야 한다. 프록시 클라이언트에 의해 클라이언트 C1에 전송되는 첫 번째 라이브 미디어 스트림의 시간은 0이고 클라이언트 C1에 전송되는 첫 번째 라이브 미디어 스트림의 인접한 프레임의 타임 스탬프는 연속적이다. "연속적"은 클라이언트 C1에 의해 수신되는 제1 라이브 미디어 스트림의 인접한 비디오 프레임의 시간 길이가 동일함을 의미하며, 여기서 시간 길이는 프레임 레이트 f의 역수이다.

다음은 클라이언트 C2가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 획득하는 방법을 설명한다. 구체적으로, 다음 단계가 포함된다.

S19: 클라이언트 C2는 클라이언트 C2에 의해 액세스될 수 있는 미디어 서버에 대한 요청 메시지를 RDC의 웹 서버로 송신하며, 여기서 요청 메시지는 클라이언트 C2의 사용자 이름 및 IP 주소, 라이브 방송룸의 이름, 및 클라이언트 C2이 성공적으로 인증된 후 획득되는 키 토큰과 같은 정보를 포함한다. 구체적으로, 클라이언트 C2는 요청 메시지를 프록시 클라이언트 및 프록시 서버를 통해 RDC의 웹 서버로 포워딩한다. 포워딩 프로세스에서, 프록시 클라이언트 및 프록시 서버는 모두 요청 메시지에서 전달되는 정보를 획득한다.

S20: RDC의 웹 서버는 요청 메시지를 수신하고, 응답 메시지를 클라이언트 C2로 송신하며, 여기서 응답 메시지는 클라이언트 C2에 의해 액세스될 수 있는 미디어 서버를 클라이언트 C2에게 통보하는데 사용된다. 이는 전술한 단계 S4와 동일하다. 웹 서버는 클라이언트 C2에 대해 미디어 스트림 서비스를 제공할 복수의 미디어 서버 중 하나를 선택하고, 선택된 미디어 서버의 관련 정보를 응답 메시지를 통해 프록시 서버 및 프록시 클라이언트로 송신한다. 예를 들어, 선택된 미디어 서버의 관련 정보는 선택된 미디어 서버의 URL 정보, IP 주소, 및 포트 번호를 포함한다.

S21: 응답 메시지를 포워딩하는 프로세스에서, 프록시 클라이언트 및 프록시 서버는 요청 메시지에서 전달되는 정보를 획득하며, 여기서 정보는 클라이언트 C2에 의해 액세스될 수 있는 미디어 서버에 관한 정보를 포함한다. 예를 들어, 정보는 미디어 서버의 IP 주소 및 포트 번호를 포함한다.

S22: 클라이언트 C2는 라이브 방송룸에 진입하는 것을 요청하기 위한 제2 라이브 방송룸 요청 메시지를 프록시 클라이언트로 송신하며, 여기서 제2 라이브 방송룸 요청 메시지는 클라이언트 C2가 라이브 방송룸에 진입할 것을 요청한다는 것을 나타낸다. 제2 라이브 방송룸 요청 메시지는, 클라이언트 C2의 사용자 이름, IP 주소, 및 포트 번호, 라이브 방송룸의 이름, 인증이 성공한 후 획득되는 토큰, 등을 포함한다.

S23: 프록시 클라이언트는 클라이언트 C2에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신하고, 클라이언트 C2의 역할을 작동(working) 상태로 설정한다. 프록시 클라이언트는 또한 클라이언트 C2에 관한 엔트리를 "라이브-방송-룸 사용자 상관 관계 테이블"에 추가한다. 구체적으로, 엔트리의 내용은, 클라이언트 C2의 IP 주소, 포트 번호, 사용자 상태, 및 사용자 이름, RDC 내의 선택된 타깃 미디어 서버의 IP 주소 및 포트 번호, 및 라이브 방송룸의 이름과 같은 정보를 포함한다. 클라이언트 C2의 사용자 상태는 작동 상태이다. 클라이언트 C2의 IP 주소는 데이터베이스에 저장된 기본 키(primary key)일 수 있다.

또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 프록시 클라이언트의 식별자를 제2 라이브 방송룸 요청 메시지에 추가하며, 여기서 프록시 클라이언트의식별자는 프록시 클라이언트의 IP 주소, 포트 번호, 등이다.

S24: 프록시 클라이언트는 프록시 클라이언트의 식별자가 추가된 제2 라이브 방송룸 요청 메시지를 프록시 서버로 송신한다. 수정된 제2 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자, 클라이언트 C2의 사용자 이름, 라이브 방송룸의 이름, 및 인증이 성공한 후 획득되는 토큰과 같은 정보를 포함한다.

S25: 프록시 서버는 프록시 클라이언트에 의해 송신되는 수정된 제2 라이브 방송룸 요청 메시지를 수신하고, 제2 라이브 방송룸 요청 메시지에 기초하여 클라이언트 C2의 역할을 결정하고, 그리고 라이브-방송-룸 사용자 상관 관계 테이블을 리프레시한다. 구체적으로, 가능한 구현예는, 제2 라이브 방송룸 요청 메시지를 수신한 후, 프록시 서버는 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 라이브 방송룸에서 마스터 사용자 역할을 하는 클라이언트가 라이브 방송룸에 있는지 여부를 결정하고; 그리고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 중에 라이브 방송룸에서 마스터 사용자 역할을 하는 클라이언트가 라이브 방송룸에 있으면, 프록시 서버는 클라이언트 C2의 역할이 슬레이브 사용자인 것으로 결정한다. 이 실시예에서, 라이브 방송룸에서 역할이 현재 마스터 사용자인 클라이언트 C1이 있고, 따라서 클라이언트 C2의 역할은 슬레이브 사용자로 결정된다.

또한, S25는, 프록시 서버는 "라이브-방송-룸 사용자 상관 관계 테이블"을 리프레시하고, 클라이언트 C2의 역할을 슬레이브(slave) 사용자로 식별하는 것을 추가로 포함한다. 또한, 방법은 다음을 더 포함한다: 프록시 서버는, 프록시 클라이언트의 식별자, 예를 들어, 프록시 클라이언트의 IP 주소 및 포트 번호를, 클라이언트 C2에 관한 엔트리에 추가한다.

S26: 프록시 서버는 제2 라이브 방송룸 요청 메시지를 RDC의 미디어 서버로 송신한다. 제2 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자를 포함하지 않는다.

S27: 미디어 서버는 제2 라이브 방송룸 요청 메시지를 수신하고, 제2 라이브 방송룸 응답 메시지를 클라이언트 C2로 송신하며, 여기서 제2 라이브 방송룸 응답 메시지는 클라이언트 C2가 라이브 방송룸에 성공적으로 진입하였음을 클라이언트 C2에게 통보하는데 사용된다. 구체적으로, 미디어 서버는 제2 라이브 방송룸 응답 메시지를 프록시 서버 및 프록시 클라이언트로 송신하고, 이후 프록시 클라이언트는 제2 라이브 방송룸 응답 메시지를 클라이언트 C2로 포워딩한다.

S28: 클라이언트 C2는 제2 미디어 요청 메시지를 프록시 클라이언트로 송신하며, 여기서, 제2 미디어 요청 메시지는 미디어 서버로부터 라이브 미디어 스트림을 획득하는 것을 요청하는데 사용된다. 선택사항으로서, 제2 미디어 요청 메시지는 클라이언트 C2의 제2 식별자를 전달하며, 여기서 제2 식별자는 클라이언트 C2을 고유하게 식별하는데 사용된다. 이 실시예에서, 제2 식별자는 클라이언트 C2의 IP 주소, 사용자 이름, 등을 포함한다.

구체적으로, 제2 미디어 요청 메시지를 수신한 후, 프록시 클라이언트는 제2 미디어 요청 메시지를 프록시 서버로 포워딩하고, 프록시 서버는 제2 미디어 요청 메시지를 RDC의 미디어 서버로 송신한다.

S29: 제2 미디어 요청 메시지를 수신한 후, 미디어 서버는 제2 미디어 응답 메시지를 클라이언트 C2로 송신하며, 여기서, 제2 미디어 응답 메시지는 클라이언트 C2가 제1 라이브 미디어 스트림을 획득하도록 허용됨을 클라이언트 C2에게 통보하는데 사용된다. 구체적으로, 미디어 서버는 제2 미디어 응답 메시지를 프록시 서버로 송신하고, 프록시 서버는 제2 미디어 응답 메시지를 프록시 클라이언트로 포워딩하고, 마지막으로 프록시 클라이언트는 제2 미디어 응답 메시지를 클라이언트 C2로 포워딩한다.

S30: 프록시 클라이언트는 로컬로 캐시된 제1 라이브 미디어 스트림을 클라이언트 C2로 송신하고, 그리고 제1 라이브 미디어 스트림을 송신하는 경우 제1 라이브 미디어 스트림의 타임스탬프를 추가로 조정하여, 조정된 타임스탬프는, 프록시 클라이언트에 의해 클라이언트 C2로 송신되는 제1 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프가 0임을, 그리고 클라이언트 C2로 송신되는 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 충족하도록 한다.

S31: 미디어 서버는 제2 라이브 미디어 스트림을 프록시 서버로 송신하며, 여기서, 제2 라이브 미디어 스트림은 클라이언트 C2로 송신되는 미디어 스트림이고, 클라이언트 C2의 역할은 슬레이브 사용자이다.

S32: 제2 라이브 미디어 스트림을 수신한 후, 제2 라이브 미디어 스트림은 슬레이브 사용자로서 서빙하는 클라이언트 C2로 송신되는 미디어 스트림이므로, 프록시 서버는 제2 라이브 미디어 스트림을 캐시하지도 제2 라이브 미디어 스트림을 클라이언트 C2로 포워딩하지도 않는다.

S33: 미디어 서버는 제1 라이브 미디어 스트림을 프록시 서버로 실시간으로 송신한다.

S34: 미디어 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신한 후, 프록시 서버는 제1 라이브 미디어 스트림의 세그먼트를 GOP로 로컬로 캐시한다. 이 실시예에서, 프록시 서버는 3개의 GOP를 로컬로 캐시하고, 더 많거나 더 적은 GOP를 추가로 캐시할 수 있다. 이는 본 실시예에서 제한되지 않는다.

S35: 프록시 서버는 제1 라이브 미디어 스트림을 프록시 클라이언트로 송신한다.

S36: 프록시 클라이언트는 제1 라이브 미디어 스트림을 수신하고, 제1 라이브 미디어 스트림의 세그먼트를 GOP로 로컬로 캐시한다.

S37: 프록시 클라이언트는, "라이브-방송-룸 사용자 상관 관계 테이블" 내의 엔트리의 내용에 기초하여, 마스터 사용자로서 서빙하는 클라이언트의 수량 및 슬레이브 사용자로서 서빙하는 클라이언트의 수량을 결정하고, 제1 라이브 미디어 스트림 세그먼트의 캐시된 세그먼트를 복제하여, 세그먼트를 라이브 방송룸 내의 클라이언트로 송신할 준비를 한다. 이 실시예에서, 현재 라이브 방송룸 내에 클라이언트 C1 및 클라이언트 C2의 두 클라이언트만이 있고, 여기서 클라이언트 C1은 마스터 사용자이고, 클라이언트 C2는 슬레이브 사용자이다. 따라서, 프록시 클라이언트는, 제1 라이브 미디어 스트림의 복사본을 클라이언트 C2로 송신할 준비를 하기 위해, 제1 라이브 미디어 스트림의 하나의 복사본을 만든다.

S38: 프록시 클라이언트는 로컬로 캐시된 제1 라이브 미디어 스트림을 클라이언트 C1으로 송신한다. 또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 클라이언트 C1이 미디어 스트림의 비디오 프레임을 수신하는 시점에 기초하여 제1 라이브 미디어 스트림의 타임스탬프를 조정한다.

S39: 프록시 클라이언트는 로컬로 캐시된 제1 라이브 미디어 스트림을 클라이언트 C2로 송신한다. 또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 클라이언트 C2이 미디어 스트림의 비디오 프레임을 수신하는 시점에 기초하여 제1 라이브 미디어 스트림의 타임스탬프를 조정한다.

또한, 프록시 클라이언트는 라이브 방송룸에 진입하는 사용자에 의해 시청되는 비디오 프레임의 타임스탬프를 조정하여, 라이브 방송룸 내의 클라이언트 C1 및 클라이언트 C2는 제1 라이브 미디어 스트림의 미디어 컨텐츠를 "동기적으로" 시청할 수 있어, 사용자 경험을 개선한다.

본 실시예의 방법에 따르면, 프록시 클라이언트 및 프록시 서버가 마스터 사용자로서 서빙하는 제1 클라이언트에 의해 요청되는 라이브 미디어 스트림을 획득하는 경우, 프록시 클라이언트는 라이브 미디어 스트림의 일부 세그먼트를 로컬로 캐시한다. 제2 클라이언트가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 요청하는 경우, 프록시 클라이언트는 로컬로 캐시된 라이브 미디어 스트림을 제2 클라이언트로 직접 송신하여, 프록시 서버는 라이브 미디어 스트림을 프록시 클라이언트 및 제2 클라이언트로 다시 송신할 필요가 없다. 방법에 따르면, 프록시 서버는 하나의 라이브 미디어 스트림만 프록시 클라이언트 및 상기 제2 클라이언트로 송신하면 되며, 달리 말하면, 하나의 라이브 미디어 스트림을 전송하기 위한 광역 네트워크 대역폭만이 소비된다. 이는 라이브 미디어 스트림을 송신하기 위한 트래픽을 효과적으로 줄일 수 있고, WAN 네트워크 링크 부하를 줄이고, 리소스 오버헤드를 줄인다.

또한, 본 실시예의 방법에 따르면, 클라이언트 C1의 제1 라이브 방송룸 요청 메시지 및 제1 미디어 요청 메시지는 하나의 메시지로 결합될 수 있고, 결합된 메시지는 제1 라이브 방송룸 요청 메시지 및 제1 미디어 요청 메시지의 기능을 가진다. 따라서, 클라이언트 C1의 역할을 결정하는 경우, 프록시 서버는, 제1 미디어 요청 메시지의 수량에 기초하여, 현재 라이브 방송룸에 진입하는 마스터 사용자로서 서빙하는 클라이언트의 수량을 계산할 수 있다. 이와 유사하게, 클라이언트 C2의 제2 라이브 방송룸 요청 메시지 및 제2 미디어 요청 메시지는 또한 하나의 메시지로 결합될 수 있고, 클라이언트 C2의 역할을 결정하기 위한 대응하는 방법은 동일하다. 세부사항은 본 실시예에서 다시 설명되지 않는다.

또한, 본 실시예에서 제공되는 방법은, 클라이언트 C2의 역할이 예를 들어 슬레이브 사용자의 역할로부터 마스터 사용자의 역할로 변경되는 경우, 미디어 서버가 라이브 미디어 스트림을 클라이언트 C2로 계속 송신하는 프로세스를 추가로 포함한다. 또한, 도 6a 및 도 6b에 도시된 바와 같이, S40 내지 S52가 포함된다. 구체적인 방법 절차는 다음과 같다.

S40: 클라이언트 C1은 라이브 방송룸을 나가기 위한 요청 메시지를 프록시 클라이언트로 송신하며, 여기서, 라이브 방송룸을 나가기 위한 요청 메시지는 클라이언트 C1에게 라이브 방송룸을 나갈 것을 요청하는데 사용된다. 라이브 방송룸을 나가기 위한 요청 메시지는, 클라이언트 C1의 사용자 이름, IP 주소, 포트 번호, 및 사용자 역할, 및 라이브 방송룸의 이름과 같은 정보를 포함한다.

S41: 라이브 방송룸을 나가기 위한 요청 메시지를 수신한 후, 프록시 클라이언트는 클라이언트 C1의 역할을 이탈하는(Exiting) 사용자로 마킹하고, 이탈하는 사용자의 역할을 "라이브-방송-룸 사용자 상관 관계 테이블"에 기록한다.

S42: 프록시 클라이언트는 라이브 방송룸을 나가기 위한 요청 메시지를 프록시 서버로 송신한다.

S43: 라이브 방송룸을 나가기 위한 요청 메시지를 수신한 후, 프록시 서버는, 이 때 마스터 사용자로서 서빙하는 클라이언트 C1에 의해 요청되는 제1 라이브 미디어 스트림이 클라이언트 C2에 의해 시청되고 있으므로, 라이브 방송룸을 나가기 위한 요청 메시지를 미디어 서버로 일시적으로 포워딩하지 않는다. 또한, 클라이언트 C1의 역할이 이탈하는(Exiting) 사용자로 마킹되고, "라이브-방송-룸 사용자 상관 관계 테이블"에 기록된다.

S44: 프록시 서버는 라이브 방송룸 내의 클라이언트로부터 하나의 클라이언트를 새로운 마스터 사용자로 선택한다. 이 실시예에서, 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트 C1 및 클라이언트 C2만이 존재한다. 클라이언트 C1이 라이브 방송룸을 나갈 것을 요청하는 경우, 프록시 서버는 클라이언트 C2를 새로운 마스터 사용자로 선택하고, 클라이언트 C2의 역할을 슬레이브 사용자로부터 마스터 사용자로 변경하고, 그리고 또한 클라이언트 C2를 슬레이브-마스터(slave-to-master) 사용자로 마킹한다.

S45: 미디어 서버는 제2 라이브 미디어 스트림을 프록시 서버로 실시간으로 송신한다. 제2 라이브 미디어 스트림의 컨텐츠는 제1 라이브 미디어 스트림의 컨텐츠와 동일하고, 제2 라이브 미디어 스트림 및 제1 라이브 미디어 스트림 모두는 컨텐츠 소스로부터의 것이다.

S46: 프록시 서버는 제2 라이브 미디어 스트림을 수신하고, 제2 라이브 미디어 스트림을 GOP로 로컬로 캐시한다.

또한, 방법은 다음을 더 포함한다: 프록시 서버는 정렬 알고리즘에 따라 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림을 정렬한다. 구체적으로, 정렬 프로세스는 다음을 포함한다: 프록시 서버가 제1 라이브 미디어 스트림의 I 프레임을 수신할 때마다, 프록시 서버는 I 프레임을 로컬로 캐시된 제2 라이브 미디어 스트림의 I 프레임과 비교하고; 그리고 프록시 서버가 제2 라이브 미디어 스트림의 I 프레임을 수신할 때마다, 프록시 서버는 I 프레임을 로컬로 캐시된 제1 라이브 미디어 스트림의 I 프레임과 비교한다. 프록시 서버가, 전술한 비교를 통해, 제1 라이브 미디어 스트림에 속하는 I 프레임 및 제2 라이브 미디어 스트림에 속하는 I 프레임(이하 I 프레임 a 및 I 프레임 b로 지칭됨)를 찾으면-여기서, 두 I 프레임은 동일한 미디어 컨텐츠를 가짐-, 프록시 서버는 두 라이브 미디어 스트림이 정렬된 것으로 결정한다. I 프레임 a와 I 프레임 b는 동일한 비디오 프레임임을 이해할 수 있다. 또한 프록시 서버는 I 프레임 a와 I 프레임 b에 기초하여 스위칭 포인트를 결정한다. 구체적으로, 프록시 서버는 프록시 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임(이하, 스위칭 프레임 x로 지칭됨) 및 프록시 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임(이하, 스위칭 프레임 y로 지칭됨)을 결정하며, 여기서 스위칭 프레임 x 및 스위칭 프레임 y는 인접한 프레임이다. 구체적으로, 프록시 서버는 제1 라이브 미디어 스트림에서 I 프레임 a 이후의 n번째 프레임을 스위칭 프레임 x로 결정할 수 있고, 제2 라이브 미디어 스트림에서 I 프레임 b 이후의 (n+1)번째 프레임을 스위칭 프레임 y로 결정할 수 있으며, 여기서 n은 0보다 크거나 같은 정수이다. I 프레임 a 및 I 프레임 b가 동일한 비디오 프레임이므로, I 프레임 a 이후의 n번째 프레임 및 I 프레임 b 이후의 (n+1)번째 프레임은 자연히 인접한 프레임이다.

이 실시예에서, 마스터 사용자의 역할을 하는 클라이언트가 라이브 방송룸을 나가는 경우, 새로운 마스터 사용자로서 서빙하는 클라이언트 C2는 제2 라이브 미디어 스트림을 요청하고 획득하는데 사용된다. 제1 라이브 미디어 스트림의 I-번째 프레임 및 제2 라이브 미디어 스트림의 I-번째 프레임이 정렬되어, 프록시 서버는, 제2 라이브 미디어 스트림을 프록시 클라이언트로 송신하는 경우, 원래 재생 중인 제1 라이브 미디어 스트림 미디어의 미디어 컨텐츠로부터 제2 라이브 미디어 스트림으로 끊김 없이 스위칭한다. 이러한 방식으로, 라이브 방송룸 내의 사용자에 대해, 프록시 서버가 라이브 미디어 스트림을 스위칭할 때 반복적으로 재생되는 부분이 없거나 또는 재생되는 컨텐츠가 완전해진다.

S47: 프록시 서버는 라이브 방송룸을 나가기 위한 요청 메시지를 미디어 서버로 송신한다.

S48: 라이브 방송룸을 나가기 위한 요청 메시지를 수신한 후, 미디어 서버는 라이브 방송룸을 나가기 위한 응답 메시지를 프록시 서버로 송신하며, 여기서 라이브 방송룸을 나가기 위한 응답 메시지는 클라이언트 C1가 라이브 방송룸을 성공적으로 나감을 클라이언트 C1에게 통보하는데 사용된다.

S49: 프록시 서버는 클라이언트 C1에 대응하는 엔트리를 "라이브-방송-룸 사용자 상관 관계 테이블"로부터 삭제한다.

S48은 S49 이전에 수행되거나, S48은 S49 이후에 수행될 수 있다. 이는 엄격히 제한되지 않는다.

S50: 프록시 서버는 미디어 서버에 의해 송신되는, 라이브 방송룸을 나가기 위한 응답 메시지를 수신하고, 라이브 방송룸을 나가기 위한 응답 메시지를 프록시 클라이언트로 포워딩한다.

S51: 프록시 클라이언트는 프록시 서버에 의해 송신되는, 라이브 방송룸을 나가기 위한 응답 메시지를 수신하고, 클라이언트 C1에 대응하는 엔트리를 "라이브-방송-룸 사용자 상관 관계 테이블"로부터 삭제한다.

S52: 프록시 클라이언트는 라이브 방송룸을 나가기 위한 응답 메시지를 클라이언트 C1으로 송신한다.

또한, 방법은 다음을 더 포함한다: 프록시 서버는 프록시 서버에 캐시된 제2 라이브 미디어 스트림을 프록시 클라이언트로 송신하고; 그리고 프록시 클라이언트는 제2 라이브 미디어 스트림을 수신한 후 제2 라이브 미디어 스트림을 GOP로 로컬로 캐시한 다음, 캐시된 제2 라이브 미디어 스트림의 세그먼트를 클라이언트 C2로 송신하여, 라이브 방송룸 내의 클라이언트 C2가 라이브 미디어 컨텐츠를 정상적으로 시청할 수 있도록 보장한다. 또한, 제2 라이브 미디어 스트림을 클라이언트 C2로 송신하는 경우, 프록시 클라이언트는 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 클라이언트 C2에 의해 수신되는 제2 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프 및 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프는 연속적이도록 하며, 여기서, 대응하는 시간 길이는 프레임 레이트 파라미터 f의 역수이다. 구체적인 조정 프로세스는 전술한 실시예의 설명을 참조한다. 세부 사항은 여기서 다시 설명하지 않는다.

본 실시예에서 제공되는 방법에 따르면, 마스터 사용자로서 서빙하는 클라이언트가 라이브 방송룸을 나가는 경우, 프록시 서버는 라이브 방송룸 내의 클라이언트로부터 새로운 클라이언트를 새로운 마스터 사용자로 선택하고, 새로운 마스터 사용자의 라이브 미디어 스트림에 정렬을 수행하고, 그리고 라이브 미디어 스트림을 프록시 클라이언트로 송신한다. 새로운 마스터 사용자의 그리고 프록시 서버에 의해 송신되는 라이브 미디어 스트림을 수신한 후, 프록시 클라이언트는 라이브 미디어 스트림의 타임스탬프를 조정하여, 라이브 방송룸에서 미디어 컨텐츠를 시청하는 다른 사용자가 미디어 스트림의 스위칭을 인식하지 못하게 한다. 이 방법은 라이브 방송룸에서 시청하는 사용자 경험을 보장한다.

실시예 2

이 실시예는 다른 라이브 미디어 스트림 송신 방법을 제공하고, 이 방법은 복수의 마스터 사용자가 있는 기술적 시나리오에 적용된다. 복수의 마스터 사용자는, 라이브 방송룸에서 마스터 사용자의 역할을 하는 클라이언트의 특정한 수는 2보다 크거나 같음을 의미한다. 또한, 복수의 마스터 사용자는 하나의 주-마스터 사용자 및 복수의 부-마스터 사용자를 포함하고, 적어도 하나의 슬레이브(slave) 사용자를 더 포함할 수 있으며, 여기서, 주-마스터 사용자는 주-마스터 사용자로 식별될 수 있고, 부-마스터 사용자는 부-마스터 사용자로 식별될 수 있다. 또한, 이 방법에서, 동일한 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트가 라이브 미디어 스트림을 요청하고 획득하는 프로세스는 전술한 실시예 1에서 설명한 프로세스와 유사하나, 차이는 다음과 같다: 클라이언트의 역할을 식별하고; 그리고 마스터 사용자 역할을 하는 클라이언트가 라이브 방송룸을 나가는 경우, 라이브 방송 내에 여전히 있는 클라이언트의 역할을 식별하고 라이브 미디어 스트림을 복제하고 전달한다.

구체적으로, 본 실시예에서, 제3 클라이언트(이하 간단히 "클라이언트 C3"라 함)가 추가로 포함되고, 라이브 방송룸에서 마스터 사용자의 수량의 미리 정해진 상한치는 2로 설정된다. 이 경우, 각각의 클라이언트가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 획득하는 것을 요청하는 프로세스는 다음과 같다. 도 7a 내지 도 7c에 도시된 바와 같이, 프로세스는 다음 단계를 포함한다.

S1 내지 S18은 클라이언트 C1가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 획득하는 것을 요청하는 프로세스이다. 이 프로세스는 실시예 1의 S1 내지 S18과 같고, 유일한 차이는, S9에서, "라이브-방송-룸 사용자 상관 관계 테이블"이 리프레시될 때 클라이언트 C1의 역할이 주-마스터(main-master) 사용자로 마킹되거나 설정된다는 것이다. 다른 단계에 대해서는, 실시예 1의 설명을 참조한다. 세부 사항은 여기서 다시 설명하지 않는다.

프록시 서버가 미디어 서버에 의해 송신되는 제1 라이브 미디어 스트림을 획득하는 경우, 프록시 서버는 제1 라이브 미디어 스트림의 3개의 세그먼트를 GOP로 로컬로 캐시하고, 제1 라이브 미디어 스트림의 세그먼트를 프록시 클라이언트를 통해 실시간으로 클라이언트 C1으로 송신한다.

S19 내지 S39은 클라이언트 C2가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 획득하는 것을 요청하는 프로세스이다. 구체적으로, S19 내지 S24는 클라이언트 C2가 프록시 클라이언트를 통해 라이브 방송룸에 진입하고 제2 라이브 방송룸 요청 메시지를 프록시 클라이언트로 송신하는 프로세스이다. 프로세스는 실시예 1에서 S19로부터 S24까지의 프로세스와 동일하다. 따라서, 실시예 1의 구체적인 설명을 참조할 수 있으며, 세부 사항은 여기에 다시 설명하지 않는다.

S25: 프록시 클라이언트에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신한 후, 프록시 서버는 제2 라이브 방송룸 요청 메시지에 기초하여 클라이언트 C2의 역할을 결정한다. 구체적으로, 프록시 서버는, 제2 라이브 방송룸 요청 메시지를 획득하는 경우, 마스터 사용자의 역할을 하고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하는지 여부를 결정한다. 수량이 미리 정해진 상한치에 도달하면, 프록시 서버는 클라이언트 C2가 슬레이브 사용자인 것으로 결정한다. 수량이 미리 정해진 상한치에 도달하지 않고 마스터 사용자로서 서빙하는 클라이언트의 수량이 0이 아니면, 프록시 서버는 클라이언트 C2가 부-마스터 사용자인 것으로 결정한다. 이 실시예에서, 미리 정해진 상한치는 2이고, 프록시 서버는, 클라이언트 C1으로부터의 제1 라이브 방송룸 요청 메시지 및 클라이언트 C2로부터의 제2 라이브 방송룸 요청 메시지의, 현재 총 2개의 라이브 방송룸 요청 메시지가 획득되는 것으로 결정하고, 클라이언트 C1의 역할은 주-마스터 사용자이다. 이 경우, 라이브 방송룸에서 마스터 사용자로서 서빙하는 클라이언트의 수량은 1이고, 수량은 미리 정해진 상한치에 도달하지 않는다. 따라서, 프록시 서버는 클라이언트 C2의 역할이 부-마스터 사용자인 것으로 결정한다.

또한, 방법은 다음을 더 포함한다: "라이브-방송-룸 사용자 상관 관계 테이블"에서 클라이언트 C2에 관한 엔트리를 리프레시하는 단계, 및 클라이언트 C2의 역할을 부-마스터 사용자로 마킹하는 단계.

방법은 S26 내지 S39를 더 포함한다. S26 내지 S39는 클라이언트 C2는 프록시 클라이언트에 의해 송신되는 제1 라이브 미디어 스트림을 획득하고 프록시 클라이언트는 제1 라이브 미디어 스트림을 클라이언트 C1으로 송신하는 프로세스이다. S26로부터 S39까지의 프로세스는 실시예 1에서 S26로부터 S39까지의 프로세스와 동일하다. 따라서, 세부 사항은 본 실시예에서 다시 설명하지 않는다.

그러나, S32에서, 프록시 서버가 미디어 서버로부터 제2 라이브 미디어 스트림을 획득한 후-여기서, 제2 라이브 미디어 스트림은 클라이언트 C2로 송신되는 미디어 스트림이고 클라이언트 C2의 역할은 부-마스터 사용자임-, 프록시 서버는 제2 라이브 미디어 스트림을 GOP로 로컬로 캐시하고, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림을 정렬 알고리즘에 따라 정렬한다.

구체적으로, 프록시 서버는 정렬 알고리즘에 따라 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림을 정렬하는 프로세스는 다음을 포함한다: 프록시 서버가 제1 라이브 미디어 스트림의 I 프레임을 수신할 때마다, 프록시 서버는 I 프레임을 로컬로 캐시된 제2 라이브 미디어 스트림의 I 프레임과 비교하고; 그리고 프록시 서버가 제2 라이브 미디어 스트림의 I 프레임을 수신할 때마다, 프록시 서버는 I 프레임을 로컬로 캐시된 제1 라이브 미디어 스트림의 I 프레임과 비교한다. 프록시 서버가, 전술한 비교를 통해, 제1 라이브 미디어 스트림에 속하는 I 프레임 및 제2 라이브 미디어 스트림에 속하는 I 프레임(이하 I 프레임 a 및 I 프레임 b로 지칭됨)를 찾으면-여기서, 두 I 프레임은 동일한 미디어 컨텐츠를 가짐-, 프록시 서버는 두 라이브 미디어 스트림이 정렬된 것으로 결정한다. I 프레임 a와 I 프레임 b는 동일한 비디오 프레임임을 이해할 수 있다. 또한 프록시 서버는 I 프레임 a와 I 프레임 b에 기초하여 스위칭 포인트를 결정한다. 구체적으로, 프록시 서버는 클라이언트 C2로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임(이하, 스위칭 프레임 x로 지칭됨) 및 클라이언트 C2로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임(이하, 스위칭 프레임 y로 지칭됨)을 결정하며, 여기서 스위칭 프레임 x 및 스위칭 프레임 y는 인접한 프레임이다. 구체적으로, 프록시 서버는 제1 라이브 미디어 스트림에서 I 프레임 a 이후의 n번째 프레임을 스위칭 프레임 x로 결정할 수 있고, 제2 라이브 미디어 스트림에서 I 프레임 b 이후의 (n+1)번째 프레임을 스위칭 프레임 y로 결정할 수 있으며, 여기서 n은 0보다 크거나 같은 정수이다. I 프레임 a 및 I 프레임 b가 동일한 비디오 프레임이므로, I 프레임 a 이후의 n번째 프레임 및 I 프레임 b 이후의 (n+1)번째 프레임은 자연히 인접한 프레임이다.

이 실시예에서, 부-마스터 사용자의 역할을 하는 제2 클라이언트에 대해, 프록시 서버가 미디어 서버에 의해 송신되는 제2 라이브 미디어 스트림을 획득한 후, 프록시 서버는 후속 사용을 위해 제2 라이브 미디어 스트림을 로컬로 캐시한다.

다음 단계 S40 내지 S61은 클라이언트 C3가 라이브 방송룸에 진입하고 라이브 미디어 스트림을 요청하고 획득하는 프로세스이다. 세부 사항은 다음과 같다.

S40: 클라이언트 C3는 클라이언트 C3에 의해 액세스될 수 있는 미디어 서버에 대한 요청 메시지를 RDC의 웹 서버로 송신한다. 또한, 요청 메시지는 클라이언트 C3의 사용자 이름 및 IP 주소, 라이브 방송룸의 이름, 및 클라이언트 C3이 성공적으로 인증된 후 획득되는 키 토큰과 같은 정보를 포함하며, 여기서 IP 주소는 클라이언트 C3의 위치를 결정하는데 사용된다.

S41: RDC의 웹 서버는 요청 메시지를 수신하고, 클라이언트 C3에 의해 액세스될 수 있는 미디어 서버에 대한 응답 메시지를 클라이언트 C3로 송신하며, 여기서, 응답 메시지는 클라이언트 C3에 의해 액세스될 수 있는 미디어 서버를 클라이언트 C3에게 통보하는데 사용된다. 구체적으로, RDC의 웹 서버는 응답 메시지를 프록시 서버로 송신하고, 프록시 서버는 응답 메시지를 프록시 클라이언트로 송신하고, 프록시 클라이언트는 응답 메시지를 클라이언트 C3로 포워딩한다.

웹 서버는, 클라이언트 C3에 의해 송신되는, 클라이언트 C3에 의해 액세스될 수 있는 미디어 서버에 대한 요청 메시지에서 전달되는 IP 주소에 기초하여, 클라이언트 C3의 위치를 결정하고 위치 정보에 기초하여 클라이언트 C3에 가장 가까운 미디어 서버를 타깃 미디어 서버로 선택한다.

S42: 응답 메시지는, 예를 들어, 타깃 미디어 서버의 URL 정보, IP 주소, 및 포트 번호와 같은, 타깃 미디어 서버의 관련 정보를 전달한다. 따라서, 응답 메시지를 포워딩하는 경우, 프록시 서버 및 프록시 클라이언트는 클라이언트 C3에 의해 액세스될 수 있는 미디어 서버에 관한 정보, 즉, 타깃 미디어 서버의 관련 정보를 를 획득한다.

S43: 클라이언트 C3는 라이브 방송룸에 진입하는 것을 요청하기 위한 제3 라이브 방송룸 요청 메시지를 프록시 클라이언트로 송신하며, 여기서 제3 라이브 방송룸 요청 메시지는 클라이언트 C3가 라이브 방송룸에 진입할 것을 요청한다는 것을 나타낸다. 제3 라이브 방송룸 요청 메시지는, 클라이언트 C3의 사용자 이름, IP 주소, 및 포트 번호, 라이브 방송룸의 이름, 인증이 성공한 후 획득되는 토큰, 등을 포함한다.

S44: 프록시 클라이언트는 제3 라이브 방송룸 요청 메시지를 수신하고, 클라이언트 C3의 역할을 작동(working) 상태로 설정한다. 또한, 프록시 클라이언트는 "라이브-방송-룸 사용자 상관 관계 테이블"을 업데이트하고, 클라이언트 C3에 관한 엔트리를 라이브-방송-룸 사용자 상관 관계 테이블에 추가한다. 구체적으로, 엔트리의 내용은, 클라이언트 C3의 IP 주소, 포트 번호, 사용자 상태, 및 사용자 이름, RDC 내의 선택된 타깃 미디어 서버의 IP 주소 및 포트 번호, 및 라이브 방송룸의 이름과 같은 정보를 포함한다. 클라이언트 C3의 사용자 상태는 작동 상태이다. 또한, 엔트리는, 프록시 클라이언트의 식별자, 예를 들어, 프록시 클라이언트의 IP 주소 및 포트 번호를 추가로 포함한다.

또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 프록시 클라이언트의 식별자를 제3 라이브 방송룸 요청 메시지에 추가하며, 여기서 프록시 클라이언트의식별자는 프록시 클라이언트의 IP 주소, 포트 번호, 등이다.

S45: 프록시 클라이언트는 프록시 클라이언트의 식별자가 추가된 제3 라이브 방송룸 요청 메시지를 프록시 서버로 송신하며, 여기서, 수정된 제3 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자, 클라이언트 C3의 사용자 이름, 라이브 방송룸의 이름, 및 인증이 성공한 후 획득되는 토큰과 같은 정보를 포함한다.

S46: 프록시 서버는 수정된 제3 라이브 방송룸 요청 메시지를 수신하고, 제3 라이브 방송룸 요청 메시지에 기초하여 클라이언트 C3의 역할을 결정하고, 그리고 라이브-방송-룸 사용자 상관 관계 테이블을 리프레시한다. 구체적으로, 클라이언트 C3의 역할을 결정하는 단계는 다음을 포함한다: 제3 라이브 방송룸 요청 메시지가 수신되는 경우, 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 마스터 사용자의 수량이 미리 정해진 상한치에 도달하는지 여부를 결정하는 단계; 및 수량이 미리 정해진 상한치에 도달하면, 클라이언트 C3의 역할이 슬레이브 사용자인 것으로 결정하거나, 또는 수량이 미리 정해진 상한치에 도달하지 않고 마스터 사용자의 수량 이 0이 아니면, 클라이언트 C3의 역할은 부-마스터 사용자인 것으로 결정하는 단계. 이 실시예에서, 미리 정해진 상한치는 2이고; 그리고 클라이언트 C3가 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 경우, 마스터 사용자로서 서빙하는 클라이언트의 수량은 현재 2이며, 이는 미리 정해진 상한치와 동일하다. 따라서, 프록시 서버는 클라이언트 C3의 역할이 슬레이브 사용자인 것으로 결정한다.

또한, 방법은 다음을 더 포함한다: 클라이언트 C3의 역할을 결정한 후, 프록시 서버는 "라이브-방송-룸 사용자 상관 관계 테이블"을 리프레시하고, 클라이언트 C3의 역할을 슬레이브 사용자로 마킹한다.

S47: 프록시 서버는 제3 라이브 방송룸 요청 메시지를 RDC의 미디어 서버로 송신한다. 제3 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자를 포함하지 않는다.

S48: RDC의 미디어 서버는 제3 라이브 방송룸 요청 메시지를 수신하고, 제3 라이브 방송룸 응답 메시지를 클라이언트 C3로 송신하며, 여기서 제3 라이브 방송룸 응답 메시지는 클라이언트 C3가 라이브 방송룸에 성공적으로 진입하였음을 클라이언트 C3에게 통보하는데 사용된다. 구체적으로, 제1, 미디어 서버는 제3 라이브 방송룸 응답 메시지를 프록시 서버로 송신하고, 그런 다음 프록시 서버는 제3 라이브 방송룸 응답 메시지를 프록시 클라이언트로 송신하고, 마지막으로 프록시 클라이언트는 제3 라이브 방송룸 응답 메시지를 클라이언트 C3로 포워딩한다.

S49: 클라이언트 C3는 제3 미디어 요청 메시지를 송신하며, 여기서 제3 미디어 요청 메시지는 미디어 서버로부터 라이브 미디어 스트림을 획득하는 것을 요청하는데 사용된다. 선택사항으로서, 제3 미디어 요청 메시지는 클라이언트 C3의 식별자를 전달하며, 여기서 식별자는 클라이언트 C3을 고유하게 식별하는데 사용된다. 이 실시예에서, 식별자는 클라이언트 C3의 IP 주소 및 사용자 이름, 등을 포함한다.

S50: 제3 미디어 요청 메시지를 수신한 후, 미디어 서버는 제3 미디어 응답 메시지를 클라이언트 C3로 송신하며, 여기서, 제3 미디어 응답 메시지는 클라이언트 C3가 라이브 미디어 스트림을 획득하도록 허용됨을 클라이언트 C3에게 통보하는데 사용된다. 구체적으로, 미디어 서버는 제3 미디어 응답 메시지를 프록시 서버 및 프록시 클라이언트를 통해 클라이언트 C3로 포워딩한다.

S51: 프록시 클라이언트는 로컬로 캐시된 제1 라이브 미디어 스트림을 클라이언트 C3로 송신한다. 제1 라이브 미디어 스트림을 송신하기 전에, 클라이언트 C3에 의해 수신되는 제1 라이브 미디어 스트림의 첫 번째 프레임의 타임스냄프가 0이 되도록, 그리고 클라이언트 C3로 송신되는 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적이도록, 프록시 클라이언트는 추가적으로 제1 라이브 미디어 스트림의 타임스탬프를 조정할 필요가 있다.

S52: 미디어 서버는 제3 라이브 미디어 스트림을 프록시 서버로 송신하며, 여기서, 제3 라이브 미디어 스트림은 컨텐츠 소스로부터 오고, 제3 라이브 미디어 스트림은 클라이언트 C3로 송신되는 미디어 스트림이다.

S53: 제3 라이브 미디어 스트림을 수신한 후, 클라이언트 C3의 역할은 슬레이브 사용자이므로, 프록시 서버는 제3 라이브 미디어 스트림을 캐시하지도 포워딩하지도 않는다.

S54. 프록시 서버는, 실시간으로, 미디어 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신한다.

S55: 프록시 서버는 제1 라이브 미디어 스트림을 GOP로 로컬로 캐시한다. 프록시 서버는 몇가지 최근 GOP만을 로컬로 캐시한다.

S56: 프록시 서버는 캐시된 제1 라이브 미디어 스트림을 프록시 클라이언트로 송신한다.

S57: 프록시 클라이언트는 제1 라이브 미디어 스트림을 GOP로 로컬로 캐시한다.

S58: 프록시 클라이언트는 라이브-방송-룸 사용자 상관 관계 테이블에 기초하여 제1 라이브 미디어 스트림을 복제한다. 이 실시예에서, 주-마스터 사용자로서 서빙하는 클라이언트 C1에 추가로, 부-마스터 사용자로서 서빙하는 클라이언트 C2 및 슬레이브 사용자로서 서빙하는 클라이언트 C3가 있으며, 따라서 프록시 클라이언트는 제1 라이브 미디어 스트림의 2개의 복사본을 만든다.

S59: 프록시 클라이언트는 제1 라이브 미디어 스트림을 클라이언트 C1으로 송신한다. 또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 클라이언트 C1의 재생 시점에 기초하여 제1 라이브 미디어 스트림의 타임스탬프를 조정한다.

S60: 프록시 클라이언트는 제1 라이브 미디어 스트림을 클라이언트 C2로 송신한다. 또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 클라이언트 C2의 재생 시점에 기초하여 제1 라이브 미디어 스트림의 타임스탬프를 조정한다.

S61: 프록시 클라이언트는 제1 라이브 미디어 스트림을 클라이언트 C3로 송신한다. 또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 클라이언트 C3의 재생 시점에 기초하여 제1 라이브 미디어 스트림의 타임스탬프를 조정한다.

구체적으로, S59 내지 S61에서 프록시 클라이언트가 제1 라이브 미디어 스트림의 타임스탬프를 조정하는 프로세스에 대해서는, 전술한 실시예의 설명을 참조한다. 세부 사항은 여기서 다시 설명하지 않는다.

또한, 본 실시예에서, 방법은 주-마스터 사용자로서 서빙하는 클라이언트 C1이 라이브 방송룸을 나가는 프로세스를 더 포함한다. 이 프로세스는 실시예 1에서 클라이언트 C1이 라이브 방송룸을 나가는 프로세스와 유사하다. 세부 사항은 도 8a 내지 도 8c에 도시되어 있다.

S62 내지 S65는 실시예 1의 S40 내지 S43과 동일하다.

S66: 프록시 서버는 부-마스터 사용자로서 서빙하는 클라이언트 C2를 새로운 주-마스터 사용자로 선택하고, 클라이언트 C2의 역할을 부-마스터 사용자로부터 주-마스터 사용자로 변경하고, "라이브-방송-룸 사용자 상관 관계 테이블"에서 클라이언트 C2에 관한 엔트리를 업데이트한다.

S67 내지 S73은 실시예 1의 S48 내지 S53과 동일하다.

S74: 미디어 서버는 제3 라이브 미디어 스트림을 프록시 서버로 송신하며, 여기서, 제3 라이브 미디어 스트림은 클라이언트 C3로 송신되는 미디어 스트림이고, 제3 라이브 미디어 스트림은 컨텐츠 소스로부터 온다. 이 경우, 클라이언트 C3의 역할은 슬레이브 사용자로부터 부-마스터 사용자로 변경된다.

S75: 프록시 서버가 제3 라이브 미디어 스트림을 수신한 후, 클라이언트 C3의 역할이 부-마스터 사용자로 변경되었으므로, 프록시 서버는 제3 라이브 미디어 스트림을 GOP로 로컬로 캐시하고, 제2 라이브 미디어 스트림 및 제3 라이브 미디어 스트림을 정렬 알고리즘에 따라 정렬한다.

클라이언트 C1가 라이브 방송룸을 나가는 절차에서, 프록시 서버가 라이브 방송룸에서 클라이언트(예를 들어, 클라이언트 C2)로 송신되는 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 스위칭한 후, 미디어 서버는 제2 라이브 미디어 스트림을 프록시 서버를 통해 클라이언트 C2로 연속적으로 송신한다. 스위칭 이후, 프록시 서버는 연속적으로 수신되는 제2 라이브 미디어 스트림을 프록시 클라이언트로 전달한다. 세부 사항에 관해서는, 후속 단계를 참조한다.

S76: 미디어 서버는 제2 라이브 미디어 스트림을 프록시 서버로 실시간으로 송신하며, 여기서, 제2 라이브 미디어 스트림은 클라이언트 C2로 송신되는 미디어 스트림이고, 제2 라이브 미디어 스트림은 컨텐츠 소스로부터 온다. 이 경우, 클라이언트 C2의 역할은 부-마스터 사용자로부터 주-마스터 사용자로 변경된다.

S77: 제2 라이브 미디어 스트림을 수신한 후, 프록시 서버는 제2 라이브 미디어 스트림을 GOP로 로컬로 캐시하고, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림을 정렬 알고리즘에 따라 정렬한다.

S78: 프록시 서버는 제2 라이브 미디어 스트림을 프록시 클라이언트로 송신한다.

S79: 프록시 클라이언트는 프록시 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신하고, 제2 라이브 미디어 스트림을 GOP로 로컬로 캐시한다.

S80: 프록시 클라이언트는 "라이브-방송-룸 사용자 상관 관계 테이블"에 기초하여 제2 라이브 미디어 스트림을 복제하고 전달한다. 이 실시예에서, 프록시 클라이언트는 제2 라이브 미디어 스트림의 하나의 복사본을 만들고, 제2 라이브 미디어 스트림의 복사본을 라이브 방송룸에서 부-마스터 사용자의 역할을 하는 클라이언트 C3로 송신할 준비를 한다.

S81: 프록시 클라이언트는 로컬로 캐시된 제2 라이브 미디어 스트림을 클라이언트 C2로 송신한다. 또한, 방법은 다음을 더 포함한다: 프록시 클라이언트은 클라이언트 C2이 미디어 스트림의 비디오 프레임을 수신하는 시점에 기초하여 제2 라이브 미디어 스트림의 타임스탬프를 조정한다.

S82: 프록시 클라이언트는 로컬로 캐시된 제2 라이브 미디어 스트림을 클라이언트 C3로 송신한다. 또한, 방법은 다음을 더 포함한다: 프록시 클라이언트는 클라이언트 C3이 미디어 스트림의 비디오 프레임을 수신하는 시점에 기초하여 제2 라이브 미디어 스트림의 타임스탬프를 조정한다.

본 실시예에서 제공되는 방법에 따르면, 주-마스터 사용자로서 서빙하는 클라이언트 C1이 라이브 방송룸을 나가는 경우, 프록시 서버는 새로운 주-마스터 사용자로서 서빙하는 클라이언트 C2의 라이브 미디어 스트림을 프록시 클라이언트로 송신한 다음, 프록시 클라이언트는 새로운 라이브 미디어 스트림을 클라이언트 C2 및 C3로 송신하여, 라이브 방송룸에서 주-마스터 사용자가 나가는 경우 라이브 방송룸 내의 다른 사용자의 사용자 경험이 영항을 받지 않는 것을 확보한다.

이 실시예에서, 프록시 서버는 미디어 서버에 의해 송신되는 복수의 라이브 미디어 스트림을 획득하고, 각각의 라이브 미디어 스트림은 하나의 클라이언트의 미디어 요청 메시지에 대응한다. 그러나, 미디어 스트림을 프록시 클라이언트로 송신하는 경우, 프록시 서버는 주-마스터 사용자 역할을 하는 클라이언트에 대응하는 라이브 미디어 스트림만을 프록시 클라이언트로 송신하고; 부-마스터 사용자 역할을 하는 클라이언트의 획득되는 라이브 미디어 스트림을 로컬로 캐시하고; 및 슬레이브 사용자 역할을 하는 클라이언트의 획득되는 라이브 미디어 스트림은 캐시하지 않고, 라이브 미디어 스트림을 직접 폐기한다. 따라서, 프록시 서버는 하나의 라이브 미디어 스트림을 프록시 클라이언트로 전송하기 위한 광역 네트워크 대역폭만을 소비하고, 프록시 서버와 프록시 클라이언트 사이의 WAN 네트워크 리소스를 절약한다. 프록시 클라이언트 측에서, 프록시 서버에 의해 송신되는 라이브 미디어 스트림을 수신한 후, 프록시 클라이언트는 라이브 미디어 스트림을 복제하고 라이브 미디어 스트림의 복사본을 라이브 방송룸 내의 모든 클라이언트로 전달하며, 라이브 미디어 스트림을 송신하기 전에 각각의 클라이언트의 타임스탬프를 조정하여, 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 사용자는 라이브 방송 컨텐츠를 "동기적으로" 시청할 수 있다.

또한, 본 실시예에서 제공되는 방법은 클라이언트 C2 및 클라이언트 C1이 동시에 라이브 방송룸을 나갈 것을 요청하는 프로세스를 더 포함한다. 구체적으로, 클라이언트 C2가 라이브 방송룸을 나갈 것을 요청하는 프로세스는 클라이언트 C1이 라이브 방송룸을 나가는 전술한 프로세스와 유사하다.

구체적으로, 먼저, 클라이언트 C1은 라이브 방송룸을 나갈 것을 요청한다. 이 프로세스는 (도 8a 및 도 8b에 도시된 바와 같은) S62로부터 S73까지의 전술한 프로세스와 동일하고, 세부 사항은 다시 설명하지 않는다. 클라이언트 C1이 라이브 방송룸을 나가는 경우, 클라이언트 C2의 역할은 부-마스터 사용자로부터 주-마스터 사용자로 변경되고, 클라이언트 C3의 역할은 슬레이브 사용자로부터 부-마스터 사용자로 변경된다.

S73 이후, 클라이언트 C2가 라이브 방송룸을 나갈 것을 요청하는 프로세스는 다음을 포함한다: 클라이언트 C2는 라이브 방송룸을 나가기 위한 요청 메시지를 프록시 클라이언트로 송신하고; 라이브 방송룸을 나가기 위한 요청 메시지를 수신한 후, 프록시 클라이언트는 클라이언트 C2의 역할을 이탈하는 사용자로 마킹하고, 그리고 라이브 방송룸을 나가기 위한 요청 메시지를 프록시 서버로 포워딩하고; 라이브 방송룸을 나가기 위한 요청 메시지를 수신한 후, 프록시 서버는 "라이브-방송-룸 사용자 상관 관계 테이블"에서 클라이언트 C2의 역할을 이탈하는 사용자로 리프레시한다. 이 경우, 클라이언트 C3는 여전히 라이브 방송룸에 있고 라이브 미디어 스트림을 획득하며, 프록시 서버는 미디어 서버에 의해 송신되는 제3 라이브 미디어 스트림을 수신하며, 여기서 제3 라이브 미디어 스트림은 클라이언트 C3로 송신되는 미디어 스트림이다. 이 경우, 클라이언트 C3의 역할은 부-마스터 사용자로부터 주-마스터 사용자로 변경된다. 따라서, 프록시 서버는 제3 라이브 미디어 스트림을 GOP로 로컬로 캐시한다.

클라이언트 C3가 라이브 방송룸에서 라이브 방송 컨텐츠를 여전히 시청하므고, 프록시 서버는 라이브 미디어 스트림을 제3 라이브 미디어 스트림으로 스위칭하고, 제3 라이브 미디어 스트림 및 제1 라이브 미디어 스트림을 정렬할 필요가 있다. 프록시 서버는 제3 라이브 미디어 스트림을 프록시 클라이언트로 송신한다. 제3 라이브 미디어 스트림을 수신한 후, 프록시 클라이언트는 제3 라이브 미디어 스트림을 캐시하여 클라이언트 C3로 송신하고, 프록시 클라이언트가 제3 라이브 미디어 스트림을 송신할 때 타임스탬프를 조정하여, 클라이언트 C3로 송신되는 제3 라이브 미디어 스트림은 이전의 미디어 스트림에 끊김 없이 상호 연결될 수 있다. 이러한 방식으로, 클라이언트 C1 및 C2가 나가는 경우, 클라이언트 C3는 영향을 받지 않으며, 라이브 방송룸에 여전히 있는 클라이언트 C3에 의해 시청되는 미디어 컨텐츠의 매끄러움이 확보된다.

또한, 방법은 다음을 더 포함한다: 라이브 방송을 나가기 위한 클라이언트 C2의 응답 메시지를 포워딩하는 경우 프록시 서버 및 프록시 클라이언트는 클라이언트 C2에 관한 엔트리를 "라이브-방송-룸 사용자 상관 관계 테이블"로부터 삭제하여, 라이브 방송룸 내의 클라이언트에 관한 정보를 실시간으로 업데이트한다.

전술한 실시예 1 및 실시예 2에서, 동일한 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 클라이언트, 및 프록시 서버는 각각의 클라이언트의 역할을 식별하고 라이브 미디어 스트림을 전달함에 유의해야 한다. 또한, 다른 경우가 있다. 복수의 프록시 클라이언트가 동일한 프록시 서버에 액세스한다. 프록시 서버를 통해 동일한 라이브 방송룸에 진입하는 모든 클라이언트에 대해, 프록시 서버는 복수의 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 모든 클라이언트에 대한 사용자 역할을 집합적으로 식별한다. 예를 들어, 3개의 프록시 클라이언트가 동일한 프록시 서버에 액세스하는 경우, 프록시 서버는 라이브 방송룸 내의 모든 클라이언트에 대한 마스터 사용자 및 슬레이브 사용자를 중앙에서 식별하고, 식별된 역할에 기초하여 라이브 미디어 스트림을 각각의 프록시 클라이언트로 송신한다. 또한, 프록시 서버가 사용자 역할을 식별하고 라이브 미디어 스트림을 각각의 프록시 클라이언트로 송신하고 각각의 프록시 클라이언트는 라이브 미디어 스트림을 복제하고 라이브 미디어 스트림의 복사본을 프록시 클라이언트에 액세스하는 모든 클라이언트로 전달하는 프로세스는, 실시예 1 및 실시예 2의 방법의 프로세스와 유사하다. 세부 사항은 여기서 다시 설명하지 않는다.

본 출원의 본 실시예에서 제공되는 비디오 라이브 방송을 위한 양방향 프록시 기술에 따르면, 프록시 클라이언트와 프록시 서버가 사용된다. 프록시 서버는, 라이브 방송룸 요청 메시지에 기초하여 각각의 클라이언트의 역할을 식별하도록, 그리고 마스터 사용자 역할을 하는 클라이언트의 하나의 라이브 미디어 스트림만을 프록시 클라이언트로 송신하도록, 구성된다. 마스터 사용자의 라이브 미디어 스트림을 수신한 후, 프록시 클라이언트는 라이브 미디어 스트림을 복제하고 라이브 미디어 스트림의 복사본을 프록시 클라이언트에 액세스하는 모든 클라이언트로 전달한다. 이 방법은 프록시 서버와 프록시 클라이언트 사이에 미디어 스트림을 송신하기 위한 트래픽을 효과적으로 줄이고, 송신 대역폭을 줄이며, WAN 네트워크 오버헤드를 줄인다.

또한, 이 방법에 따르면, 미디어 서버는 클라이언트에 대해 독립적인 인증을 구성할 필요가 없으며, 프록시 클라이언트가 중앙에서 포워딩을 수행하므로, 운영 및 유지 관리 비용이 더욱 절감된다.

다음은 본 출원의 전술한 방법 실시예에 대응하는 장치 및 하드웨어 디바이스 실시예를 설명한다.

도 9는 본 출원의 실시예에 따른 미디어 스트림 송신 장치의 개략적인 구조도이다. 장치는 전술한 실시예에서 설명된 프록시 서버 또는 프록시 클라이언트일 수 있다.

또한, 장치는 수신 유닛(901), 처리 유닛(902), 및 송신 유닛(903)을 포함한다. 또한, 장치는 다른 기능 모듈 또는 유닛, 예를 들어, 저장 유닛을 더 포함할 수 있다. 장치는 서버일 수 있고, 전술한 실시예에서 미디어 스트림 송신 방법을 수행하도록 구성된다. 예를 들어, 장치는 동일한 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 적어도 2개의 클라이언트에 대해 라이브 미디어 스트림을 제공한다.

구체적으로, 장치가 프록시 서버인 경우, 수신 유닛(901)은 라이브 방송룸 입장을 요청하는데 사용되고 동일한 프록시 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 수신하도록 구성되며, 여기서, 제1 라이브 방송룸 요청 메시지는 제1 클라이언트로부터 온 것이고, 제2 라이브 방송룸 요청 메시지는 제2 클라이언트로부터 온 것이다. 수신 유닛(901)은 미디어 서버에 의해 프록시 서버를 통해 제1 클라이언트로 송신되는 제1 라이브 미디어 스트림 및 미디어 서버에 의해 프록시 서버를 통해 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림을 수신하도록 추가적으로 구성된다. 처리 유닛(902)은 제1 라이브 방송룸 요청 메시지에 기초하여 제1 클라이언트의 역할을 결정하도록, 그리고 제2 라이브 방송룸 요청 메시지에 기초하여 제2 클라이언트의 역할하도록, 구성된다. 송신 유닛(903)은, 제1 클라이언트의 역할이 마스터 사용자이고 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정되는 경우, 제1 라이브 미디어 스트림만을 제1 클라이언트 및 제2 클라이언트로 송신하도록 구성된다.

제1 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자를 포함하고, 제2 라이브 방송룸 요청 메시지는 프록시 클라이언트의 식별자를 포함한다. 처리 유닛(902)은, 제1 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자 및 제2 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자에 기초하여, 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지가 동일한 프록시 클라이언트로부터 온 것임을 결정하도록 추가적으로 구성된다.

선택사항으로서, 본 실시예의 구체적인 구현예로서, 처리 유닛(902)은, 제2 라이브 방송룸 요청 메시지가 수신되는 경우, 라이브 방송룸에서 역할이 마스터 사용자이고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트가 라이브 방송룸 내에 있는지 여부를 결정하도록; 그리고 라이브 방송룸에서 역할이 마스터 사용자이고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트가 라이브 방송룸 내에 있으면, 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정하도록, 구체적으로 구성된다. 그렇지 않으면, 라이브 방송룸에서 역할이 마스터 사용자이고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트가 없으면, 처리 유닛(902)은 제2 클라이언트의 역할은 마스터 사용자인 것으로 결정한다.

선택사항으로서, 본 실시예의 다른 구체적인 구현예로서, 수신 유닛(901)은, 제1 라이브 미디어 스트림이 프록시 클라이언트로 송신된 후, 프록시 클라이언트에 의해 송신되는 그리고 라이브 방송룸을 나가기 위한 요청 메시지를 수신하도록 추가적으로 구성되며, 여기서 라이브 방송룸을 나가기 위한 요청 메시지는 제1 클라이언트에게 라이브 방송룸을 나갈 것을 요청하는데 사용된다. 처리 유닛(902)은, 제2 클라이언트를 새로운 마스터 사용자로 결정하는 경우, 제2 클라이언트의 역할을 슬레이브 사용자로부터 마스터 사용자로 변경하도록; 그리고 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 스위칭하도록, 추가적으로 구성된다.

선택사항으로서, 본 실시예의 또 다른 구체적인 구현예로서, 제2 클라이언트에 의해 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 제2 클라이언트에 의해 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 인접한 프레임이다. 처리 유닛(902)은, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 기초하여, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하도록-여기서, 제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임임-; 제1 I 프레임 및 제2 I 프레임에 기초하여, 서로 인접하고 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하고, 제1 스위칭 프레임 및 제2 스위칭 프레임을 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임으로서 각각 사용하도록, 추가적으로 구성된다. 송신 유닛(903)은, 제1 스위칭 프레임 및 제2 스위칭 프레임이 결정된 후, 라이브 방송룸을 나가기 위한 요청 메시지를 제1 클라이언트로부터 미디어 서버로 포워딩하도록 추가적으로 구성된다.

선택사항으로서, 본 실시예의 또 다른 구체적인 구현예로서, 처리 유닛(902)은, 제2 라이브 방송룸 요청 메시지가 수신되는 경우, 마스터 사용자의 역할을 하고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하는지 여부를 결정하도록-여기서, 미리 정해진 상한치는 2보다 크거나 같음-; 그리고 마스터 사용자의 역할을 하고 프록시 클라이언트를 통해 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하면, 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정하도록, 구체적으로 구성된다.

이에 상응하여, 마스터 사용자의 역할을 하는 클라이언트의 수량이 0이 아니고 미리 정해진 상한치에 도달하지 않으면, 처리 유닛(902)은 제2 클라이언트의 역할이 부-마스터 사용자인 것으로 결정한다.

선택사항으로서, 본 실시예의 또 다른 구체적인 구현예로서, 제1 클라이언트가 주-마스터 사용자이고, 제2 클라이언트가 슬레이브 사용자인 경우, 수신 유닛(901)은, 제1 클라이언트로부터, 라이브 방송룸을 나가기 위한 요청 메시지를 수신하도록 추가적으로 구성된다. 처리 유닛(902)은, 제2 클라이언트를 새로운 부-마스터 사용자로 결정하는 경우, 제2 클라이언트의 역할을 슬레이브 사용자로부터 부-마스터 사용자로 변경하도록 추가적으로 구성된다. 저장 유닛은 수신되는 제2 라이브 미디어 스트림을 GOP로 캐시하도록 구성된다.

선택사항으로서, 본 실시예의 또 다른 구체적인 구현예로서, 제1 클라이언트가 주-마스터 사용자이고, 제2 클라이언트가 부-마스터 사용자인 경우, 저장 유닛은 수신되는 제2 라이브 미디어 스트림을 GOP로 캐시하도록 구성된다. 처리 유닛(902)은, 제1 라이브 미디어 스트림 및 캐시된 제2 라이브 미디어 스트림에 기초하여, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하도록 추가적으로 구성되며, 여기서 제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임이다.

선택사항으로서, 본 실시예의 또 다른 구체적인 구현예로서, 수신 유닛(901)은, 제1 클라이언트로부터, 라이브 방송룸을 나가기 위한 요청 메시지를 수신하도록 추가적으로 구성된다. 처리 유닛(902)은, 제2 클라이언트를 새로운 주-마스터 사용자로 결정하는 경우, 제1 I 프레임 및 제2 I 프레임에 기초하여, 서로 인접하고 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하도록; 그리고 제1 라이브 미디어 스트림을 제1 스위칭 프레임 및 제2 스위칭 프레임에 기초하여 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림으로 스위칭하도록 추가적으로 구성되며, 여기서, 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임은 제1 스위칭 프레임이고, 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 제2 스위칭 프레임이다.

선택사항으로서, 본 실시예의 또 다른 구체적인 구현예로서, 저장 유닛은 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림을 GOP로 캐시하도록 구성된다.

또한, 장치가 프록시 클라이언트인 경우, 수신 유닛(901)은 제1 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지, 및 제2 클라이언트에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신하도록 구성된다. 송신 유닛(903)은 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신하도록 구성된다. 수신 유닛(901)은 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하도록 추가적으로 구성되며, 여기서, 미디어 서버에 의해 프록시 서버를 통해 제1 클라이언트로 송신되는 제1 라이브 미디어 스트림은 미디어 스트림이고, 제1 클라이언트의 역할은 마스터 사용자이고, 그리고 제2 클라이언트의 역할은 슬레이브 사용자이다. 송신 유닛(903)은 제1 라이브 미디어 스트림을 제1 클라이언트 및 제2 클라이언트로 송신하도록 추가적으로 구성된다.

또한, 처리 유닛(902)은, 제1 라이브 방송룸 요청 메시지가 송신되기 전에, 프록시 클라이언트의 식별자를 제1 라이브 방송룸 요청 메시지에 추가하도록; 그리고 제2 라이브 방송룸 요청 메시지가 송신되기 전에, 프록시 클라이언트의 식별자를 제2 라이브 방송룸 요청 메시지에 추가하도록, 구성된다.

장치는, 제1 라이브 미디어 스트림을 GOP로 캐시하도록 구성되는, 저장 유닛을 더 포함한다.

선택사항으로서, 본 실시예의 구체적인 구현예로서, 처리 유닛(902)은, 제1 라이브 방송룸 요청 메시지가 수신되는 경우 제1 클라이언트의 역할을 작동으로 마킹하도록; 제2 라이브 방송룸 요청 메시지가 수신되는 경우 제2 클라이언트의 역할을 작동으로 마킹하도록; 그리고 라이브 방송룸을 나가기 위한 요청 메시지가 수신되는 경우 제1 클라이언트의 역할을 이탈로 마킹하도록, 추가적으로 구성된다.

선택사항으로서, 본 실시예의 구체적인 구현예로서, 처리 유닛(902)은, 제1 라이브 미디어 스트림이 제2 클라이언트로 송신되기 전에, 제1 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프가 0임을, 그리고 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 충족하도록, 추가적으로 구성된다.

선택사항으로서, 본 실시예의 구체적인 구현예로서, 제1 클라이언트가 라이브 방송룸을 나갈 것을 요청하는 경우, 수신 유닛(901)은 프록시 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신하도록 추가적으로 구성되며, 여기서 제2 라이브 미디어 스트림은 미디어 서버에 의해 프록시 클라이언트를 통해 제2 클라이언트로 송신되는 미디어 스트림이고, 제2 클라이언트는 슬레이브 사용자로부터 마스터 사용자로 역할이 변경되는 클라이언트이다. 송신 유닛(903)은 제2 라이브 미디어 스트림을 제2 클라이언트 및 제2 클라이언트로 송신하도록 추가적으로 구성된다.

선택사항으로서, 본 실시예의 구체적인 구현예로서, 처리 유닛(902)은, 제2 라이브 미디어 스트림이 제2 클라이언트로 송신되기 전에, 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임 및 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프는 연속적임을 충족하도록, 추가적으로 구성된다.

특정 하드웨어 구현예에서, 도 10에 도시된 바와 같이, 본 출원은 네트워크 디바이스를 추가로 제공한다. 네트워크 디바이스는 전술한 방법 실시예에서 프록시 서버 또는 프록시 클라이언트일 수 있거나, CDN 시스템의 다른 디바이스 또는 장치일 수 있다.

구체적으로, 네트워크 디바이스는 송수신기(10), 프로세서(20), 및 메모리(30)를 포함한다. 네트워크 디바이스는 대안적으로 더 많거나 더 적은 구성 요소를 포함할 수 있거나, 일부 구성 요소가 결합될 수 있거나, 구성 요소가 다르게 배열될 수 있다. 이는 본 출원에서 제한되지 않는다.

송수신기(10)는 요청 메시지, 응답 메시지, 라이브 미디어 스트림, 등을 수신 및 송신하도록, 그리고 네트워크 내의 다른 디바이스(클라이언트, 미디어 서버, 등)와 데이터 전송을 수행하도록 구성된다. 또한, 송수신기(10)는 수신기(1001), 송신기(1002), 및 안테나(1003)와 같은 구성 요소를 더 포함할 수 있거나, 송수신기 모듈을 더 포함할 수 있다. 또한, 송수신기 모듈은, 무선 근거리 네트워크(wireless local area network, WLAN) 모듈, 블루투스 모듈, 또는 기저 대역(baseband) 모듈과 같은 통신 모듈을 더 포함할 수 있고, 통신 모듈에 대응하는 무선 주파수(radio frequency, RF) 회로를 포함할 수 있으며, 여기서, 무선 주파수 회로는 무선 근거리 네트워크 통신, 블루투스 통신, 적외선 통신, 및/또는 셀룰러 통신 시스템 통신, 예를 들어, 광대역 코드 분할 다중 액세스(wideband code division multiple access, WCDMA) 및/또는 고속 다운링크 패킷 액세스(high speed downlink packet access, HSDPA)를 수행하도록 구성된다. 송수신기 모듈은 네트워크 디바이스 내의 구성 요소 사이의 통신을 제어하도록 구성되고, 직접 메모리 액세스(direct memory access)를 지원할 수 있다.

프로세서(20)는 네트워크 디바이스의 제어 센터로서, 다양한 인터페이스 및 라인을 통해 전체 네트워크 디바이스의 다양한 부분과 연결된다. 프로세서(20)는 메모리(30)에 저장된 소프트웨어 프로그램 및/또는 유닛을 실행 또는 실행하고, 메모리(30)에 저장된 데이터를 호출하여 네트워크 디바이스의 다양한 기능을 수행하거나 데이터를 처리한다.

또한, 프로세서(20)는 집적 회로(integrated circuit, IC)를 포함할 수 있으며, 예를 들어 단일 패키지 IC를 포함할 수 있거나, 동일한 기능 또는 상이한 기능을 가지는 복수의 연결된 패키지 IC를 포함할 수 있다. 예를 들어, 프로세서는 중앙 처리 장치(Central Processing Unit, CPU)만 포함하거나, GPU, 디지털 신호 프로세서(Digital Signal Processor, DSP), 및 송수신기의 (기저 대역 칩과 같은)제어 칩의 조합일 수 있다.

메모리(30)는 휘발성 메모리(volatile memory), 예를 들어, 랜덤 액세스 메모리(Random Access Memory, RAM)를 포함할 수 있거나; 또는 비휘발성 메모리(non-volatile memory), 예를 들어, 플래시 메모리(flash memory), 하드 디스크 드라이브(Hard Disk Drive, HDD), 또는 솔리드-스테이트 드라이브(Solid-State Drive, SSD)를 포함할 수 있다. 메모리는 전술한 유형의 메모리의 조합을 더 포함할 수 있다. 메모리는 프로그램이나 코드를 저장할 수 있다. 프로세서(20)는 통신 디바이스의 기능을 구현하기 위해 프로그램 또는 코드를 실행한다.

이 실시예에서, 네트워크 디바이스가 프록시 서버인 경우, 도 9에 도시된 장치 실시예의 수신 유닛(901) 및 송신 유닛(903)의 기능은 송수신기(10)에 의해 구현될 수 있거나, 프로세서(20)에 의해 제어되는 송수신기(10)에 의해 구현될 수 있다. 처리 유닛(902)의 기능은 프로세서(20)에 의해 구현될 수 있다. 저장 유닛의 기능은 메모리(30)에 의해 구현될 수 있다.

네트워크 디바이스가 프록시 클라이언트인 경우, 도 9에 도시된 장치 실시예의 수신 유닛(901) 및 송신 유닛(903)의 기능은 송수신기(10)에 의해 구현될 수 있거나, 프로세서(20)에 의해 제어되는 송수신기(10)에 의해 구현될 수 있다. 처리 유닛(902)의 기능은 프로세서(20)에 의해 구현될 수 있다. 저장 유닛의 기능은 메모리(30)에 의해 구현될 수 있다.

또한, 본 출원의 실시예는 미디어 스트림 송신 시스템을 추가로 제공한다. 이 시스템은 도 9에 도시된 미디어 스트림 송신 장치 또는 도 10에 도시된 네트워크 디바이스를 포함하고, 전술한 방법 실시예의 미디어 스트림 송신 방법을 구현하기 위해, 복수의 클라이언트, RDC, EDC, 및 컨텐츠 소스와 같은 디바이스를 더 포함한다.

선택사항으로서, 미디어 스트림 송신 시스템은 비디오 라이브 방송 시스템, 예를 들어, CDN 시스템이다.

또한, 본 출원은 컴퓨터 저장 매체를 추가로 제공한다. 컴퓨터 저장 매체는 프로그램을 저장할 수 있다. 프로그램이 실행되는 경우, 본 출원에서 제공되는 컨텐츠 송신 방법 및 컨텐츠 수신 방법의 실시예의 단계의 일부 또는 전부가 수행될 수 있다. 저장 매체는 자기 디스크, 광학 디스크, 읽기-전용 메모리 ROM, 랜덤 액세스 메모리 RAM, 등일 수 있다.

전술한 실시예의 전부 또는 일부는 소프트웨어, 하드웨어, 펌웨어, 또는 이들의 임의의 조합을 사용하여 구현될 수 있다. 기능을 구현하는데 소프트웨어가 사용되는 경우, 기능의 전부 또는 일부는 컴퓨터 프로그램 제품의 형태로 구현될 수 있다.

컴퓨터 프로그램 제품은 하나 이상의 컴퓨터 명령을 포함한다. 컴퓨터 프로그램이 컴퓨터 상에 로딩되어 실행되는 경우, 본 출원의 전술한 실시예에 따른 절차 또는 기능의 전부 또는 일부가 생성된다. 컴퓨터는 범용 컴퓨터, 전용 컴퓨터, 컴퓨터 네트워크, 또는 다른 프로그래밍 가능한 장치일 수 있다.

컴퓨터 명령은 컴퓨터-판독 가능한 저장 매체에 저장될 수 있거나, 컴퓨터-판독 가능한 저장 매체로부터 다른 컴퓨터-판독 가능한 저장 매체로 전송될 수 있다. 예를 들어, 컴퓨터 명령은 웹 사이트, 컴퓨터, 서버, 또는 데이터 센터로부터 다른 웹 사이트, 컴퓨터, 서버, 또는 데이터 센터로 유선 또는 무선 방식으로 전송될 수 있다.

본 명세서의 실시예에서 동일하거나 유사한 부분에 대해서는 서로를 참조한다. 특히, 미디어 스트림 송신 장치의 실시예는 기본적으로 방법 실시예와 유사하므로 간략히 설명한다. 관련 부분에 대해서는, 방법 실시예의 설명을 참조한다.

통상의 기술자는 필요한 일반 하드웨어 플랫폼에 추가되는 소프트웨어에 의해 본 발명의 실시예의 기술이 구현될 수 있음을 분명히 이해할 수 있다. 그러한 이해에 기초하여, 본 발명의 실시예의 기술적 해결 수단은 본질적으로 또는 기존 기술에 기여하는 부분은 소프트웨어 제품의 형태로 구현될 수 있다. 컴퓨터 소프트웨어 제품은, ROM/RAM과 같은 저장 매체, 자기 디스크, 또는 광학 디스크에 저장될 수 있고, (퍼스널 컴퓨터, 서버, 네트워크 디바이스, 등일 수 있는) 컴퓨터 디바이스에게 본 발명의 실시예 또는 실시예의 일부에서 설명된 방법을 수행하도록 지시하기 위한 다수의 명령을 포함한다.

본 명세서의 실시예에서 동일하거나 유사한 부분에 대해서는 서로를 참조한다. 특히, 동기 캐리어 주파수 신호 송신 장치 및 동기 캐리어 주파수 신호 수신 장치의 실시예는 기본적으로 방법 실시예와 유사하므로 간략히 설명한다. 관련 부분에 대해서는, 방법 실시예의 설명을 참조한다.

또한, 본 출원의 설명에서, "복수의"는 특별히 명시하지 않는 한 2개 이상을 의미한다. 또한, 본 출원의 실시예의 기술적 해결 수단의 명료한 설명의 편의상, "제1" 및 "제2"와 같은 용어는 동일한 객체 또는 기능 및 목적이 기본적으로 동일한 유사한 객체를 구별하기 위해 사용된다. "제1" 및 "제2"와 같은 용어가 수량 또는 실행 순서를 제한하지 않으며, "제1" 및 "제2"와 같은 용어가 명확한 차이를 나타내지 않음을 통상의 기술자는 이해할 수 있다.

본 출원의 전술한 구현예는, 본 출원의 보호 범위에 대한 어떠한 제한도 구성하지 않는다.

Claims

라이브 방송룸에 진입하는 클라이언트에게 라이브 미디어 스트림을 제공하기 위한 미디어 스트림 송신 방법으로서,
프록시 서버에 의해, 상기 라이브 방송룸 입장을 요청하는데 사용되고 동일한 프록시 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 수신하는 단계-여기서, 상기 제1 라이브 방송룸 요청 메시지는 제1 클라이언트로부터 온 것이고, 상기 제2 라이브 방송룸 요청 메시지는 제2 클라이언트로부터 온 것임-;
상기 프록시 서버에 의해, 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 송신되는 제1 라이브 미디어 스트림 및 상기 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림을 수신하는 단계;
상기 프록시 서버에 의해, 상기 제1 라이브 방송룸 요청 메시지에 기초하여 상기 제1 클라이언트의 역할을 결정하고, 상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할을 결정하는 단계; 및
상기 제1 클라이언트의 역할은 마스터 사용자이고, 상기 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정하는 경우, 상기 프록시 서버에 의해, 상기 제1 라이브 미디어 스트림만을 상기 프록시 클라이언트로 송신하여, 상기 프록시 클라이언트가 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신하도록 하는 단계;를 포함하는 미디어 스트림 송신 방법.
제1항에 있어서,
상기 제1 라이브 방송룸 요청 메시지는 상기 프록시 클라이언트의 식별자를 포함하고, 상기 제2 라이브 방송룸 요청 메시지는 상기 프록시 클라이언트의 식별자를 포함하며; 그리고
상기 방법은,
상기 프록시 서버에 의해 상기 제1 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자 및 상기 제2 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자에 기초하여, 상기 제1 라이브 방송룸 요청 메시지 및 상기 제2 라이브 방송룸 요청 메시지는 상기 동일한 프록시 클라이언트로부터 온 것임을 결정하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
제1항 또는 제2항에 있어서,
상기 프록시 서버에 의해, 상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할을 결정하는 단계는,
상기 제2 라이브 방송룸 요청 메시지가 수신되는 경우, 상기 프록시 서버에 의해, 상기 라이브 방송룸에서 역할이 마스터 사용자이고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트가 상기 라이브 방송룸 내에 있는지 여부를 결정하는 단계; 및
상기 라이브 방송룸에서 역할이 마스터 사용자이고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트가 상기 라이브 방송룸 내에 있으면, 상기 제2 클라이언트의 역할은 상기 슬레이브 사용자인 것으로 결정하는 단계;를 포함하는, 미디어 스트림 송신 방법.
제3항에 있어서,
상기 프록시 서버에 의해, 상기 제1 라이브 미디어 스트림을 상기 프록시 클라이언트로 송신하는 단계 이후에,
상기 프록시 서버에 의해, 상기 프록시 클라이언트에 의해 송신되는 그리고 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하는 단계-여기서, 상기 라이브 방송룸을 나가기 위한 요청 메시지는 상기 제1 클라이언트에게 상기 라이브 방송룸을 나갈 것을 요청하는데 사용됨-;
상기 제2 클라이언트를 새로운 마스터 사용자로 결정하는 경우, 상기 프록시 서버에 의해, 상기 제2 클라이언트의 역할을 상기 슬레이브 사용자로부터 마스터 사용자로 변경하는 단계; 및
상기 프록시 서버에 의해, 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 상기 제2 라이브 미디어 스트림으로 스위칭하는 단계;를 포함하는, 미디어 스트림 송신 방법.
제4항에 있어서,
상기 프록시 서버에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 프록시 서버에 의해 상기 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 인접한 프레임이고; 그리고
상기 상기 프록시 서버에 의해, 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 상기 제2 라이브 미디어 스트림으로 스위칭하는 단계 이전에, 상기 방법은,
상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 기초하여 상기 프록시 서버에 의해, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하는 단계-여기서, 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임임-;
상기 제1 I 프레임 및 상기 제2 I 프레임에 기초하여 상기 프록시 서버에 의해, 서로 인접하고 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하고, 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임을 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임으로 각각 사용하는 단계;를 포함하고, 그리고
상기 프록시 서버가 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임을 결정한 후, 상기 방법은,
상기 프록시 서버에 의해, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 상기 제1 클라이언트로부터 상기 미디어 서버로 포워딩하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
제1항 또는 제2항에 있어서,
상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할을 결정하는 단계는,
상기 제2 라이브 방송룸 요청 메시지가 수신되는 경우, 상기 프록시 서버에 의해, 마스터 사용자의 역할을 하고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하는지 여부를 결정하는 단계-여기서, 상기 미리 정해진 상한치는 2보다 크거나 같음-; 및
상기 마스터 사용자의 역할을 하고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트의 수량이 상기 미리 정해진 상한치에 도달하면, 상기 제2 클라이언트의 역할은 상기 슬레이브 사용자인 것으로 결정하는 단계;를 포함하는, 미디어 스트림 송신 방법.
제6항에 있어서,
상기 라이브 방송룸에서 마스터 사용자의 역할을 하는 클라이언트의 수량이 0이 아니고 상기 미리 정해진 상한치에 도달하지 않으면, 상기 제2 클라이언트의 역할은 부-마스터 사용자인 것으로 결정하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
제6항에 있어서,
상기 제1 클라이언트가 주-마스터 사용자이고, 상기 제2 클라이언트가 슬레이브 사용자인 경우, 상기 방법은, ~를 더 포함한다:
상기 프록시 서버에 의해 상기 제1 클라이언트로부터, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하는 단계;
상기 제2 클라이언트를 새로운 부-마스터 사용자로 결정하는 경우, 상기 프록시 서버에 의해, 상기 제2 클라이언트의 역할을 상기 슬레이브 사용자로부터 부-마스터 사용자로 변경하는 단계; 및
상기 프록시 서버에 의해, 상기 수신되는 제2 라이브 미디어 스트림을 화상 그룹 GOP으로 캐시하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
제7항에 있어서,
상기 제1 클라이언트가 주-마스터 사용자이고, 상기 제2 클라이언트가 부-마스터 사용자인 경우,
상기 프록시 서버에 의해, 상기 수신되는 제2 라이브 미디어 스트림을 GOP로 캐시하는 단계; 및
상기 제1 라이브 미디어 스트림 및 상기 캐시된 제2 라이브 미디어 스트림에 기초하여 상기 프록시 서버에 의해, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하는 단계-여기서, 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임임;를 더 포함하는, 미디어 스트림 송신 방법.
제9항에 있어서,
상기 프록시 서버에 의해 상기 제1 클라이언트로부터, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하는 단계;
상기 제2 클라이언트를 새로운 주-마스터 사용자로 결정하는 경우, 상기 프록시 서버에 의해, 상기 제2 클라이언트의 역할을 상기 부-마스터 사용자로부터 주-마스터 사용자로 변경하는 단계;
상기 제1 I 프레임 및 상기 제2 I 프레임에 기초하여 상기 프록시 서버에 의해, 서로 인접하고 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결저하는 단계; 및
상기 프록시 서버에 의해, 상기 제2 클라이언트으로 송신되는 상기 제1 라이브 미디어 스트림을, 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임에 기초하여 상기 제2 라이브 미디어 스트림으로 스위칭하는 단계-여기서, 상기 프록시 서버에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임은 상기 제1 스위칭 프레임이고, 상기 프록시 서버에 의해 상기 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 상기 제2 스위칭 프레임임-;를 더 포함하는, 미디어 스트림 송신 방법.
제1항 내지 제10항 중 어느 한 항에 있어서,
상기 프록시 서버에 의해, 상기 제1 라이브 미디어 스트림을 GOP에 의해 캐시하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
라이브 방송룸에 진입하는 클라이언트에 대해 라이브 미디어 스트림을 제공하기 위한 미디어 스트림 송신 방법으로서,
프록시 클라이언트에 의해, 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제1 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지, 및 상기 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제2 클라이언트에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신하는 단계;
상기 프록시 클라이언트에 의해, 상기 제1 라이브 방송룸 요청 메시지 및 상기 제2 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신하는 단계;
상기 프록시 클라이언트에 의해, 상기 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하는 단계-여기서, 상기 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 송신되는 제1 라이브 미디어 스트림은 미디어 스트림이고, 상기 제1 클라이언트의 역할은 마스터 사용자이고, 상기 제2 클라이언트의 역할은 슬레이브 사용자임-; 및
상기 프록시 클라이언트에 의해, 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신하는 단계;를 포함하는, 미디어 스트림 송신 방법.
제12항에 있어서,
상기 프록시 클라이언트에 의해, 상기 제1 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신하는 단계 이전에, 상기 프록시 클라이언트에 의해, 상기 프록시 클라이언트의 식별자를 상기 제1 라이브 방송룸 요청 메시지에 추가하는 단계를 더 포함하고; 그리고
상기 프록시 클라이언트에 의해, 상기 제2 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신하는 단계 이전에, 상기 프록시 클라이언트에 의해, 상기 프록시 클라이언트의 상기 식별자를 상기 제2 라이브 방송룸 요청 메시지에 추가하는 단계를 더 포함하는, 미디어 스트림 송신 방법.
제12항 또는 제13항에 있어서,
상기 상기 프록시 클라이언트에 의해, 상기 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하는 단계 이후에,
상기 프록시 클라이언트에 의해, 상기 제1 라이브 미디어 스트림을 화상 그룹 GOP으로 캐시하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
제12항 내지 제14항 중 어느 한 항에 있어서,
상기 프록시 클라이언트에 의해, 상기 제1 라이브 미디어 스트림을 상기 제2 클라이언트로 송신하는 단계 이전에,
상기 프록시 클라이언트에 의해, 상기 제1 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 상기 프록시 클라이언트에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프가 0임을, 그리고 상기 프록시 클라이언트에 의해 상기 제2 클라이언트로 송신되는 상기 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 충족하도록 하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
제12항 내지 제15항 중 어느 한 항에 있어서,
상기 제1 클라이언트가 상기 라이브 방송룸을 나갈 것을 요청하는 경우,
상기 프록시 클라이언트에 의해, 상기 프록시 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신하는 단계-여기서, 상기 제2 라이브 미디어 스트림은 상기 미디어 서버에 의해 상기 프록시 클라이언트를 통해 상기 제2 클라이언트로 송신되는 미디어 스트림이고, 상기 제2 클라이언트는 상기 슬레이브 사용자로부터 마스터 사용자로 역할이 변경되는 클라이언트임-; 및
상기 프록시 클라이언트에 의해, 상기 제2 라이브 미디어 스트림을 상기 제2 클라이언트로 송신하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
제16항에 있어서,
상기 프록시 클라이언트에 의해, 상기 제2 라이브 미디어 스트림을 상기 제2 클라이언트로 송신하는 단계 이전에,
상기 프록시 클라이언트에 의해, 상기 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 상기 프록시 클라이언트에 의해 상기 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임 및 상기 프록시 클라이언트에 의해 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 충족하도록 하는 단계;를 더 포함하는, 미디어 스트림 송신 방법.
미디어 스트림 송신 장치로서,
상기 라이브 방송룸 입장을 요청하는데 사용되고 동일한 프록시 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지 및 제2 라이브 방송룸 요청 메시지를 수신하도록 구성되는 수신 유닛-여기서, 상기 제1 라이브 방송룸 요청 메시지는 제1 클라이언트로부터 온 것이고, 상기 제2 라이브 방송룸 요청 메시지는 제2 클라이언트로부터 온 것이며, 여기서,
상기 수신 유닛은 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 송신되는 제1 라이브 미디어 스트림 및 상기 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림을 수신하도록 추가적으로 구성됨-;
상기 제1 라이브 방송룸 요청 메시지에 기초하여 상기 제1 클라이언트의 역할을 결정하도록, 그리고 상기 제2 라이브 방송룸 요청 메시지에 기초하여 상기 제2 클라이언트의 역할하도록 구성되는 처리 유닛; 및
상기 제1 클라이언트의 역할이 마스터 사용자이고 상기 제2 클라이언트의 역할은 슬레이브 사용자인 것으로 결정되는 경우, 상기 제1 라이브 미디어 스트림만을 상기 프록시 클라이언트로 송신하여, 상기 프록시 클라이언트가 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신하도록 구성되는 송신 유닛;을 포함하는, 미디어 스트림 송신 장치.
제18항에 있어서,
상기 제1 라이브 방송룸 요청 메시지는 상기 프록시 클라이언트의 식별자를 포함하고, 상기 제2 라이브 방송룸 요청 메시지는 상기 프록시 클라이언트의 식별자를 포함하며; 그리고
상기 처리 유닛은, 상기 제1 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자 및 상기 제2 라이브 방송룸 요청 메시지에 포함된 프록시 클라이언트의 식별자에 기초하여, 상기 제1 라이브 방송룸 요청 메시지 및 상기 제2 라이브 방송룸 요청 메시지는 상기 동일한 프록시 클라이언트로부터 온 것임을 결정하도록 추가적으로 구성되는, 미디어 스트림 송신 장치.
제18항 또는 제19항에 있어서,
상기 처리 유닛은, 상기 제2 라이브 방송룸 요청 메시지가 수신되는 경우, 상기 라이브 방송룸에서 역할이 마스터 사용자이고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트가 상기 라이브 방송룸 내에 있는지 여부를 결정하도록; 그리고 상기 라이브 방송룸에서 역할이 마스터 사용자이고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트가 상기 라이브 방송룸 내에 있으면, 상기 제2 클라이언트의 역할은 상기 슬레이브 사용자인 것으로 결정하도록, 구체적으로 구성되는, 미디어 스트림 송신 장치.
제20항에 있어서,
상기 수신 유닛은, 상기 제1 라이브 미디어 스트림이 상기 프록시 클라이언트로 송신된 후, 상기 프록시 클라이언트에 의해 송신되는 그리고 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하도록 추가적으로 구성되고-여기서, 상기 라이브 방송룸을 나가기 위한 요청 메시지는 상기 제1 클라이언트에게 상기 라이브 방송룸을 나갈 것을 요청하는데 사용됨-; 및
상기 처리 유닛은, 상기 제2 클라이언트를 새로운 마스터 사용자로 결정하는 경우, 상기 제2 클라이언트의 역할을 상기 슬레이브 사용자로부터 마스터 사용자로 변경하도록; 그리고 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 상기 제2 라이브 미디어 스트림으로 스위칭하도록, 추가적으로 구성되는, 미디어 스트림 송신 장치.
제21항에 있어서,
상기 제2 클라이언트에 의해 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제2 클라이언트에 의해 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 인접한 프레임이고; 그리고
상기 처리 유닛은, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 기초하여, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하도록-여기서, 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임임-; 상기 제1 I 프레임 및 상기 제2 I 프레임에 기초하여, 서로 인접하고 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하도록, 그리고 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임을 상기 제2 클라이언트에 의해 송신되는 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제1 클라이언트에 의해 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임으로 각각 사용하도록, 추가적으로 구성되고; 그리고
상기 송신 유닛은, 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임이 결정된 후, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 상기 제1 클라이언트로부터 상기 미디어 서버로 포워딩하도록 추가적으로 구성되는, 미디어 스트림 송신 장치.
제18항 또는 제19항에 있어서,
상기 처리 유닛은, 상기 제2 라이브 방송룸 요청 메시지가 수신되는 경우, 마스터 사용자의 역할을 하고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트의 수량이 미리 정해진 상한치에 도달하는지 여부를 결정하도록-여기서, 상기 미리 정해진 상한치는 2보다 크거나 같음-; 그리고 상기 마스터 사용자의 역할을 하고 상기 프록시 클라이언트를 통해 상기 라이브 방송룸에 진입하는 클라이언트의 수량이 상기 미리 정해진 상한치에 도달하면, 상기 제2 클라이언트의 역할은 상기 슬레이브 사용자인 것으로 결정하도록, 구체적으로 구성되는, 미디어 스트림 송신 장치.
제23항에 있어서,
상기 처리 유닛은, 상기 라이브 방송룸에서 마스터 사용자의 역할을 하는 클라이언트의 수량이 0이 아니고 상기 미리 정해진 상한치에 도달하지 않으면, 상기 제2 클라이언트의 역할은 부-마스터 사용자인 것으로 결정하도록 추가적으로 구성되는, 미디어 스트림 송신 장치.
제23항에 있어서,
저장 유닛을 더 포함하되,
상기 제1 클라이언트가 주-마스터 사용자이고, 상기 제2 클라이언트가 슬레이브 사용자인 경우,
상기 수신 유닛은, 상기 제1 클라이언트로부터, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하도록 추가적으로 구성되고;
상기 처리 유닛은 상기 제2 클라이언트를 새로운 부-마스터 사용자로 결정하는 경우, 상기 제2 클라이언트의 역할을 상기 슬레이브 사용자로부터 부-마스터 사용자로 변경하도록 추가적으로 구성되고; 그리고
상기 저장 유닛은 상기 수신되는 제2 라이브 미디어 스트림을 화상 그룹 GOP로 캐시하도록 구성되는, 미디어 스트림 송신 장치.
제24항에 있어서,
저장 유닛을 더 포함하되,
상기 제1 클라이언트가 주-마스터 사용자이고, 상기 제2 클라이언트가 부-마스터 사용자인 경우,
상기 저장 유닛은 상기 수신되는 제2 라이브 미디어 스트림을 GOP로 캐시하도록 구성되고; 그리고
상기 처리 유닛은, 상기 제1 라이브 미디어 스트림 및 상기 캐시된 제2 라이브 미디어 스트림에 기초하여, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 I 프레임 및 제2 I 프레임을 식별하도록 추가적으로 구성되는-여기서, 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임임-, 미디어 스트림 송신 장치.
제26항에 있어서,
상기 수신 유닛은, 상기 제1 클라이언트로부터, 상기 라이브 방송룸을 나가기 위한 요청 메시지를 수신하도록 추가적으로 구성되고; 그리고
상기 처리 유닛은, 상기 제2 클라이언트를 새로운 주-마스터 사용자로 결정하는 경우, 상기 제2 클라이언트의 역할을 상기 부-마스터 사용자로부터 주-마스터 사용자로 변경하도록; 상기 제1 I 프레임 및 상기 제2 I 프레임에 기초하여, 서로 인접하고 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 각각 속하는 제1 스위칭 프레임 및 제2 스위칭 프레임을 결정하도록; 그리고 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림을 상기 제1 스위칭 프레임 및 상기 제2 스위칭 프레임에 기초하여 상기 제2 라이브 미디어 스트림으로 스위칭하도록, 추가적으로 구성되고,
여기서, 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임은 상기 제1 스위칭 프레임이고, 상기 제1 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임은 상기 제2 스위칭 프레임인, 미디어 스트림 송신 장치.
제18항 내지 제27항 중 어느 한 항에 있어서,
상기 제1 라이브 미디어 스트림을 GOP로 캐시하도록 구성되는 저장 유닛;을 더 포함하는, 미디어 스트림 송신 장치.
미디어 스트림 송신 장치로서,
라이브 방송룸에 진입할 것을 요청하는데 사용되고 제1 클라이언트에 의해 송신되는 제1 라이브 방송룸 요청 메시지, 및 상기 라이브 방송룸에 진입할 것을 요청하는데 사용되고 제2 클라이언트에 의해 송신되는 제2 라이브 방송룸 요청 메시지를 수신하도록 구성되는 수신 유닛; 및
상기 제1 라이브 방송룸 요청 메시지 및 상기 제2 라이브 방송룸 요청 메시지를 프록시 서버를 통해 미디어 서버로 송신하도록 구성되는 송신 유닛;을 포함하되,
상기 수신 유닛은 상기 프록시 서버에 의해 송신되는 제1 라이브 미디어 스트림을 수신하도록 추가적으로 구성되고-여기서, 상기 미디어 서버에 의해 상기 프록시 서버를 통해 상기 제1 클라이언트로 송신되는 제1 라이브 미디어 스트림은 미디어 스트림이고, 상기 제1 클라이언트의 역할은 마스터 사용자이고, 상기 제2 클라이언트의 역할은 슬레이브 사용자임-; 그리고
상기 송신 유닛은 상기 제1 라이브 미디어 스트림을 상기 제1 클라이언트 및 상기 제2 클라이언트로 송신하도록 추가적으로 구성되는, 미디어 스트림 송신 장치.
제29항에 있어서,
처리 유닛을 더 포함하되,
상기 처리 유닛은, 상기 제1 라이브 방송룸 요청 메시지가 송신되기 전에, 상기 프록시 클라이언트의 식별자를 상기 제1 라이브 방송룸 요청 메시지에 추가하도록; 그리고 상기 제2 라이브 방송룸 요청 메시지가 송신되기 전에, 상기 프록시 클라이언트의 상기 식별자를 상기 제2 라이브 방송룸 요청 메시지에 추가하도록 구성되는, 미디어 스트림 송신 장치.
제29항 또는 제30항에 있어서,
저장 유닛을 더 포함하되,
상기 저장 유닛은 상기 제1 라이브 미디어 스트림을 화상 그룹 GOP로 캐시하도록 구성되는, 미디어 스트림 송신 장치.
제29항 내지 제31항 중 어느 한 항에 있어서,
상기 처리 유닛은, 상기 제1 라이브 미디어 스트림이 상기 제2 클라이언트로 송신되기 전에, 상기 제1 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 첫 번째 프레임의 타임스탬프가 0임을, 그리고 상기 제2 클라이언트로 송신되는 상기 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 충족하도록 구성되는, 미디어 스트림 송신 장치.
제29항 내지 제32항 중 어느 한 항에 있어서,
상기 제1 클라이언트가 상기 라이브 방송룸을 나갈 것을 요청하는 경우,
상기 수신 유닛은 상기 프록시 서버에 의해 송신되는 제2 라이브 미디어 스트림을 수신하도록 추가적으로 구성되고-여기서, 상기 제2 라이브 미디어 스트림은 상기 미디어 서버에 의해 상기 프록시 클라이언트를 통해 상기 제2 클라이언트로 송신되는 미디어 스트림이고, 상기 제2 클라이언트는 상기 슬레이브 사용자로부터 마스터 사용자로 역할이 변경되는 클라이언트임-; 그리고
상기 송신 유닛은 상기 제2 라이브 미디어 스트림을 상기 제2 클라이언트 및 상기 제2 클라이언트로 송신하도록 추가적으로 구성되는, 미디어 스트림 송신 장치.
제33항에 있어서,
상기 처리 유닛은, 상기 제2 라이브 미디어 스트림이 상기 제2 클라이언트로 송신되기 전에, 상기 제2 라이브 미디어 스트림의 타임스탬프를 조정하여, 조정된 타임스탬프는, 상기 제2 클라이언트로 송신되는 제2 라이브 미디어 스트림의 첫 번째 프레임 및 상기 제2 클라이언트로 송신되는 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 충족하도록 추가적으로 구성되는, 미디어 스트림 송신 장치.
적어도 하나의 클라이언트, 프록시 클라이언트, 프록시 서버, 및 미디어 서버를 포함하는 미디어 스트림 송신 시스템으로서,
각각의 클라이언트는 상기 프록시 클라이언트를 통해 라이브 방송룸에 액세스하고;
상기 프록시 클라이언트는 제12항 내지 제17항 중 어느 한 항에 따른 미디어 스트림 송신 방법을 수행하도록 구성되고; 그리고
상기 프록시 서버는 제1항 내지 제11항 중 어느 한 항에 따른 미디어 스트림 송신 방법을 수행하도록 구성되는, 미디어 스트림 송신 시스템.
메모리에 연결되는 프로세서를 포함하는 네트워크 디바이스로서,
상기 메모리는 명령을 저장하도록 구성되고; 그리고
상기 프로세서는 상기 메모리에 저장된 명령을 실행하여, 상기 네트워크 디바이스가 제1항 내지 제17항 중 어느 한 항에 따른 방법을 수행하도록 구성되는, 네트워크 디바이스.
명령을 저장하는 컴퓨터-판독 가능한 저장 매체로서,
상기 명령이 실행되는 경우, 제1항 내지 제17항 중 어느 한 항에 따른 방법이 구현되는, 컴퓨터-판독 가능한 저장 매체.