KR102525289B1 - 미디어 스트림 발신 방법과 장치 및 디바이스 - Google Patents

미디어 스트림 발신 방법과 장치 및 디바이스 Download PDF

Info

Publication number
KR102525289B1
KR102525289B1 KR1020217020731A KR20217020731A KR102525289B1 KR 102525289 B1 KR102525289 B1 KR 102525289B1 KR 1020217020731 A KR1020217020731 A KR 1020217020731A KR 20217020731 A KR20217020731 A KR 20217020731A KR 102525289 B1 KR102525289 B1 KR 102525289B1
Authority
KR
South Korea
Prior art keywords
client
live
media stream
proxy server
media
Prior art date
Application number
KR1020217020731A
Other languages
English (en)
Other versions
KR20210094081A (ko
Inventor
나이퀴앙 퀴아오
시아 주
준 조우
퀴 부
Original Assignee
후아웨이 테크놀러지 컴퍼니 리미티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 후아웨이 테크놀러지 컴퍼니 리미티드 filed Critical 후아웨이 테크놀러지 컴퍼니 리미티드
Publication of KR20210094081A publication Critical patent/KR20210094081A/ko
Application granted granted Critical
Publication of KR102525289B1 publication Critical patent/KR102525289B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2743—Video hosting of uploaded data from client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47208—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting near-video-on-demand content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/50—Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5027—Dropping a party from a conference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/50—Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5045—Selection of bridge/multipoint control unit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/50—Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5081—Inform conference party of participants, e.g. of change of participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2183—Cache memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

미디어 스트림 발신 방법과 장치 및 디바이스가 개시된다. 방법은 라이브 브로드캐스트 룸에 입장하는 클라이언트를 위해 라이브 미디어 스트림을 제공한다. 방법은 다음을 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 제1 클라이언트로부터 수신함; 프록시 서버는 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 제1 클라이언트의 역할을 판정함; 제1 클라이언트의 역할이 슬레이브 사용자인 경우, 프록시 서버는 제1 클라이언트에 프록시 서버 내에 캐싱된 제1 라이브 미디어 스트림을 발신하되, 제1 라이브 미디어 스트림은 프록시 서버를 통해서 제2 클라이언트에 미디어 서버에 의해 발신된 미디어 스트림이고, 제2 클라이언트의 역할은 마스터 사용자임. 이 방법에 따르면, 미디어 서버는 프록시 서버에 오직 하나의 라이브 미디어 스트림을 발신할 필요가 있고, 프록시 서버는 라이브 미디어 스트림을 복제하고 라이브 브로드캐스트 룸 내에서 슬레이브 사용자로서 이바지하는 모든 클라이언트에 전달할 수 있다. 이것은 미디어 스트림을 발신하기 위한 트래픽을 감소시키고, 이출 대역폭을 효과적으로 절감하며, 리소스 오버헤드를 감소시킨다.

Description

미디어 스트림 발신 방법과 장치 및 디바이스
이 출원은 비디오 재생(video playing) 분야에 관련되고, 특히 미디어 스트림(media stream) 발신 방법과 장치 및 디바이스에 관련된다.
사용자는 라이브 브로드캐스트 모드(live broadcast mode) 또는 주문형 비디오 모드(video on demand mode)에서 비디오를 관람할(watch) 수 있다. 주문형 비디오 모드에서는, 비디오를 관람하는 경우에, 사용자가 언제든지 비디오 콘텐트(video content)를 빨리 감기(fast forward) 또는 되감기(rewind)할 수 있으나, 라이브 브로드캐스트 모드에서는 비디오 콘텐트를 빨리감기하거나 되감기할 수 없다. 라이브 브로드캐스트는 일반적으로 데이터의 모든 프레임이 시간 순차 태그(time sequence tag)로써 라벨링되고(labelled) 이후에 스트리밍되는(streamed) 프로세스로서 이해될 수 있다. 구체적으로, 카메라 또는 마이크와 같은 수집 장치는 오디오 또는 비디오 정보를 계속해서 수집하고, 이후에 정보에 대해 인코딩(encoding), 캡슐화(encapsulation) 및 스트림 푸싱(stream pushing)과 같은 처리를 수행하고, 이후에 전달 네트워크(delivery network)를 통해서 정보를 송신한다. 재생단(playing end)은 데이터를 계속해서 다운로드하고, 재생을 위해 시간 순차에 기반하여 데이터를 디코딩한다(decode). 비디오 라이브 브로드캐스트의 전반적인 절차는 일련의 프로세스를 포함한다: 수집, 인코딩, 스트림 푸싱, 트랜스코딩(transcoding), 전달, 디코딩/렌더링(rendering) 및 유사한 것.
인터넷 비디오 라이브 브로드캐스트의 주류적인 벤더(vendor)는 통상적으로 비디오 송신을 위해 유니캐스트(unicast) 송신 프로토콜을 사용한다. 따라서, 만일 N명의 사용자가 비디오를 관람하는 경우, 비디오 스트림의 채널이 N개 있다. 추가로, 기업(enterprise) 라이브 비디오 브로드캐스트를 위해, 제시되는 서류를 공유하는 것 및 텍스트 코멘트(text comment)를 행하는 것과 같은 기능이 비디오 라이브 브로드캐스트 동안 지원될 필요가 있다. 즉, 사용자 요구사항을 만족시키고 사용자 경험을 개선하기 위해, 공유되는 서류 및 텍스트 코멘트는 비디오 콘텐트가 기업 라이브 브로드캐스트의 웹 페이지(web page) 상에 디스플레이되는 동안에 디스플레이된다.
사용자 경험을 개선하고 백본(backbone) 네트워크 대역폭을 절감하기 위해, 라이브 브로드캐스트 플랫폼 상에 전형적으로 라이브 콘텐트 전달 네트워크(content delivery network, CDN)가 배치된다. 라이브 CDN은 분산형(distributed) 콘텐트 전달 플랫폼이며 다층 아키텍처(multi-layer architecture)를 지원한다. 라이브 CDN 플랫폼 상에서, 상이한 구역 내의 사용자를 위해 인근에서의 서비스를 제공하기 위해, 캐싱(caching)을 위한 서버가 상이한 계층에 배치될 수 있다.
라이브 CDN을 사용함으로써 오디오 및 비디오 스트림을 전달하는 프로세스에서, 실시간 메시지 프로토콜(real time messaging protocol, RTMP)(또한 실시간 메시지 송출 프로토콜(real time message transport protocol)로 지칭됨)이 비디오 스트림 푸싱 및 스트림 분배(stream distribution) 프로세스에서 전형적으로 사용되고; 전달 프로세스에서 3개의 프로토콜이 전형적으로 사용된다: RTMP, HLS(HTTP live streaming)(HTTP 라이브 스트리밍) 프로토콜 및 하이퍼텍스트 이송 프로토콜(hyper text transfer protocol, HTTP)-플래시 비디오(flash video, FLV), 여기서 하이퍼텍스트 이송 프로토콜-플래시 비디오는 줄여서 "HTTP-FLV"로 지칭됨. HLS는 애플 사(Apple Inc.)에 의해 개발된 HTTP 기반 스트리밍 미디어 송신 프로토콜이다. HLS는 오디오 및 비디오 라이브 서비스 및 기록된 콘텐트(VOD) 서비스를 제공하기 위해, 아이폰(iPhone), 아이패드(iPad), 아이팟 터치(iPod touch) 및 맥 OS X(Mac OS X)를 포함하여, iOS 디바이스에 주로 적용된다. HLS는 다음의 이점을 갖는다: HLS를 사용함으로써, 클라이언트는 한 번에 완전한 데이터 스트림을 요청하지 않고; 대신에, 스트리밍 미디어 데이터는 서버단(server end)에서 더 짧은 지속기간(duration)을 가진 더 작은 파일로 세그먼트화되고(segmented) 더 작은 파일은 인덱스(index) 파일에 기반하여 순차로 액세스된다. 클라이언트(client)가 서버로부터 획득된 더 작은 파일을 계속적으로 및 순차적으로 재생한다면 오디오 및 비디오가 재생될 수 있다.
도 1에 도시된 바와 같이, 라이브 CDN에서, 콘텐트 소스(content source)는 RTMP를 사용하여 기업 데이터 센터(enterprise data center, EDC)에 오디오 및 비디오 미디어 스트림을 발신하는데, EDC는 웹 서버(Web server) 및 복수의 미디어 서버(media server)를 포함한다. EDC 내의 웹 서버는 라이브 프로그램을 관람하기 위한, 클라이언트로부터의 요청에 응답하고, 사용자를 인증하며, 사용자의 위치에 기반하여 사용자를 위해 서비스를 제공하기 위해 가장 가까운 미디어 서버를 할당한다. 선택된 미디어 서버는 사전설정된 정책에 따라 하위 레벨(lower-level) 구역 데이터 센터(region data center, RDC)에 오디오 및 비디오 미디어 스트림을 발신한다. 미디어 스트림(라이브 콘텐트)를 수신한 후에, RDC 내의 미디어 서버는, 사전설정된 정책에 따라, 미디어 스트림을 서버 룸(server room, SR) 내의 하위 레벨 미디어 서버에 전달한다. 최종적으로, 서버 룸 내의 미디어 서버는 상위 레벨(upper-level) 미디어 서버에 의해 전달된 미디어 스트림(라이브 콘텐트)를 캐싱하고, 직접적으로 사용자를 위해 라이브 브로드캐스트 서비스를 제공한다.
이 프로세스에서, 상위 레벨 RDC 내의 미디어 서버는 라이브 브로드캐스트 룸 내에서 미디어 스트림을 요청하는 각각의 클라이언트에 라이브 미디어 스트림을 발신할 필요가 있어서, 상위 레벨 RDC 내의 미디어 서버는 라이브 브로드캐스트 룸 내의 각각의 사용자에 라이브 미디어 스트림을 발신할 필요가 있다. 라이브 브로드캐스트 룸에 입장하는 많은 수효의 사용자가 있는 경우에, 라이브 미디어 스트림 송신을 위해 대량의 광역 네트워크(wide area network, WAN) 리소스가 요구되는바, 과중한 네트워크 오버헤드(overhead)를 초래한다.
동일한 라이브 브로드캐스트 룸(live broadcast room) 내의 클라이언트에 미디어 서버에 의해 미디어 스트림을 발신하기 위한 리소스 오버헤드를 감소시키기 위해, 이 출원의 실시예는 미디어 스트림 발신 방법과 장치 및 디바이스를 제공한다. 구체적으로, 이 출원의 실시예는 다음의 기술적 해결안을 개시한다.
제1 측면에 따르면, 이 출원의 실시예는 미디어 스트림 발신 방법을 제공한다: 방법은 라이브 브로드캐스트 룸에 입장하는 클라이언트를 위해 라이브 미디어 스트림(live media stream)을 제공한다. 방법은 다음을 포함한다: 프록시 서버(proxy server)는 라이브 브로드캐스트 룸에 입장하기(enter)를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 제1 클라이언트로부터 수신하고; 프록시 서버는 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 제1 클라이언트의 역할을 판정하고; 만일 제1 클라이언트의 역할이 슬레이브(slave) 사용자인 경우, 프록시 서버는 제1 클라이언트에 프록시 서버 내에 캐싱된(cached) 제1 라이브 미디어 스트림을 발신하는데, 제1 라이브 미디어 스트림은 프록시 서버를 통해서 제2 클라이언트에 미디어 서버에 의해 발신된 미디어 스트림이고, 제2 클라이언트의 역할은 마스터(master) 사용자이다.
이 방법에서, 마스터 사용자가 역할인 클라이언트에 의해 요청된 라이브 미디어 스트림이 프록시 서버에 의해 획득된 경우에, 프록시 서버는 미디어 스트림의 일부의 세그먼트(segment)를 로컬로(locally) 캐싱한다. 슬레이브 사용자가 역할인 클라이언트가 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 요청하는 경우에, 프록시 서버는 로컬로 캐싱된 미디어 스트림을 슬레이브 사용자가 역할인 클라이언트에 직접적으로 발신하여서, 미디어 서버는 다시 프록시 서버에 라이브 미디어 스트림을 발신할 필요가 없다. 따라서, 이 출원의 제1 측면에서 제공되는 방법에 따르면, 미디어 서버는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 각각의 클라이언트에 라이브 미디어 스트림을 발신할 필요가 없다. 이것은 미디어 스트림을 발신하기 위한 트래픽(traffic)을 감소시키고, 이출(egress) 대역폭을 효과적으로 절감하며, 리소스 오버헤드를 감소시킨다.
제1 측면을 참조하여, 제1 측면의 가능한 구현에서, 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 제1 클라이언트의 역할을 판정하는 것은 다음을 포함한다: 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는지를 판정하는 것; 및 만일 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는 경우, 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하는 것.
제1 측면을 참조하여, 제1 측면의 다른 가능한 구현에서, 프록시 서버 내에 캐싱된 제1 라이브 미디어 스트림을 제1 클라이언트에 발신하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는 제1 클라이언트로부터 제1 미디어 요청 메시지를 수신하고, 미디어 서버에 제1 미디어 요청 메시지를 전송하는 것을 생략하고; 프록시 서버는 제1 클라이언트에 제1 미디어 응답 메시지를 발신하는데, 제1 미디어 응답 메시지는 제1 클라이언트가 미디어 스트림을 획득하도록 허용됨을 제1 클라이언트에 통지하는 데에 사용된다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제1 미디어 요청 메시지는 제1 클라이언트의 식별자(identifier)를 포함한다. 프록시 서버가 제1 클라이언트에 제1 라이브 미디어 스트림을 발신한 후에, 방법은 다음을 더 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기(exiting) 위한 요청 메시지를 제2 클라이언트로부터 수신하고; 제1 클라이언트를 새로운 마스터 사용자로서 판정하는 경우에, 프록시 서버는 제1 클라이언트의 역할을 슬레이브 사용자로부터 마스터 사용자로 변경하고; 프록시 서버는 미디어 서버에 제2 미디어 요청 메시지를 발신하되, 제2 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함하고; 프록시 서버는 제2 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제2 라이브 미디어 스트림을 수신하고; 프록시 서버는 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 전환한다(switch).
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 제1 클라이언트의 역할을 판정하는 것은 다음을 포함한다: 프록시 서버는 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하는 경우에 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는지를 판정하되, 사전설정된 상한은 1보다 크고; 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는 경우, 프록시 서버는 제1 클라이언트의 역할이 슬레이브 사용자임을 판정한다. 이 구현에서, 복수의 마스터 사용자가 있는 시나리오에서, 미디어 서버는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 각각의 사용자를 위해 프록시 서버에 라이브 미디어 스트림을 발신할 필요가 없으나, 프록시 서버는, 마스터 사용자에 의해 요청되고 프록시 서버에 캐싱된 라이브 미디어 스트림을, 슬레이브 사용자가 역할인 클라이언트에 전달한다. 이것은 미디어 스트림을 발신하기 위한 트래픽을 감소시키고 리소스 오버헤드를 감소시킨다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 0이 아니나 사전설정된 상한에 도달하지 않는 경우, 프록시 서버는 제1 클라이언트의 역할이 부 마스터(secondary-master) 사용자임을 판정한다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제1 클라이언트가 슬레이브 사용자인 경우에, 방법은 다음을 더 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 제2 클라이언트로부터 수신하고; 제1 클라이언트를 새로운 부 마스터 사용자로서 판정하는 경우에, 프록시 서버는 제1 클라이언트의 역할을 슬레이브 사용자로부터 부 마스터 사용자로 변경하고; 프록시 서버는 미디어 서버에 제3 미디어 요청 메시지를 발신하되, 제3 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함하고; 프록시 서버는 제3 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제3 라이브 미디어 스트림을 수신한다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제2 클라이언트가 주 마스터(main-master) 사용자이고, 제1 클라이언트가 부 마스터 사용자인 경우에, 방법은 다음을 더 포함한다: 프록시 서버는 제1 클라이언트에 제1 라이브 미디어 스트림을 발신한다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제1 클라이언트가 부 마스터 사용자인 경우에, 방법은 다음을 더 포함한다: 프록시 서버는 제1 클라이언트로부터 제4 미디어 요청 메시지를 수신하고; 프록시 서버는 미디어 서버에 제4 미디어 요청 메시지를 발신하고; 프록시 서버는 제4 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제4 라이브 미디어 스트림을 수신한다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제1 클라이언트가 부 마스터 사용자인 경우에, 방법은 다음을 더 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 제2 클라이언트로부터 수신하고; 제1 클라이언트를 새로운 주 마스터 사용자로서 판정하는 경우에, 프록시 서버는 제1 클라이언트의 역할을 부 마스터 사용자로부터 주 마스터 사용자로 변경하고; 프록시 서버는 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제4 라이브 미디어 스트림으로 전환한다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 방법은 다음을 더 포함한다: 프록시 서버는 제4 라이브 미디어 스트림의 타임스탬프(timestamp)를 조절하여서, 조절된 타임스탬프는 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적(consecutive)임을 만족시킨다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제1 클라이언트에 프록시 서버에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 프록시 서버에 의해 발신된 제4 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다. 프록시 서버가 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제4 라이브 미디어 스트림으로 전환하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는, 캐싱된 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하는데, 제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임이고; 프록시 서버는, 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임으로서 사용한다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 방법은 다음을 더 포함한다: 프록시 서버는 픽처 그룹(group of pictures, GOP) 단위로 제1 라이브 미디어 스트림을 캐싱한다.
제1 측면을 참조하여, 제1 측면의 다른 가능한 구현에서, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 전환하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는 제2 라이브 미디어 스트림의 타임스탬프를 조절하여서, 조절된 타임스탬프는 제1 클라이언트에 프록시 서버에 의해 발신된 제2 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 프록시 서버에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시킨다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 제1 클라이언트에 프록시 서버에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 프록시 서버에 의해 발신된 제2 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다. 프록시 서버가 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 전환하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하는데, 제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임이고; 프록시 서버는, 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제2 라이브 미디어 스트림의 제1 프레임으로서 사용한다. 프록시 서버가 제1 전환 프레임 및 제2 전환 프레임을 판정한 후에, 방법은 다음을 더 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한, 제2 클라이언트로부터의 요청 메시지를 미디어 서버에 전송한다.
제1 측면을 참조하여, 제1 측면의 또 다른 가능한 구현에서, 프록시 서버가 제1 클라이언트에 제1 라이브 미디어 스트림을 발신하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는 제1 라이브 미디어 스트림의 타임스탬프를 조절하여서, 조절된 타임스탬프는 제1 클라이언트에 프록시 서버에 의해 발신된 제1 라이브 미디어 스트림의 제1 프레임의 타임스탬프가 0임을 만족시키고, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프는 연속적이다.
제2 측면에 따르면, 이 출원의 실시예는 미디어 스트림 발신 장치를 제공하는데, 장치는 제1 측면 및 제1 측면의 구현에서의 방법 단계를 수행하도록 구성된 유닛을 포함한다. 구체적으로, 장치는 획득 유닛 및 처리 유닛을 포함하며, 저장 모듈과 같은 다른 모듈 또는 유닛을 더 포함할 수 있다.
제3 측면에 따르면, 이 출원의 실시예는 송수신기(transceiver), 프로세서(processor) 및 메모리(memory)를 포함하는 네트워크 디바이스를 또한 제공한다. 프로세서는 메모리에 커플링되고(coupled); 메모리는 명령어를 저장하도록 구성되고; 프로세서는 네트워크 디바이스로 하여금 제1 측면 또는 제1 측면의 구현 중 임의의 것에 따른 미디어 스트림 발신 방법을 수행할 수 있게 하기 위해 명령어를 호출하도록 구성된다.
또한, 송수신기는 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 제1 클라이언트로부터 수신하도록 구성되고; 프로세서는 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 제1 클라이언트의 역할을 판정하도록 구성되고; 송수신기는 또한, 만일 제1 클라이언트의 역할이 슬레이브 사용자인 경우, 캐싱된 제1 라이브 미디어 스트림을 제1 클라이언트에 발신하도록 구성되는데, 제1 라이브 미디어 스트림은 네트워크 디바이스를 통해서 제2 클라이언트에 미디어 서버에 의해 발신된 미디어 스트림이고, 제2 클라이언트의 역할은 마스터 사용자이다.
선택적으로, 이 측면의 가능한 구현에서, 프로세서는 구체적으로, 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는지를 판정하고, 만일 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는 경우, 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하도록 구성된다.
선택적으로, 이 측면의 다른 가능한 구현에서, 송수신기는 또한, 제1 클라이언트에 네트워크 디바이스 내에 캐싱된 제1 라이브 미디어 스트림을 발신하기 전에, 제1 클라이언트로부터 제1 미디어 요청 메시지를 수신하고, 미디어 서버에 제1 미디어 요청 메시지를 전송하는 것을 생략하고, 제1 클라이언트에 제1 미디어 응답 메시지를 발신하도록 구성되는데, 제1 미디어 응답 메시지는 제1 클라이언트가 미디어 스트림을 획득하도록 허용됨을 제1 클라이언트에 통지하는 데에 사용된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 제1 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함하고, 송수신기는 또한, 제1 클라이언트에 제1 라이브 미디어 스트림을 발신한 후에, 제2 클라이언트로부터, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하도록 구성되고; 프로세서는 또한, 제1 클라이언트를 새로운 마스터 사용자로서 판정하는 경우에, 제1 클라이언트의 역할을 슬레이브 사용자로부터 마스터 사용자로 변경하도록 구성되고; 송수신기는 또한, 미디어 서버에 제2 미디어 요청 메시지를 발신하고(제2 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함함), 제2 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제2 라이브 미디어 스트림을 수신하도록 구성되고, 송수신기는 또한, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 전환하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 프로세서는 구체적으로, 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는지를 판정하고(사전설정된 상한은 1보다 큼), 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는 경우, 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 프로세서는 또한, 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 0이 아니나 사전설정된 상한에 도달하지 않는 경우, 제1 클라이언트의 역할이 부 마스터 사용자임을 판정하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 제1 클라이언트가 슬레이브 사용자인 경우에, 송수신기는 또한, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 제2 클라이언트로부터 수신하도록 구성되고, 프로세서는 또한, 제1 클라이언트를 새로운 부 마스터 사용자로서 판정하는 경우에, 제1 클라이언트의 역할을 슬레이브 사용자로부터 부 마스터 사용자로 변경하도록 구성되고, 송수신기는 또한, 미디어 서버에 제3 미디어 요청 메시지를 발신하고(제3 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함함), 제3 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제3 라이브 미디어 스트림을 수신하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 제2 클라이언트가 주 마스터 사용자이고, 제1 클라이언트가 부 마스터 사용자인 경우에, 송수신기는 또한 제1 클라이언트에 제1 라이브 미디어 스트림을 발신하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 제1 클라이언트가 부 마스터 사용자인 경우에, 송수신기는 또한, 제1 클라이언트로부터 제4 미디어 요청 메시지를 수신하고, 미디어 서버에 제4 미디어 요청 메시지를 발신하고, 제4 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제4 라이브 미디어 스트림을 수신하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 제1 클라이언트가 부 마스터 사용자인 경우에, 송수신기는 또한, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 제2 클라이언트로부터 수신하도록 구성되고, 프로세서는 또한, 제1 클라이언트를 새로운 주 마스터 사용자로서 판정하는 경우에, 제1 클라이언트의 역할을 부 마스터 사용자로부터 주 마스터 사용자로 변경하도록 구성되고, 송수신기는 또한, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제4 라이브 미디어 스트림으로 전환하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 프로세서는 또한, 조절된 타임스탬프가 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시키도록, 제4 라이브 미디어 스트림의 타임스탬프를 조절하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 제1 클라이언트에 송수신기에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 송수신기에 의해 발신된 제4 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다.
프로세서는 또한, 캐싱된 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하고(제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임임), 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임으로서 사용하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 메모리는 픽처 그룹(GOP) 단위로 제1 라이브 미디어 스트림을 캐싱하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 프로세서는 또한, 제2 라이브 미디어 스트림의 타임스탬프를 조절하도록 구성되어서, 조절된 타임스탬프는 제1 클라이언트에 송수신기에 의해 발신된 제2 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 송수신기에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시킨다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 제1 클라이언트에 송수신기에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 송수신기에 의해 발신된 제2 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다.
프로세서는 또한, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하고(제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임임), 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제2 라이브 미디어 스트림의 제1 프레임으로서 사용하고, 제1 전환 프레임 및 제2 전환 프레임을 판정한 후에, 미디어 서버에, 라이브 브로드캐스트 룸에서 퇴장하기 위한, 제2 클라이언트로부터의 요청 메시지를 전송하도록 구성된다.
선택적으로, 이 측면의 또 다른 가능한 구현에서, 프로세서는 또한, 제1 라이브 미디어 스트림의 타임스탬프를 조절하도록 구성되어서, 조절된 타임스탬프는 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 제1 프레임의 타임스탬프가 0임을 만족시키고, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프는 연속적이다.
선택적으로, 네트워크 디바이스는 프록시 서버이다.
제4 측면에 따르면, 이 출원의 실시예는 컴퓨터 판독가능 저장 매체(computer-readable storage medium)를 또한 제공한다. 저장 매체는 명령어를 저장하고, 명령어가 컴퓨터 또는 프로세서 상에서 가동되는 경우에, 제1 측면 또는 제1 측면의 구현 중 임의의 것에 따른 방법이 수행된다.
제5 측면에 따르면, 이 출원의 실시예는 컴퓨터 프로그램 제품을 또한 제공한다. 컴퓨터 프로그램 제품은 컴퓨터 명령어를 포함하고, 명령어가 컴퓨터 또는 프로세서에 의해 실행되는 경우에, 제1 측면 또는 제1 측면의 구현 중 임의의 것에 따른 방법이 구현될 수 있다.
제6 측면에 따르면, 이 출원의 실시예는 미디어 스트림 발신 시스템을 또한 제공한다. 시스템은 적어도 하나의 클라이언트, 프록시 서버 및 미디어 서버를 포함한다. 시스템은, 프록시 서버를 사용함으로써, 제1 측면 또는 제1 측면의 구현 중 임의의 것에 따른 미디어 스트림 발신 방법을 구현한다. 프록시 서버는 제1 측면 또는 제1 측면의 구현 중 임의의 것에 따른 미디어 스트림 발신 방법을 수행하도록 구성된다.
선택적으로, 프록시 서버는 제2 측면 또는 제2 측면의 구현 중 임의의 것에 따른 미디어 스트림 발신 장치이다.
제6 측면을 참조하여, 제6 측면의 가능한 구현에서, 미디어 서버는 구역 데이터 센터(RDC) 내에 위치되고, RDC는 웹 서버를 더 포함하고, 웹 서버는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 클라이언트에 미디어 서버를 할당하도록 구성된다.
제6 측면을 참조하여, 제6 측면의 다른 가능한 구현에서, 시스템은 기업 데이터 센터(EDC) 및 콘텐트 소스를 더 포함한다.
선택적으로, 미디어 스트리밍 발신 시스템은 콘텐트 전달 네트워크(CDN) 시스템이다.
추가로, 이 출원의 실시예는 칩 시스템을 또한 제공한다. 칩 시스템은 프로세서 및 인터페이스 회로를 포함한다. 인터페이스 회로는 프로세서에 커플링된다. 프로세서는 제1 측면 또는 제1 측면의 구현 중 임의의 것에 따른 미디어 스트림 발신 방법을 구현하기 위해, 컴퓨터 프로그램 또는 명령어를 실행하도록 구성된다. 인터페이스 회로는 칩 시스템 외부의 다른 모듈과 통신하도록 구성된다.
실시예에서의 방법에 따르면, 마스터 사용자가 역할인 클라이언트에 의해 요청된 라이브 미디어 스트림이 프록시 서버를 사용함으로써 획득된 경우에, 프록시 서버는 미디어 스트림의 세그먼트의 일부를 로컬로 캐싱한다. 슬레이브 사용자가 역할인 클라이언트가 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 요청하는 경우에, 프록시 서버는 로컬로 캐싱된 미디어 스트림을 슬레이브 사용자가 역할인 클라이언트에 직접적으로 발신하여서, 미디어 서버는 다시 프록시 서버에 라이브 미디어 스트림을 발신할 필요가 없다. 이 방법에 따르면, 미디어 서버는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 각각의 클라이언트에 라이브 미디어 스트림을 발신할 필요가 없다. 이것은 미디어 스트림을 발신하기 위한 트래픽을 감소시키고, 이출 대역폭을 효과적으로 절감하며, 리소스 오버헤드를 감소시킨다.
추가로, 이 방법에 따르면, 동일한 라이브 브로드캐스트 룸 내의 모든 클라이언트에 대해, 미디어 서버는 프록시 서버에 오직 하나의 라이브 미디어 스트림을 발신할 필요가 있는바, 즉, 하나의 라이브 미디어 스트림을 송신하기 위한 광역 네트워크 대역폭이 요구된다. 미디어 서버에 의해 모든 클라이언트에 라이브 미디어 스트림을 발신하기 위해 점유되는 송신 리소스에 비해, 이는 광역 네트워크 링크의 로드(load)를 감소시키고, 모든 클라이언트가 라이브 브로드캐스트 미디어를 수신한 후, 라이브 미디어 스트림의 재생 동안 비디오 동결(video freezing)을 방지하고, 따라서 이 방법을 사용함으로써 사용자 경험을 또한 개선한다.
도 1은 이 출원에 따른 라이브 브로드캐스트 시스템의 아키텍처의 개략도이고,
도 2는 이 출원의 실시예에 따른 비디오 라이브 브로드캐스트를 위한 단측(unilateral) 프록시 시스템의 아키텍처의 개략도이고,
도 3은 이 출원의 실시예에 따른 미디어 스트림 발신 방법의 흐름도이고,
도 4a 내지 도 4d는 이 출원의 실시예에 따른 미디어 스트림 발신 방법의 시그널링 흐름도이고,
도 5a 및 도 5b는 이 출원의 실시예에 따른 다른 미디어 스트림 발신 방법의 시그널링 흐름도이고,
도 6a 및 도 6b는 이 출원의 실시예에 따른 또 다른 미디어 스트림 발신 방법의 시그널링 흐름도이고,
도 7a 및 도 7b는 이 출원의 실시예에 따른 또 다른 미디어 스트림 발신 방법의 시그널링 흐름도이고,
도 8a 및 도 8b는 이 출원의 실시예에 따른 또 다른 미디어 스트림 발신 방법의 시그널링 흐름도이고,
도 9는 이 출원의 실시예에 따른 미디어 스트림 발신 장치의 개략적인 구조도이고,
도 10은 이 출원의 실시예에 따른 네트워크 디바이스의 개략적인 구조도이다.
당업자가 이 출원의 실시예에서의 기술적 해결안을 더 잘 이해하게 하고, 이 출원의 실시예의 목적, 특징 및 이점을 더 명확히 하기 위해, 다음은 첨부된 도면을 참조하여 상세히 이 출원의 실시예에서의 기술적 해결안을 추가로 기술한다.
이 출원의 실시예에서의 기술적 해결안이 기술되기 전에, 첨부된 도면을 참조하여 이 출원의 실시예의 적용 시나리오가 먼저 기술된다.
이 출원의 기술적 해결안은 콘텐트 전달 네트워크(content delivery network, CDN) 시스템에 적용될 수 있다. 시스템은 프록시 서버(proxy server)를 포함한다. 프록시 서버는, 사용자의 비디오 베어러 프로토콜(video bearer protocol)을 위한 프록시로서 작동하고, 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 모든 클라이언트의 역할을 식별하고, 마스터 사용자가 역할인 클라이언트의 미디어 요청 메시지에 기반하여 미디어 서버로부터 라이브 미디어 스트림을 획득하고, 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 모든 클라이언트에 라이브 미디어 스트림을 전달하도록 구성된다.
이 출원의 기술적 해결안이 적용되는 시스템은 복수의 프록시 서버를 포함할 수 있고, 프록시 서버 각각은 이 출원의 실시예에서 프록시 서버에 의해 수행되는 동작을 수행할 수 있다. 다시 말해, 이 출원의 실시예에서의 프록시 서버는 이 출원의 실시예가 적용되는 시스템 내의 임의의 프록시 서버일 수 있다. 이 출원의 실시예에서, 다음의 기술된 클라이언트는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 클라이언트이고, 프록시 서버는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 모든 클라이언트의 역할(예를 들어, 마스터 사용자 및 슬레이브 사용자)을 식별한다. 상응하여, 라이브 브로드캐스트 룸에서 마스터 사용자가 역할인 다음의 기술된 클라이언트는, 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 클라이언트 중에서, 프록시 서버에 의해 마스터 사용자로서 식별된 클라이언트이다. 유사하게, 슬레이브 사용자가 역할인 다음의 기술된 클라이언트는, 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 클라이언트 중에서, 프록시 서버에 의해 슬레이브 사용자로서 식별된 클라이언트이다.
프록시 서버는 로컬 영역 네트워크(local area network)의 에지(edge)에서의 디바이스일 수 있고, 로컬 영역 네트워크 내의 클라이언트가 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하고 프록시 서버를 통해서 라이브 브로드캐스트 룸의 라이브 미디어 스트림을 획득한다.
선택적으로, 프록시 서버는 서버 상에 배치되거나, 네트워크 기능 가상화(Network Functions Virtualization, NFV)를 통해서 범용 고객 구내 장비(Universal Customer Premise Equipment, uCPE) 상에 배치될 수 있다.
또한, 도 2에 도시된 바와 같이, 이 실시예에서 제공되는 비디오 CDN 시스템에서, 시스템은 다음을 포함한다: 콘텐트 소스(content source)(101), 기업 데이터 센터(enterprise data center, EDC)(102), RDC(103), 프록시 서버(104) 및 적어도 하나의 클라이언트(client, C). 예를 들어, 적어도 하나의 클라이언트는 제1 클라이언트 C1(105), 제2 클라이언트 C2(106) 및 제3 클라이언트 C3(107)를 포함한다. EDC(102)는 복수의 미디어 서버(media server) 및 웹 서버(Web server)를 포함하고, RDC(103)는 복수의 미디어 서버 및 웹 서버를 포함한다.
라이브 CDN은 분산형 콘텐트 전달 플랫폼이며 다층 아키텍처를 지원한다. 라이브 CDN 플랫폼 상에서, 상이한 구역 내의 사용자를 위해 인근에서의 서비스를 제공하기 위해, 캐싱을 위한 복수의 서버가 상이한 계층에 배치될 수 있다. EDC 내의 사용자가 라이브 브로드캐스트 룸 내에서 라이브 브로드캐스트를 관람하는 경우에, 할당된 미디어 서버가 RDC 내에 배치되고, 송신된 라이브 미디어 스트림은 다중 프로토콜 라벨 스위칭(Multi-Protocol Label Switching, MPLS) 사설 라인(private line)을 통해서 RDC에 도달한다.
또한, 전술한 디바이스 또는 네트워크 요소의 기능의 일반적인 설명이 다음의 표 1에서 제공된다.
Figure 112021076425023-pct00001
라이브 미디어 스트림이 RDC로부터 SR에, 그리고 이후에 클라이언트에 송신되는 경우에 대량의 네트워크 리소스가 점유된다는 문제를 해결하기 위해, 실시예는 미디어 스트림 발신 방법을 제공한다. 방법은 프록시 서버에 적용되고, 프록시 서버는 라이브 브로드캐스트 룸에 입장하는 적어도 두 클라이언트를 위해 라이브 미디어 스트림을 제공하도록 구성된다. 구체적으로, 도 3에 도시된 바와 같이, 방법은 다음의 단계를 포함한다.
단계(101): 프록시 서버는, 제1 클라이언트로부터, 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하는데, 제1 라이브 브로드캐스트 룸 요청 메시지는 제1 클라이언트의 제1 식별자, 예를 들어, 클라이언트 C1의 IP 주소를 포함한다.
단계(102): 프록시 서버는 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 제1 클라이언트의 역할을 판정하는데, 제1 클라이언트의 역할은 마스터 사용자(master user) 또는 슬레이브 사용자(slave user)일 수 있다.
구체적으로, 단계(102)는 다음을 포함한다: 프록시 서버는 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하는 경우에 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는지를 판정하고; 만일 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는 경우, 프록시 서버는 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하거나, 만일 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 없는 경우, 프록시 서버는 제1 클라이언트의 역할이 마스터 사용자임을 판정한다. 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는지는 구체적으로 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 마스터 사용자가 역할인 클라이언트의 수효에 기반하여 판정될 수 있다. 만일 수효가 사전설정된 상한에 도달하는 경우, 프록시 서버는 현재의 클라이언트가 슬레이브 사용자임을 판정하되; 그렇지 않은 경우, 프록시 서버는 제1 클라이언트가 마스터 사용자임을 판정한다.
사전설정된 상한은 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하고 마스터 사용자로서 판정되는 클라이언트의 수효의 상한이다.
추가로, 이 실시예에서, 마스터 사용자가 역할인 클라이언트는 간략히 마스터 사용자 클라이언트로서 지칭되고, 슬레이브 사용자가 역할인 클라이언트는 간략히 슬레이브 사용자 클라이언트로서 지칭된다. 이 실시예에서, 사전설정된 상한의 상이한 값을 기반으로 사전설정된 상한에 대해 2개의 경우가 있을 수 있다: 사전설정된 상한이 1임 및 사전설정된 상한이 1보다 큼.
구체적으로, 사전설정된 상한이 1인 경우에, 프록시 서버를 통해서 라이브 브로드캐스트 룸을 액세스하도록 설정된 모든 클라이언트 중에서, 마스터 사용자 클라이언트의 수효는 1인바, 즉, 오직 하나의 마스터 사용자가 있다. 그러한 시나리오는 단일 마스터 사용자가 있는 시나리오로서 지칭될 수 있다. 사전설정된 상한이 1보다 큰 경우, 즉, 마스터 사용자 클라이언트의 수효가 2 이상인 경우에, 구체적으로 하나의 주 마스터 사용자(main-master user) 및 복수의 부 마스터 사용자(secondary-master user)가 있을 수 있다. 그러한 시나리오는 복수의 마스터 사용자가 있는 시나리오로서 지칭될 수 있다.
또한, 복수의 마스터 사용자가 있는 시나리오에 대해, 제1 클라이언트의 역할을 판정하는 것은 다음을 포함한다: 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에, 그리고 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 0인 경우, 제1 클라이언트의 역할이 주 마스터 사용자임을 판정하는 것; 또는 만일 수효가 0이 아니나 사전설정된 상한에 도달하지 않은 경우, 제1 클라이언트의 역할이 부 마스터 사용자임을 판정하는 것.
단계(103): 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하는 경우에, 프록시 서버는 로컬로 캐싱된 제1 라이브 미디어 스트림을 제1 클라이언트에 발신한다.
제1 라이브 미디어 스트림은 마스터 사용자가 역할인 클라이언트에 미디어 서버에 의해 프록시 서버를 통해서 발신된 미디어 스트림이다. 이 실시예에서, 단일 마스터 사용자가 있는 기술적 시나리오에서, 제2 클라이언트의 역할은 마스터 사용자이다. 복수의 마스터 사용자가 있는 기술적 시나리오에서, 제2 클라이언트의 역할은 구체적으로 주 마스터 사용자이다.
단계(103) 전에, 방법은 다음을 더 포함한다: 프록시 서버는, 제2 클라이언트로부터, 라이브 브로드캐스트 룸에 입장하기 위한 제2 라이브 브로드캐스트 룸 요청 메시지를 수신하고; 미디어 서버로부터 제1 라이브 미디어 스트림을 획득하고; 제1 라이브 미디어 스트림을 캐싱하고; 프록시 서버를 통해서 제2 클라이언트에 제1 라이브 미디어 스트림을 발신한다. 제1 라이브 미디어 스트림이 획득된 경우에, 만일 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 다른 클라이언트가 라이브 브로드캐스트 룸 내에 있는 경우, 프록시 서버는 또한 그 다른 클라이언트에 제1 라이브 미디어 스트림을 발신한다. 구체적인 구현에서, 제2 클라이언트는 제2 라이브 브로드캐스트 룸 요청 메시지를 발신함으로써 라이브 브로드캐스트 룸에 입장하기를 요청하고 미디어 요청 메시지를 발신함으로써 라이브 미디어 스트림을 요청할 수 있다. 이 경우에, 제2 클라이언트에 의해 발신된 미디어 요청 메시지를 수신한 후에, 프록시 서버는 제1 라이브 미디어 스트림을 획득하기 위해 미디어 서버에 미디어 요청 메시지를 전송한다. 대안적으로, 제2 라이브 브로드캐스트 룸 요청 메시지를 발신함으로써, 클라이언트는 라이브 브로드캐스트 룸에 입장하기를 요청하고 라이브 미디어 스트림을 요청할 수 있다. 이 경우에, 제2 라이브 브로드캐스트 룸 요청 메시지를 수신한 후에, 프록시 서버는 제1 라이브 미디어 스트림을 획득하기 위해 미디어 서버에 제2 라이브 브로드캐스트 룸 요청 메시지를 전송한다.
선택적으로, 제1 라이브 미디어 스트림을 수신한 후에, 프록시 서버는 픽처 그룹(group of pictures, GOP) 단위로 제1 라이브 미디어 스트림을 로컬로 캐싱한다. GOP는 2개의 I 프레임 간의 픽처 시퀀스(picture sequence)를 지칭할 수 있다. 인트라 픽처(intra picture)로서 또한 지칭되는 I 프레임(frame)은 전형적으로 동화상 전문가 그룹(moving picture experts group, MPEG) 기술 처리를 통해서 획득된 각각의 GOP의 제1 프레임을 지칭한다. 또한, MPEG 기술 처리는, I 프레임이 랜덤 액세스(random access)를 위한 참조(reference)로서 사용될 수 있고 다른 픽처는 참조될 필요가 없도록, 비디오 픽처를 적절히 압축하는 것을 포함한다.
이 실시예에서, 예를 들어, 3개의 GOP가 로컬로 캐싱된다. 예를 들어, 캐싱된 라이브 미디어 스트림의 3개의 GOP의 시간 세그먼트는 t1-t2, t2-t3 및 t3-t4이다.
제1 클라이언트가 라이브 미디어 스트림을 획득하기를 요청하는 경우에, 프록시 서버는 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하고 확인하며, 로컬로 캐싱된 제1 라이브 미디어 스트림을 제1 클라이언트에 직접적으로 발신하여서, 프록시 서버로 하여금 다시 미디어 서버에 라이브 미디어 스트림을 요청하여 획득하지 않게 한다. 다시 말해, 미디어 서버는 프록시 서버에 오직 하나의 라이브 미디어 스트림을 발신할 필요가 있고, 프록시 서버는 라이브 미디어 스트림을 복제하고 라이브 브로드캐스트 룸 내에서 슬레이브 사용자로서 이바지하는 모든 클라이언트에 전달할 수 있다. 따라서, 동일한 라이브 브로드캐스트 룸에 입장하는 사용자를 위해 오직 하나의 라이브 미디어 스트림을 위한 광역 네트워크 대역폭이 소비된다. 방법을 사용하는 것은 기존의 시스템에서 RDC 내의 미디어 서버 및 SR 간에 미디어 스트림을 발신하기 위한 트래픽을 감소시키고, 이출 대역폭을 효과적으로 절감하며, 리소스 오버헤드를 감소시킨다.
추가로, 방법을 사용하는 것은 또한 광역 네트워크 링크의 로드를 감소시키고, 클라이언트에 발신된 라이브 비디오의 재생 동안 비디오 동결을 방지하고, 다른 서비스에 영향을 주는 것을 방지한다. 따라서, 방법을 사용하는 것은 또한 사용자 경험을 개선한다.
단일 마스터 사용자가 있는 시나리오에서, 제1 클라이언트는 슬레이브 사용자이고, 제2 클라이언트는 마스터 사용자이다. 단계(103) 전에, 방법은 다음을 더 포함한다: 프록시 서버는 제1 클라이언트에 의해 발신된 제1 미디어 요청 메시지를 수신한다. 제1 클라이언트가 슬레이브 사용자이기 때문에, 프록시 서버는 미디어 서버에 제1 미디어 요청 메시지를 전송하지 않는다. 프록시 서버는 제1 클라이언트에 제1 미디어 응답 메시지를 발신하는데, 제1 미디어 응답 메시지는 제1 클라이언트가 미디어 스트림을 획득하도록 허용됨을 제1 클라이언트에 통지하는 데에 사용된다. 또한, 획득하도록 허용된 미디어 스트림은 제1 라이브 미디어 스트림이고, 제1 라이브 미디어 스트림은 마스터 사용자가 역할인 클라이언트에 미디어 서버에 의해 발신된 미디어 스트림이다.
추가로, 이 실시예는 다음을 더 포함한다: 라이브 브로드캐스트 룸 내의 마스터 사용자 클라이언트가 라이브 브로드캐스트 룸에서 퇴장하고, 라이브 브로드캐스트 룸 내의 다른 클라이언트가 새로운 마스터 사용자로서 선택되며, 새로운 마스터 사용자로부터의 미디어 스트림이 라이브 브로드캐스트 룸 내의 클라이언트에 발신된다. 구체적으로, 방법은 다음을 포함한다: 프록시 서버는, 제2 클라이언트로부터, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하고; 제1 클라이언트를 새로운 마스터 사용자로서 판정하는 경우에, 프록시 서버는 제1 클라이언트의 역할을 슬레이브 사용자로부터 마스터 사용자로 변경하고; 프록시 서버는 미디어 서버에 제2 미디어 요청 메시지를 발신하는데, 제2 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함하고; 프록시 서버는 제2 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제2 라이브 미디어 스트림을 수신하고; 프록시 서버는, 제2 라이브 미디어 스트림으로, 라이브 브로드캐스트 룸 내의 (제1 클라이언트를 포함하는) 클라이언트에 발신된 제1 라이브 미디어 스트림을 전환한다.
이 구현에서, 마스터 사용자로서 이바지하는 제2 클라이언트가 라이브 브로드캐스트 룸에서 퇴장하는 경우에, 프록시 서버는, 새로운 마스터 사용자로서, 슬레이브 사용자로서 이바지하는 제1 클라이언트를 선택하고, 제1 클라이언트의 신원(identity)을 사용함으로써 라이브 미디어 스트림을 요청하고 획득하며, 이후에 프록시 서버는 라이브 미디어 스트림을 복제하고 라이브 브로드캐스트 룸 내의 다른 클라이언트에 전달하여서, 라이브 브로드캐스트 룸 내의 사용자가 원활하게 비디오를 관람하도록 보장한다.
라이브 브로드캐스트 룸 내의 제1 클라이언트 및 제2 클라이언트의 역할 및 마스터 사용자 클라이언트의 수효 모두 라이브 브로드캐스트 룸 사용자 관계 테이블(live-broadcast-room user relationship table)에 기반하여 판정될 수 있다. 라이브 브로드캐스트 룸 사용자 관계 테이블은 각각의 클라이언트에 대한 정보를 기록하고, 각각의 클라이언트에 대한 정보는 라이브 브로드캐스트 룸 요청 메시지, 클라이언트의 IP 주소, 포트 번호, 사용자 역할 및 사용자 이름, 미디어 서버의 IP 주소 및 포트 번호, 그리고 라이브 브로드캐스트 룸의 이름과 같은 정보를 포함한다. 프록시 서버는 현재 라이브 브로드캐스트 룸 내의 모든 사용자의 라이브 브로드캐스트 룸 요청 메시지를 계산함으로써 마스터 사용자의 수효를 판정하고, 이후에 마스터 사용자의 수효 및 사전설정된 상한에 기반하여 제1 클라이언트의 역할을 판정한다.
추가로, 프록시 서버가 라이브 브로드캐스트 룸 내의 클라이언트(예를 들어, 제1 클라이언트)에 라이브 미디어 스트림(예를 들어, 제1 라이브 미디어 스트림 또는 제2 라이브 미디어 스트림)을 발신하기 전에, 방법은 다음을 더 포함한다: 라이브 미디어 스트림의 타임스탬프를 조절하는 것. 구체적으로, 방법은 다음을 더 포함한다: 식 y＝x+Δt 에 따라 미디어 스트림의 타임스탬프를 조절하는 것(여기서 y는 조절 후의 타임스탬프를 나타내고, x는 조절 전의 타임스탬프를 나타내고, Δt는 시간 차이를 나타낸다.
만일 미디어 스트림이 클라이언트가 라이브 브로드캐스트 룸에 입장한 후에 클라이언트에 의해 수신된 라이브 미디어 스트림의 제1 채널인 경우, 예를 들어, 단계(103)에서, 만일 제1 라이브 미디어 스트림이 제1 클라이언트가 라이브 브로드캐스트 룸에 입장한 후에 제1 클라이언트에 의해 수신된 라이브 미디어 스트림의 제1 채널인 경우, 프록시 서버는 식에 따라 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 다음의 제약을 만족시키도록, 조절한다:
프록시 서버에 의해 발신된 라이브 미디어 스트림의 제1 프레임의 타임스탬프가 0임; 및
클라이언트에 프록시 서버에 의해 발신된 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임, 즉, 발신된 라이브 비디오 스트림의 인접한 프레임의 시간 길이가 동일하고, 시간 길이는 라이브 비디오 스트림의 프레임 레이트(frame rate) f의 역수(reciprocal)임.
라이브 미디어 스트림이 클라이언트가 라이브 브로드캐스트 룸에 입장한 후에 클라이언트에 의해 수신된 라이브 미디어 스트림의 제1 채널이기 때문에, Δt는 클라이언트에 프록시 서버에 의해 발신된 라이브 미디어 스트림의 제1 프레임의, 조절 전 타임스탬프의 상반수(opposite number)를 나타낸다.
만일 클라이언트가 미디어 스트림을 수신하였다면, 즉, 만일 클라이언트에 프록시 서버에 의해 발신된 미디어 스트림이 이전의 마스터 사용자의 미디어 스트림으로부터 현재의 마스터 사용자의 미디어 스트림으로 전환한 경우, 예를 들어, 만일 프록시 서버가, 제2 라이브 미디어 스트림으로, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 전환한 경우, 프록시 서버는 식에 따라 현재의 마스터 사용자의 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 다음의 제약을 만족시키도록 조절한다:
이전의 마스터 사용자의 것이고 프록시 서버에 의해 클라이언트에 발신된 미디어 스트림의 마지막 프레임의 타임스탬프 및 현재의 마스터 사용자의 것이고 클라이언트에 발신된 미디어 스트림의 제1 프레임의 타임스탬프가 연속적임; 및
현재의 마스터 사용자의 것이고 프록시 서버에 의해 클라이언트에 발신된 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임.
예를 들어, 하나의 마스터 사용자 및 복수의 슬레이브 사용자가 있는 시나리오에서, 프록시 서버에 의해 캐싱된 제1 라이브 미디어 스트림의 GOP의 시간 길이는 5초(s)이고, 3개의 GOP가 로컬로 캐싱되고, 3개의 GOP의 콘텐트가 실시간으로 갱신된다고 가정된다. 만일 제2 클라이언트 C2가 라이브 브로드캐스트 룸에 처음 입장하는 클라이언트인 경우, 제0초에서의 클라이언트 C2의 역할은 마스터 사용자이고, 클라이언트 C2는 제60초가 도래할 때까지 계속해서 제1 라이브 미디어 스트림을 라이브 브로드캐스트 룸 내에서 관람한다. 이 경우에, 프록시 서버에 의해 로컬로 캐싱된 비디오 미디어 스트림의 3개의 GOP는 다음과 같다: 제45초부터 제50초까지의 미디어 콘텐트, 제50초부터 제55초까지의 미디어 콘텐트 및 제55초부터 제60초까지의 미디어 콘텐트. 3개의 GOP는 클라이언트 C2에 미디어 서버에 의해 발신된 미디어 스트림의 세그먼트이고, 각각의 상응하여 발신된 프레임의 타임스탬프는 클라이언트 C2의 상대적인 시간이다.
제1 클라이언트 C1이 제60초에 라이브 브로드캐스트 룸에 입장하고, 제1 클라이언트 C1의 역할은 슬레이브 사용자이다. 프록시 서버는 클라이언트 C2에 발신되고 로컬로 캐싱된 최근의 제1 라이브 미디어 스트림을 클라이언트 C1에 발신할 필요가 있다. 이 경우에, 제60초에 가장 가까운 라이브 미디어 스트림은 제3 GOP 세그먼트의 미디어 콘텐트이고, 제55초부터 제60초까지의 미디어 콘텐트가 캐싱된다. 제55초는 미디어 서버에 의해 발신된 프레임의 타임스탬프이고, 따라서 조절될 필요가 있는 시간 차이는 Δt=y-x=0-55 =-55s인바, 즉, 전술한 제약을 만족시키기 위해, 프록시 서버는 제1 라이브 미디어 스트림을 클라이언트 C1에 발신하는 경우에 55초만큼 타임스탬프를 감소시킬 필요가 있다. 이 방식으로, 라이브 브로드캐스트 룸에 입장하는 각각의 사용자는 기다릴 필요 없이 제0초에서 라이브 브로드캐스트 비디오를 관람할 수 있고, 라이브 브로드캐스트 룸 내의 모든 사용자는 "동기식으로"(synchronously) 비디오를 관람할 수 있다.
추가로, 제2 클라이언트 C2가 라이브 브로드캐스트 룸에서 퇴장하는 경우에, 비디오 미디어 스트림의 타임스탬프는 또한 조절될 필요가 있다. 구체적으로, 만일 클라이언트 C2가 비디오 재생의 제120초에서 라이브 브로드캐스트 룸에서 퇴장하는 경우, 프록시 서버는 새로운 마스터 사용자로서 클라이언트를 선택할 필요가 있다. 이 실시예에서, 제1 클라이언트 C1이 마스터 사용자로서 선택된다고 가정된다. 그러면, 프록시 서버는 클라이언트 C2에 원래 발신된 제1 라이브 미디어 스트림을 클라이언트 C1에 발신된 라이브 미디어 스트림으로 변경한다. 대응하는 타임스탬프 조절 프로세스는 다음과 같다:
제120초에서, 프록시 서버에 의해 로컬로 캐싱된 3개의 GOP의 미디어 콘텐트가 다음과 같다고 가정된다: 제105초부터 제110초까지의 미디어 콘텐트, 제110초부터 제115초까지의 미디어 콘텐트 및 제115초부터 제120초까지의 미디어 콘텐트. 10초가 경과한 후에, 프록시 서버에 의해 캐싱된 최근의 GOP 1은 제115초부터 제120초까지의 비디오 콘텐트이고, GOP 1 내의 프레임의 타임스탬프는 클라이언트 C2의 상대적인 시간이다. 클라이언트 C2가 라이브 브로드캐스트 룸에서 퇴장한 후에, 프록시 서버는 GOP 2 및 GOP 3을 로컬로 캐싱한다: 제0초부터 제5초까지의 미디어 콘텐트 및 제5초부터 제10초까지의 미디어 콘텐트. 2개의 GOP의 타임스탬프는 클라이언트 C1의 상대적인 시간이다. 따라서, 조절된 시간 차이는 Δt=120-55-0=65s로서 계산되는바, 즉, 새로운 마스터 사용자로서 이바지하는 클라이언트 C1에 프록시 서버에 의해 발신된 라이브 미디어 스트림의 프레임의 타임스탬프는 65초만큼 증가할 필요가 있다.
전술한 설명을 기반으로, 조절된 시간 차이를 계산하기 위한 2개의 경우가 있을 수 있다. 세부사항은 다음과 같다.
경우 1: 만일 클라이언트가 미디어 스트림을 수신하지 않았다면, 즉, 만일 현재의 미디어 스트림이 클라이언트가 라이브 브로드캐스트 룸에 입장한 후에 클라이언트에 의해 수신된 미디어 스트림의 제1 채널인 경우, 시간 차이는 Δt =0-t2 =-t2인데, 여기서 t2는 미디어 서버로부터 프록시 서버에 의해 수신되고 클라이언트에 전송될 필요가 있는 미디어 스트림의 제1 프레임의 타임스탬프를 나타낸다.
경우 2: 만일 클라이언트가 미디어 스트림을 수신하였다면, 즉, 만일 클라이언트에 프록시 서버에 의해 발신된 미디어 스트림이 이전의 마스터 사용자의 미디어 스트림으로부터 현재의 마스터 사용자의 미디어 스트림으로 전환된 경우, 시간 차이는 Δt=(t1+m)-t2인데, 여기서 t2는 미디어 스트림 전환 후에 클라이언트에 프록시 서버에 의해 발신된 미디어 스트림(현재의 마스터 사용자의 미디어 스트림)의 제1 프레임의, 조절 전의 타임스탬프를 나타내고, t1은 미디어 스트림 전환 전에 클라이언트에 프록시 서버에 의해 발신된 미디어 스트림(이전의 마스터 사용자의 미디어 스트림)의 마지막 프레임의, 조절 후 타임스탬프를 나타낸다. 대응하는 다음 비디오 프레임의 타임스탬프는 t1+m이고, m=1/ f이다. 예를 들어, f = 20 fps이고, 발신된 비디오 프레임의 시간 길이는 m = 1s/20 = 0.05s, 즉 50ms이다.
전술한 방법에 따르면, 프록시 서버가 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 전환하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는 제2 라이브 미디어 스트림의 타임스탬프를 조절하여서, 조절된 타임스탬프는 제1 클라이언트에 프록시 서버에 의해 발신된 제2 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 프록시 서버에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시킨다.
또한, 제1 클라이언트에 프록시 서버에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 프록시 서버에 의해 발신된 제2 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다. 프록시 서버가 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 전환하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하고(제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임임); 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제2 라이브 미디어 스트림의 제1 프레임으로서 사용한다. 제1 전환 프레임 및 제2 전환 프레임을 판정한 후에, 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한, 제2 클라이언트로부터의 요청 메시지를 미디어 서버에 전송한다.
이 실시예에서, 프록시 서버는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 각각의 클라이언트에 마스터 사용자의 라이브 미디어 스트림을 발신한다. 마스터 사용자가 전환될 때마다, 프록시 서버는, 이전의 마스터 사용자의 것이고 각각의 클라이언트에 발신된 라이브 미디어 스트림을, 현재의 마스터 사용자의 라이브 미디어 스트림으로 전환하는바, 즉, 프록시 서버는 각각의 클라이언트에 이전의 마스터 사용자의 미디어 스트림을 발신하는 것을 중지하고, 클라이언트에 현재의 마스터 사용자의 라이브 미디어 스트림을 발신하기 시작한다. 예를 들어, 클라이언트 C1이 라이브 브로드캐스트 룸에서 퇴장하는 경우에, 프록시 서버는 클라이언트 C1에 제1 라이브 미디어 스트림을 발신하는 것을 중지하고, 새로 선택된 클라이언트 C2의 제2 라이브 미디어 스트림을 라이브 브로드캐스트 스트림을 관람하고 있는 라이브 브로드캐스트 룸 내의 다른 클라이언트에 발신한다. 이 경우에, 클라이언트 C2의 역할은 마스터 사용자로 바뀐다. 추가로, 새로운 미디어 스트림을 발신하는 경우에, 현재의 마스터 사용자의 것이고 프록시 서버에 의해 임의의 클라이언트에 발신된 라이브 미디어 스트림의 제1 프레임은 이전의 마스터 사용자의 것이고 클라이언트에 발신된 라이브 미디어 스트림의 마지막 프레임에 인접한다. 즉, 클라이언트 C2에 발신된 제2 라이브 미디어 스트림의 제1 프레임은 원래 발신된 제1 라이브 미디어 스트림의 마지막 프레임에 인접한다.
복수의 마스터 사용자가 있는 시나리오에서, 제2 클라이언트는 주 마스터 사용자이고, 제1 클라이언트는 슬레이브 사용자이며, 클라이언트가 라이브 브로드캐스트 룸에서 퇴장하는 프로세스는 다음을 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한, 제2 클라이언트로부터의 요청 메시지를 수신하고; 프록시 서버는 제1 클라이언트를 새로운 부 마스터 사용자로서 판정하는 경우에 제1 클라이언트의 역할을 슬레이브 사용자로부터 부 마스터 사용자로 변경하고; 프록시 서버는 미디어 서버에 제3 미디어 요청 메시지를 발신하고, 제3 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제3 라이브 미디어 스트림을 수신하고, GOP 단위로 프록시 서버 내에 제3 라이브 미디어 스트림을 로컬로 캐싱하는데, 제3 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함한다.
이 실시예에서, 라이브 미디어 스트림을 획득한 후에, 프록시 서버는 부 마스터 사용자로서 이바지하는 클라이언트에 라이브 미디어 스트림을 전송하지 않되, 프록시 서버는 라이브 미디어 스트림의 세그먼트를 로컬로 캐싱하여서, 부 마스터 사용자의 역할이 주 마스터 사용자로 전환되는 경우에 라이브 브로드캐스트 룸 내의 사용자에게 라이브 미디어 스트림의 캐싱된 세그먼트를 전달한다.
선택적으로, 복수의 마스터 사용자가 있는 시나리오에서, 만일 제1 클라이언트가 부 마스터 사용자이고, 프록시 서버가 제1 클라이언트에 의해 발신된 제4 미디어 요청 메시지에 기반하여 미디어 서버로부터 제4 라이브 미디어 스트림을 획득하면, 주 마스터 사용자로서 이바지하는 제2 클라이언트가 라이브 브로드캐스트 룸에서 퇴장하는 경우에 방법은 다음을 더 포함한다: 제1 클라이언트를 새로운 주 마스터 사용자로서 판정하는 경우에, 프록시 서버는 제1 클라이언트의 역할을 부 마스터 사용자로부터 주 마스터 사용자로 변경하고, 프록시 서버는 라이브 브로드캐스트 내의 (제1 클라이언트를 포함하는) 클라이언트에 발신된 제1 라이브 미디어 스트림을 제4 라이브 미디어 스트림으로 전환한다.
프록시 서버는 제4 라이브 미디어 스트림의 타임스탬프를 조절하여서, 조절된 타임스탬프는 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시킨다.
또한, 제1 클라이언트에 프록시 서버에 의해 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 프록시 서버에 의해 발신된 제4 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다. 프록시 서버가 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 제4 라이브 미디어 스트림으로 전환하기 전에, 방법은 다음을 더 포함한다: 프록시 서버는, 캐싱된 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하는데, 제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임이다.
프록시 서버는, 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임으로서 사용한다. 더 구체적인 타임스탬프 조절 프로세스에 대해, 전술한 실시예에서의 설명을 참조하시오. 세부사항은 여기에서 다시 기술되지 않는다.
이 실시예에서, 복수의 마스터 사용자가 있는 기술적 시나리오에서, 프록시 서버는, 미디어 서버로부터, 주 마스터 사용자가 역할인 클라이언트에 의해 요청된 라이브 미디어 스트림을 획득하고, 라이브 브로드캐스트 룸 내의 모든 사용자에게 라이브 미디어 스트림을 전달하고; 미디어 서버는 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 각각의 사용자를 위해 프록시 서버에 라이브 미디어 스트림을 발신할 필요가 없다. 이는 미디어 서버 및 프록시 서버 간의 WAN 송신 리소스를 절감하고, 미디어 스트림 송신을 위한 오버헤드를 감소시킨다.
추가로, 프록시 서버는 또한 부 마스터 사용자가 역할인 클라이언트의 미디어 스트림을 획득하고, 미디어 스트림을 로컬로 캐싱하여서, 미디어 스트림은 주 마스터 사용자로서 이바지하는 클라이언트가 라이브 브로드캐스트 룸에서 퇴장하는 경우에 사용되도록 준비된다. 추가로, 라이브 미디어 스트림이 전환되는 경우에, 미디어 스트림 정렬 및 타임스탬프 정렬이 수행되어, 여전히 미디어 콘텐트를 관람하고 있는 라이브 브로드캐스트 룸 내의 클라이언트가 전환을 지각하지 않도록 보장한다. 이것은 사용자 경험을 보장한다.
이 출원의 이 실시예에서 기술된 제1 라이브 미디어 스트림, 제2 라이브 미디어 스트림, 제3 라이브 미디어 스트림 및 유사한 것은 콘텐트 소스에 의해 발신된 동일한 라이브 미디어 스트림임에 유의하여야 한다. 미디어 스트림은 상이한 클라이언트의 미디어 요청 메시지에 기반하여 프록시 서버에 의해 획득된 라이브 미디어 스트림 간을 구별하는 데에 사용된다. 사용자가 상이한 시점에 라이브 브로드캐스트 룸에 입장하기 때문에, 클라이언트에 프록시 서버에 의해 발신된 라이브 미디어 스트림의 타임스탬프는 상이하다. 따라서, 클라이언트에 라이브 미디어 스트림을 발신하는 경우에, 프록시 서버는 타임스탬프를, 라이브 브로드캐스트 룸에 입장하는 각각의 클라이언트가 즉시 현재의 라이브 미디어 콘텐트를 볼 수 있도록, 조절할 수 있다.
다음은 이 출원의 실시예에서 제공되는 방법을 구체적으로 기술한다.
실시예 1:
이 실시예는 비디오 라이브 미디어 스트림 발신 방법을 제공한다. 방법은 도 2에 도시된 비디오 라이브 브로드캐스트 시스템에 적용될 수 있다. 방법은 다음을 포함한다: 미디어 서버는 라이브 브로드캐스트 룸에 입장하는 제1 클라이언트 및 제2 클라이언트를 위해 라이브 미디어 스트림을 제공하는데, 제1 클라이언트 및 제2 클라이언트 양자 모두는 동일한 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장한다. 또한, 도 4a 내지 도 4d에 도시된 바와 같이, 방법은 총 26개의 단계(step, S)를 포함한다: S1 내지 S26.
S1 내지 S12는 제1 클라이언트(이하에서 "클라이언트 C1"으로 지칭됨)가 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 획득하는 프로세스이다. S13 내지 S26는 제2 클라이언트(이하에서 "클라이언트 C2"로 지칭됨)가 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 획득하는 프로세스이다.
구체적으로, 클라이언트 C1이 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 획득하는 프로세스는 다음의 단계를 포함한다.
S1: 콘텐트 소스가 제1 라이브 미디어 스트림을 EDC 내의 미디어 서버에 발신한다.
S2: EDC 내의 미디어 서버는 제1 라이브 미디어 스트림을 수신하고, 제1 라이브 미디어 스트림을 하위 레벨 RDC 내의 미디어 서버에 발신한다. 제1 라이브 미디어 스트림이 발신되기 전에, 방법은 EDC 내의 웹 서버가 하위 레벨 RDC 내의 미디어 서버를 인증하고, 인증이 성공하는 경우에만 EDC 내의 미디어 서버가 하위 레벨 RDC 내의 미디어 서버에 제1 라이브 미디어 스트림을 발신하는 단계를 더 포함한다.
선택적으로, S2는 다음을 더 포함한다: 프록시 서버(proxy server)는, 제1 라이브 미디어 스트림의 서비스 특징에 기반하여, 프록시 서버에 의해 서빙되는(served) 클라이언트에 대응하는 송신 프로토콜을 식별한다. 서비스 특징은 다음을 포함한다: 웹 서버의 IP 주소 및 포트 번호. 예를 들어, 하이퍼텍스트 이송 프로토콜(Hyper Text Transfer Protocol, HTTP)에 대해, 구성될 수 있는 서비스 특징은 다음을 포함한다: 웹 서버의 IP 주소 및 포트 번호. 또한, 프록시 서버는 또한, HTTP 프로토콜에 대응하는 송신 프로토콜이 미디어 스트림 송신을 위한, 송신 제어 프로토콜(Transmission Control Protocol, TCP)임을 판정할 수 있다.
S3: 클라이언트 C1은 액세스될 수 있는 미디어 서버에 대한 요청 메시지를 RDC 내의 웹 서버에 발신한다. 또한, 요청 메시지는 클라이언트 C1의 사용자 이름 및 IP 주소, 라이브 브로드캐스트 룸의 이름, 그리고 인증이 성공한 후에 클라이언트 C1에 의해 획득된 키 토큰(key token)과 같은 정보를 포함하는데, IP 주소는 클라이언트 C1의 위치를 판정하는 데에 사용된다. 구체적으로, 클라이언트 C1은 프록시 서버에 요청 메시지를 발신하고, 이후에 프록시 서버는 RDC 내의 웹 서버에 요청 메시지를 전송한다.
S4: RDC 내의 웹 서버는 요청 메시지를 수신하고, 액세스될 수 있는 미디어 서버에 대한 응답 메시지를 클라이언트 C1에 발신하는데, 응답 메시지는 클라이언트 C1에 의해 액세스될 수 있는 미디어 서버를 클라이언트 C1에 통지하는 데에 사용된다. 구체적으로, 웹 서버는, 요청 메시지에 기반하여, 클라이언트 C1을 위해 미디어 스트림 서비스를 제공하는 것이 가능한 타겟(target) 미디어 서버를 판정하고(타겟 미디어 서버는 RDC 내의 복수의 미디어 서버 중 하나임); 이후에 클라이언트 C1에 응답 메시지를 발신한다(응답 메시지는 타겟 미디어 서버의 관련된 정보, 예를 들어, 타겟 미디어 서버의 유니폼 리소스 로케이터(Uniform Resource Locator, URL) 정보, IP 주소 및 포트 번호를 포함함).
선택적으로, 웹 서버는 액세스될 수 있는 미디어 서버에 대한 것인, 클라이언트 C1에 의해 발신된 요청 메시지 내에 반송되는(carried) IP 주소에 기반하여 클라이언트 C1의 위치를 판정하고, 위치 정보에 기반하여 클라이언트 C1에 가장 가까운 미디어 서버를 타겟 미디어 서버로서 선택한다.
선택적으로, RDC 내의 웹 서버는 프록시 서버를 통해서 클라이언트 C1에 응답 메시지를 발신한다. 응답 메시지는 타겟 미디어 서버의 관련된 정보, 예를 들어, 타겟 미디어 서버의 URL 정보, IP 주소 및 포트 번호를 반송한다.
S5: 클라이언트 C1은 라이브 브로드캐스트 룸에 입장하고, 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 프록시 서버에 발신하는데, 제1 라이브 브로드캐스트 룸 요청 메시지는 클라이언트 C1이 라이브 브로드캐스트 룸에 입장하기를 요청함을 지시한다(indicate). 제1 라이브 브로드캐스트 룸 요청 메시지는 클라이언트 C1의 사용자 이름, IP 주소 및 포트 번호, 라이브 브로드캐스트 룸의 이름, 인증이 성공한 후에 획득된 토큰 및 유사한 것을 포함한다.
S6: 프록시 서버는 클라이언트 C1에 의해 발신된 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하고, 클라이언트 C1의 역할을 설정한다. 가능한 구현에서, 제1 라이브 브로드캐스트 룸 요청 메시지를 수신한 후에, 프록시 서버는 마스터 사용자가 역할인 클라이언트의 총 수효에 기반하여 클라이언트 C1의 역할을 판정하고; 만일 총 수효가 제1 임계 이하인 경우, 클라이언트 C1의 역할은 마스터 사용자이거나, 만일 총 수효가 제1 임계보다 큰 경우, 클라이언트 C1의 역할은 슬레이브 사용자이다. 이 실시예에서, 제1 임계가 1이고, 클라이언트 C1이 라이브 브로드캐스트 룸에 처음 입장하는 사용자이라고 가정하면, 만일 마스터 사용자가 역할인 클라이언트의 수효가 현재의 시점에서 제1 임계와 같은 경우, 프록시 서버는 클라이언트 C1의 역할이 마스터 사용자임을 판정한다.
대안적으로, 다른 가능한 구현에서, 제1 라이브 브로드캐스트 룸 요청 메시지를 수신한 후에, 프록시 서버는 라이브 브로드캐스트 룸 내에 마스터 사용자로서 이바지하는 클라이언트가 있는지를 판정한다. 만일 라이브 브로드캐스트 룸 내에 마스터 사용자로서 이바지하는 클라이언트가 있는 경우, 프록시 서버는 클라이언트 C1의 역할이 슬레이브 사용자임을 판정하되; 그렇지 않은 경우, 프록시 서버는 클라이언트 C1가 마스터 사용자임을 판정한다.
선택적으로, 방법은 다음을 더 포함한다: 클라이언트 C1이 라이브 브로드캐스트 룸에 입장한 후에, 프록시 서버는 "라이브 브로드캐스트 룸 사용자 관계 테이블"을 구축하는데, "라이브 브로드캐스트 룸 사용자 관계 테이블"은 클라이언트 C1에 대한 엔트리(entry)를 포함한다. 구체적으로, 엔트리의 콘텐트는 다음을 포함한다: 클라이언트 C1의 IP 주소, 포트 번호, 사용자 역할 및 사용자 이름, RDC 내의 선택된 타겟 미디어 서버의 IP 주소 및 포트 번호, 그리고 라이브 브로드캐스트 룸의 이름. 클라이언트 C1의 IP 주소는 데이터베이스 내에 캐싱된 주된 키(primary key)일 수 있다. 이해가능하게는, 라이브 브로드캐스트 룸에 처음 입장하기 위한 것이고 클라이언트에 의해 발신된 것인 요청 메시지를 수신하는 경우에, 프록시 서버는 라이브 브로드캐스트 룸 요청 메시지에 기반하여 라이브 브로드캐스트 룸 사용자 관계 테이블을 구축하여, 라이브 브로드캐스트 룸 내의 각각의 클라이언트의 상태를 기록한다.
이 실시예에서, 마스터 사용자가 역할인 클라이언트의 수효는 1이다. 곧, 프록시 서버를 통해서 라이브 브로드캐스트 룸에 입장하는 클라이언트 중에서, 오직 하나의 마스터 사용자가 설정되고, 다른 클라이언트는 슬레이브 사용자이다. 그러한 시나리오는 단일 마스터 사용자가 있는 시나리오로서 지칭될 수 있다.
S7: 프록시 서버는 RDC 내의 미디어 서버에 제1 라이브 브로드캐스트 룸 요청 메시지를 전송한다.
단계 S6는 단계 S7 전에 수행될 수 있거나 단계 S6는 단계 S7 후에 수행될 수 있다. 이것은 이 출원에서 엄격히 한정되지 않는다.
S8: RDC 내의 미디어 서버는 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하고, 클라이언트 C1에 제1 라이브 브로드캐스트 룸 응답 메시지를 발신하는데, 제1 라이브 브로드캐스트 룸 응답 메시지는 클라이언트 C1이 라이브 브로드캐스트 룸에 성공적으로 입장함을 클라이언트 C1에 통지하는 데에 사용된다. 구체적으로, S8에서, 미디어 서버는 프록시 서버를 통해서 클라이언트 C1에 제1 라이브 브로드캐스트 룸 응답 메시지를 전송한다.
S9: 클라이언트 C1은 프록시 서버에 제1 미디어 요청 메시지를 발신하는데, 제1 미디어 요청 메시지는 미디어 서버로부터 제1 라이브 미디어 스트림을 획득하기를 요청하는 데에 사용된다. 선택적으로, 제1 미디어 요청 메시지는 클라이언트 C1의 제1 식별자를 반송하는데, 제1 식별자는 클라이언트 C1을 고유하게 식별하는 데에 사용된다. 이 실시예에서, 제1 식별자는 클라이언트 C1의 IP 주소 및 사용자 이름 및 유사한 것을 포함한다.
S10: 프록시 서버는 제1 미디어 요청 메시지를 수신하고 RDC 내의 미디어 서버에 전송하는데, 미디어 서버는 타겟 미디어 서버이다. 제1 미디어 요청 메시지는 마스터 사용자로서 이바지하는 클라이언트 C1에 의해 요청되고, 따라서 프록시 서버는 미디어 서버에 제1 미디어 요청 메시지를 전송한다.
S11: 제1 미디어 요청 메시지를 수신한 후에, 미디어 서버는 클라이언트 C1에 제1 미디어 응답 메시지를 발신하는데, 제1 미디어 응답 메시지는 클라이언트 C1이 제1 라이브 미디어 스트림을 획득하도록 허용됨을 클라이언트 C1에 통지하는 데에 사용된다. 구체적인 구현에서, 프록시 서버는 제1 미디어 응답 메시지를 수신하고 클라이언트 C1에 전송한다.
S12: 미디어 서버는 클라이언트 C1에 제1 라이브 미디어 스트림을 발신한다. 구체적으로, 미디어 서버는 상위 레벨 EDC 내의 미디어 서버에 의해 발신된 제1 라이브 미디어 스트림을 실시간으로 획득하고, 이후에 제1 라이브 미디어 스트림을 프록시 서버에 발신한다. 제1 라이브 미디어 스트림을 수신한 후에, 프록시 서버는 GOP 단위로 제1 라이브 미디어 스트림의 세그먼트를 로컬로 캐싱한다. 예를 들어, 프록시 서버는 3개의 최근 GOP의 미디어 스트림 세그먼트(t1-t2, t2-t3 및 t3-t4)를 캐싱하고, 캐싱된 미디어 스트림의 모든 세그먼트는 동일한 시간 길이를 갖는다. 예를 들어, 각각의 캐싱된 GOP의 시간 길이는 5초이다. 프록시 서버는 캐싱된 제1 라이브 미디어 스트림의 세그먼트를 클라이언트 C1에 발신한다.
선택적으로, S12에서, 클라이언트 C1에 제1 라이브 미디어 스트림을 발신하는 프로세스에서, 제1 라이브 미디어 스트림의 타임스탬프는 또한, 조절된 타임스탬프가 클라이언트 C1에 발신된 제1 라이브 미디어 스트림의 제1 프레임의 타임스탬프가 0이고, 클라이언트 C1에 발신된 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 만족시키도록, 조절될 필요가 있다. "연속적"은 클라이언트 C1에 의해 수신된 제1 라이브 미디어 스트림의 인접한 비디오 프레임의 시간 길이가 동일함을 의미하고, 시간 길이는 프레임 레이트 파라미터 f의 역수이다.
다음은 클라이언트 C2가 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 획득하는 방법을 기술한다. 구체적으로, 다음의 단계가 포함된다.
S13: 클라이언트 C2는 액세스될 수 있는 미디어 서버에 대한 요청 메시지를 RDC 내의 웹 서버에 발신하는데, 요청 메시지는 클라이언트 C2의 사용자 이름 및 IP 주소, 라이브 브로드캐스트 룸의 이름, 그리고 클라이언트 C2가 인증된 후에 획득된 키 토큰과 같은 정보를 포함한다. 구체적으로, 클라이언트 C2는 프록시 서버를 통해서 RDC 내의 웹 서버에 요청 메시지를 전송하고; 요청 메시지의 전송 동안에, 프록시 서버는 요청 메시지 내에 반송되는 정보를 획득한다.
S14: RDC 내의 웹 서버는 요청 메시지를 수신하고, 응답 메시지를 클라이언트 C2에 발신하는데, 응답 메시지는 클라이언트 C2에 의해 액세스될 수 있는 미디어 서버를 클라이언트 C2에 통지하는 데에 사용된다. 이는 전술한 단계(S4)와 동일하고, 웹 서버는 클라이언트 C2를 위해 미디어 스트림 서비스를 제공하기 위해 복수의 미디어 서버 중 하나를 선택하고, 선택된 미디어 서버의 관련된 정보를 프록시 서버에 응답 메시지를 통해서 발신한다. 예를 들어, 선택된 미디어 서버의 관련된 정보는 미디어 서버의 URL 정보, IP 주소 및 포트 번호를 포함한다.
S15: 클라이언트 C2는 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제2 라이브 브로드캐스트 룸 요청 메시지를 프록시 서버에 발신하는데, 제2 라이브 브로드캐스트 룸 요청 메시지는 클라이언트 C2가 라이브 브로드캐스트 룸에 입장하기를 요청함을 지시한다. 제2 라이브 브로드캐스트 룸 요청 메시지는 클라이언트 C2의 사용자 이름, IP 주소 및 포트 번호, 라이브 브로드캐스트 룸의 이름, 인증이 성공한 후에 획득된 토큰 및 유사한 것을 포함한다.
S16: 프록시 서버는 클라이언트 C2에 의해 발신된 제2 라이브 브로드캐스트 룸 요청 메시지를 수신하고, 클라이언트 C2의 역할을 설정한다. 구체적인 구현은, 제2 라이브 브로드캐스트 룸 요청 메시지를 수신한 후에, 프록시 서버는 라이브 브로드캐스트 내에 마스터 사용자가 역할인 클라이언트가 있는지를 판정하고; 만일 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는 경우, 프록시 서버는 클라이언트 C2의 역할이 슬레이브 사용자임을 판정한다. 이 실시예에서, 현재의 라이브 브로드캐스트 룸 내에 마스터 사용자로서 이바지하는 클라이언트 C1이 있고, 따라서 클라이언트 C2는 슬레이브 사용자로서 판정된다.
추가로, S16은 다음을 더 포함한다: 프록시 서버는 클라이언트 C2에 대한 엔트리를 "라이브 브로드캐스트 룸 사용자 관계 테이블"에 추가한다. 이는 위에서 기술된 클라이언트 C1의 엔트리를 추가하는 것과 유사하다. 클라이언트 C2에 대해, 엔트리의 콘텐트는 클라이언트 C2의 IP 주소, 포트 번호, 사용자 역할 및 사용자 이름, 타겟 미디어 서버의 IP 주소 및 포트 번호, 그리고 라이브 브로드캐스트 룸의 이름과 같은 정보를 포함한다.
선택적으로, S16에서, 라이브 브로드캐스트 룸 내에서 현재 마스터 사용자로서 이바지하는 클라이언트의 수효가 계산되고, 마스터 사용자로서 이바지하는 클라이언트의 수효는 현재의 시점에서 획득된 라이브 브로드캐스트 룸 요청 메시지의 수효에 기반하여 판정될 수 있는데, 라이브 브로드캐스트 룸 요청 메시지의 수효는"라이브 브로드캐스트 룸 사용자 관계 테이블" 내에 기록된다. 이 실시예에서, 프록시 서버는 2개의 라이브 브로드캐스트 룸 요청 메시지(클라이언트 C1으로부터의 제1 라이브 브로드캐스트 룸 요청 메시지 및 클라이언트 C2로부터의 제2 라이브 브로드캐스트 룸 요청 메시지)를 수신하고, 라이브 브로드캐스트 룸 요청 메시지의 수효는 1보다 크다. 따라서, 클라이언트 C2가 슬레이브 사용자임이 판정된다. 추가로, 마스터 사용자로서 이바지하는 클라이언트의 수효는 다른 방식으로 판정될 수 있다. 이것은 이 출원에서 한정되지 않는다.
S17: 프록시 서버는 제2 라이브 브로드캐스트 룸 요청 메시지를 수신하고 RDC 내의 미디어 서버에 전송한다.
S18: RDC 내의 미디어 서버는 제2 라이브 브로드캐스트 룸 요청 메시지를 수신하고, 클라이언트 C2에 제2 라이브 브로드캐스트 룸 응답 메시지를 발신하는데, 제2 라이브 브로드캐스트 룸 응답 메시지는 클라이언트 C2가 라이브 브로드캐스트 룸에 성공적으로 입장함을 클라이언트 C2에 통지하는 데에 사용된다. 구체적으로, 미디어 서버는 프록시 서버를 통해서 클라이언트 C2에 제2 라이브 브로드캐스트 룸 응답 메시지를 전송한다.
S19: 클라이언트 C2는 프록시 서버에 제2 미디어 요청 메시지를 발신하는데, 제2 미디어 요청 메시지는 미디어 서버로부터 라이브 미디어 스트림을 획득하기를 요청하는 데에 사용된다. 제2 미디어 요청 메시지는 클라이언트 C2의 제2 식별자를 반송하는데, 제2 식별자는 클라이언트 C2의 IP 주소 및 사용자 이름을 포함한다.
프록시 서버는 제2 미디어 요청 메시지가 클라이언트 C2(이의 역할은 슬레이브 사용자임)에 의해 발신되기 때문에 미디어 서버에 제2 미디어 요청 메시지를 전송하지 않는다.
S20: 프록시 서버는 제2 미디어 요청 메시지를 수신하고, 클라이언트 C2에 제2 미디어 응답 메시지를 발신하는데, 제2 미디어 응답 메시지는 클라이언트 C2가 제1 라이브 미디어 스트림을 획득하도록 허용됨을 클라이언트 C2에 통지하는 데에 사용된다.
S21: 프록시 서버는 로컬로 캐싱된 제1 라이브 미디어 스트림을 클라이언트 C2에 발신하는데, 제1 라이브 미디어 스트림은 GOP 단위로 캐싱되고 전달된다. 또한, GOP 단위로 캐싱된 미디어 스트림의 세그먼트에 대해, S12에서의 설명을 참조하시오. 세부사항은 여기에서 다시 기술되지 않는다.
선택적으로, 프록시 서버가 클라이언트 C2에 제1 라이브 미디어 스트림을 발신하는 경우에, 방법은 다음을 더 포함한다: 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 두 제약을 만족시키도록, 조절하는 것: 1. 클라이언트 C2에 의해 수신된 제1 라이브 미디어 스트림의 제1 프레임의 타임스탬프가 0임; 및 2. 클라이언트 C2에 발신된 제1 라이브 미디어 스트림 비디오의 인접한 프레임의 타임스탬프가 연속적임, 즉, 발신을 위한 시간 길이는 프레임 레이트 파라미터 f의 역수임. 구체적인 조절 프로세스에 대해, 전술한 실시예에서의 설명을 참조하시오.
S22: RDC 내의 미디어 서버는 실시간으로 클라이언트 C1에 제1 라이브 미디어 스트림을 발신한다. 구체적으로, 제1 라이브 미디어 스트림은 프록시 서버를 통해서 클라이언트 C1에 전송될 수 있다. 제1 라이브 미디어 스트림은 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트 C1에 의해 발동되고 획득된다.
S23: 미디어 서버로부터 제1 라이브 미디어 스트림을 수신한 후에, 프록시 서버는 GOP 단위로 제1 라이브 미디어 스트림의 세그먼트를 로컬로 캐싱한다. 이 실시예에서, 프록시 서버는 3개의 GOP를 로컬로 캐싱하며, 또한 더 많거나 더 적은 GOP를 캐싱할 수 있다.
S24: 프록시 서버는, "라이브 브로드캐스트 룸 사용자 관계 테이블" 내의 엔트리의 콘텐트에 기반하여, 마스터 사용자로서 이바지하는 클라이언트의 수효 및 슬레이브 사용자로서 이바지하는 클라이언트의 수효를 판정하고, 제1 라이브 미디어 스트림의 캐싱된 세그먼트를 복제하여, 라이브 브로드캐스트 룸 내의 클라이언트에 세그먼트를 발신하기를 준비한다. 이 실시예에서, 현재의 라이브 브로드캐스트 룸 내에 오직 두 클라이언트(클라이언트 C1 및 클라이언트 C2)가 있는데, 클라이언트 C1은 마스터 사용자이고, 클라이언트 C2는 슬레이브 사용자이다.
S25: 프록시 서버는 클라이언트 C1에 제1 라이브 미디어 스트림을 발신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제1 라이브 미디어 스트림 내의 타임스탬프를, 클라이언트 C1이 미디어 스트림의 비디오 프레임을 수신하는 시점에 기반하여 조절한다.
S26: 프록시 서버는 클라이언트 C2에 제1 라이브 미디어 스트림을 발신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제1 라이브 미디어 스트림 내의 타임스탬프를, 클라이언트 C2가 미디어 스트림의 비디오 프레임을 수신하는 시점에 기반하여 조절한다.
추가로, 라이브 브로드캐스트 룸 내의 클라이언트 C1 및 클라이언트 C2가 제1 라이브 브로드캐스트의 미디어 콘텐트를 "동기식으로" 관람할 수 있도록(이로써, 사용자 경험을 개선함), 라이브 브로드캐스트 룸에 입장하는 사용자에 의해 관람되는 비디오 프레임의 타임스탬프가 조절된다.
방법에 따르면, 마스터 사용자로서 이바지하는 클라이언트에 의해 요청된 라이브 미디어 스트림을 획득하는 데에 프록시 서버가 사용되는 경우에, 미디어 스트림의 세그먼트의 일부가 프록시 서버 내에 로컬로 캐싱된다. 슬레이브 사용자가 역할인 클라이언트가 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 요청하는 경우에, 로컬로 캐싱된 미디어 스트림은 슬레이브 사용자로서 이바지하는 클라이언트에 직접적으로 발신되어서, 미디어 서버는 다시 프록시 서버에 라이브 미디어 스트림을 발신할 필요가 없는바, 즉, 미디어 서버는 프록시 서버에 오직 하나의 라이브 미디어 스트림을 발신할 필요가 있고, 프록시 서버는 라이브 미디어 스트림을 복제하고 라이브 브로드캐스트 룸 내에서 슬레이브 사용자로서 이바지하는 모든 클라이언트에 전달할 수 있다. 이것은 미디어 스트림을 발신하기 위한 트래픽을 감소시키고, 이출 대역폭을 효과적으로 절감하며, 리소스 오버헤드를 감소시킨다.
추가로, 이 방법에 따르면, 동일한 라이브 브로드캐스트 룸 내의 모든 클라이언트에 대해, 미디어 서버는 프록시 서버에 오직 하나의 라이브 미디어 스트림을 발신할 필요가 있는바, 즉, 하나의 라이브 미디어 스트림을 송신하기 위한 광역 네트워크 대역폭이 요구된다. 미디어 서버에 의해 모든 클라이언트에 라이브 미디어 스트림을 발신하기 위해 점유되는 송신 리소스에 비해, 이는 광역 네트워크 링크의 로드를 감소시키고, 모든 클라이언트가 라이브 브로드캐스트 미디어를 수신한 후, 라이브 미디어 스트림의 재생 동안 비디오 동결을 방지하고, 따라서 이 방법을 사용함으로써 사용자 경험을 또한 개선한다.
추가로, 이 실시예의 방법에 따르면, 클라이언트 C1의 제1 라이브 브로드캐스트 룸 요청 메시지 및 제1 미디어 요청 메시지는 하나의 메시지로 조합될 수 있고, 조합된 메시지는 제1 라이브 브로드캐스트 룸 요청 메시지 및 제1 미디어 요청 메시지의 기능을 갖는다. 따라서, S6에서 클라이언트 C1의 역할이 판정된 경우에, 현재 라이브 브로드캐스트 룸에 입장하는 마스터 사용자로서 이바지하는 클라이언트의 수효는 제1 미디어 요청 메시지의 수효에 기반하여 계산될 수 있다. 유사하게, 클라이언트 C2의 제2 라이브 브로드캐스트 룸 요청 메시지 및 제2 미디어 요청 메시지는 또한 하나의 메시지로 조합될 수 있다.
추가로, 이 실시예에서 제공되는 방법은 클라이언트 C2의 역할이, 예를 들어, 슬레이브 사용자로부터 마스터 사용자로, 바뀌는 경우에 미디어 서버가 클라이언트 C2에 라이브 미디어 스트림을 발신하는 프로세스를 더 포함한다. 또한, 도 5a 및 도 5b에 도시된 바와 같이, S27 내지 S39가 구체적인 방법 절차인데, 이는 다음과 같다:
S27: 클라이언트 C1은 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 프록시 서버에 발신하는데, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지는 클라이언트 C1이 라이브 브로드캐스트 룸에서 퇴장할 것임을 미디어 서버에 통지하는 데에 사용된다. 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지는 클라이언트 C1의 사용자 이름, IP 주소, 포트 번호 및 사용자 역할, 그리고 라이브 브로드캐스트 룸 이름과 같은 정보를 포함한다.
S28: 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 클라이언트 C1으로부터 수신한 후에, 마스터 사용자가 역할인 클라이언트 C1에 의해 요청된 제1 라이브 미디어 스트림이 이 시간에 클라이언트 C2에 의해 관람되고 있기 때문에, 프록시 서버는 일시적으로, 미디어 서버에, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 전송하지 않는다. 추가로, C1의 역할은 퇴장(Exiting) 사용자로서 표지되고(marked), "라이브 브로드캐스트 룸 사용자 관계 테이블" 내에 기록된다.
S29: 프록시 서버는 라이브 브로드캐스트 룸 내의 하나의 클라이언트를 새로운 마스터 사용자로서 선택한다. 이 실시예에서, 라이브 브로드캐스트 룸 내에 오직 클라이언트 C1 및 클라이언트 C2가 있다. 클라이언트 C1이 라이브 브로드캐스트 룸에서 퇴장하기를 요청하는 경우에, 남은 유일한 클라이언트 C2는 새로운 마스터 사용자로서 이바지하는 클라이언트로서 선택되고, 클라이언트 C2의 역할은 슬레이브 사용자로부터 마스터 사용자로 변경되는바, 예를 들어, 클라이언트 C2는 슬레이브로부터의 마스터(slave-to-master) 사용자로서 표지된다.
S30: 프록시 서버는 미디어 스트림을 획득하기 위한 제3 미디어 요청 메시지를 RDC 내의 미디어 서버에 발신하는데, 제3 미디어 요청 메시지는 클라이언트 C2의 제2 식별자를 포함한다. 제2 식별자는 클라이언트 C2를 고유하게 식별하는 데에 사용된다. 다시 말해, 제3 미디어 요청 메시지 내의 제2 식별자는 클라이언트 C2의 역할이 미디어 서버에 라이브 미디어 스트림을 요청하는 데에 사용됨을 지시한다.
S31: RDC 내의 미디어 서버는 제3 미디어 요청 메시지를 수신하고, 클라이언트 C2에 제3 미디어 응답 메시지를 발신하는데, 제3 미디어 응답 메시지는 클라이언트 C2가 라이브 미디어 스트림을 획득하도록 허용됨을 클라이언트 C2에 통지하는 데에 사용된다.
추가로, 미디어 서버는 제3 미디어 요청 메시지 내에 반송되는 제2 식별자를 수신하고, 클라이언트 C2가 미디어 서버에 라이브 미디어 스트림을 획득하기 위한 요청을 발동함을 판정하고, 또한 현재의 요청 메시지 내에 반송된 제2 식별자가 제1 미디어 요청 메시지 내에 반송된 제1 식별자와 상이함을 판정한다. 제1 식별자는 클라이언트 C1을 지시하는 데에 사용되고, 현재의 제2 식별자는 클라이언트 C2를 지시하는 데에 사용되며, 그것은 라이브 미디어 스트림 요청을 발동하는 클라이언트가 클라이언트 C1으로부터 클라이언트 C2로 바뀜을 지시한다.
S32: 제3 미디어 요청 메시지를 발동하는 클라이언트의 역할이 슬레이브로부터의 마스터 사용자이기 때문에 프록시 서버는 제3 미디어 응답 메시지를 전송하지 않는다. 이 경우에, 클라이언트 C2의 역할이 마스터 사용자로 변경되고, "라이브 브로드캐스트 룸 사용자 관계 테이블" 내의 클라이언트 C2에 대응하는 엔트리 내에 기록된다.
S33: 미디어 서버는 프록시 서버를 통해서 클라이언트 C2에 제2 라이브 미디어 스트림을 발신한다. 제2 라이브 미디어 스트림의 콘텐트는 제1 라이브 미디어 스트림의 콘텐트와 동일하고, 제2 라이브 미디어 스트림 및 제1 라이브 미디어 스트림 양자 모두는 콘텐트 소스로부터의 것이다.
S34: 프록시 서버는 제2 라이브 미디어 스트림을 수신하고, GOP 단위로 제2 라이브 미디어 스트림을 로컬로 캐싱한다.
추가로, 방법은 다음을 더 포함한다: 프록시 서버는 클라이언트 C1 및 클라이언트 C2에 발신될 라이브 미디어 스트림을 정렬 알고리즘에 따라 정렬한다. 구체적으로, 프로세서는 다음을 포함한다: 프록시 서버가 제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 라이브 미디어 스트림의 제1 프레임(이는 이하에서 전환 프레임 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) 프레임은 자연히 인접한 프레임이다.
S35: 프록시 서버는 클라이언트 C2에 의해 현재 관람되는 비디오 프레임의 상대적인 위치에 기반하여 제2 라이브 미디어 스트림의 타임스탬프를 조절하여서, 클라이언트 C2에 발신된 비디오 프레임은 클라이언트 C2에 의해 수신된 제2 라이브 미디어 스트림의 제1 프레임 y의 타임스탬프 및 제1 라이브 미디어 스트림의 마지막 프레임 x의 타임스탬프가 연속적임을 만족시키고, 대응하는 시간 길이는 프레임 레이트 파라미터 f의 역수이다. 구체적인 조절 프로세스에 대해, 전술한 실시예에서의 설명을 참조하시오. 세부사항은 여기에서 다시 기술되지 않는다.
이 실시예에서, 마스터 사용자가 역할인 클라이언트 C1이 라이브 브로드캐스트 룸에서 퇴장하는 경우에, 새로운 마스터 사용자로서 이바지하는 클라이언트 C2가 제2 라이브 미디어 스트림을 요청하고 획득하는 데에 사용되고, 제2 라이브 미디어 스트림 및 원래 발신된 제1 라이브 미디어 스트림 간의 시간 차이가 조절되어서, 프록시 서버는, 클라이언트 C2에 제2 라이브 미디어 스트림을 발신하는 경우에, 원래 재생되고 있는 제1 라이브 미디어 스트림 미디어의 미디어 콘텐트로부터 제2 라이브 미디어 스트림으로 매끄럽게(seamlessly) 전환한다. 이 방식으로, 클라이언트 C2에 의해 비디오 콘텐트가 관람되는 경우에 어떤 반복적으로 재생되는 부분도 없고 재생되는 콘텐트가 온전하며(integral), 클라이언트 C2의 사용자 경험이 영향을 받지 않는다.
S36: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 RDC 내의 미디어 서버에 전송한다.
S37: 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신한 후에, 미디어 서버는, 클라이언트 C1에, 라이브 브로드캐스트 룸에서 퇴장하기 위한 응답 메시지를 발신하는데, 라이브 브로드캐스트 룸에서 퇴장하기 위한 응답 메시지는 클라이언트 C1이 라이브 브로드캐스트 룸에서 성공적으로 퇴장함을 클라이언트 C1에 통지하는 데에 사용된다. 구체적으로, 라이브 브로드캐스트 룸에서 퇴장하기 위한 응답 메시지는 프록시 서버를 통해서 클라이언트 C1에 전송된다.
S38: 프록시 서버는 "라이브 브로드캐스트 룸 사용자 관계 테이블"로부터 클라이언트 C1에 대응하는 엔트리를 삭제한다. S37은 S38 전에 수행될 수 있거나, S37은 S38 후에 수행될 수 있고, 이것은 한정되지 않는다.
S39: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한 응답 메시지를 클라이언트 C1에 전송한다.
추가로, 방법은 다음을 더 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에서 비디오를 관람하고 있는 클라이언트 C2에 제2 라이브 미디어 스트림을 발신한다.
이 실시예에서 제공된 방법에 따르면, 마스터 사용자로서 이바지하는 클라이언트가 라이브 브로드캐스트 룸에서 퇴장하는 경우에, 프록시 서버는 라이브 브로드캐스트 룸 내의 새로운 클라이언트를 새로운 마스터 사용자로서 선택하고, 새로운 마스터 사용자의 역할은 라이브 미디어 스트림을 요청하는 것을 계속하는 데에 사용된다. 라이브 미디어 스트림이 새로운 마스터 사용자에 의해 획득되고, 비디오 프레임의 타임스탬프가 조절된 후에, 새로 획득된 라이브 미디어 스트림은 라이브 브로드캐스트 룸 내에서 여전히 비디오를 관람하고 있는 클라이언트에 발신되어서, 마스터 사용자로서 이바지하는 클라이언트가 퇴장하는 경우에 다른 클라이언트가 영향을 받지 않는다. 이 방법에 따르면, 라이브 미디어 스트림의 전환 동안에, 어떤 반복적으로 재생되는 부분도 없고 재생되는 콘텐트는 온전하며, 라이브 브로드캐스트 룸 내의 다른 사용자가 라이브 미디어 스트림의 전환을 모르기 때문에 사용자 경험이 개선된다.
실시예 2:
이 실시예는 다른 라이브 미디어 스트림 발신 방법을 제공한다. 방법은 복수의 마스터 사용자가 있는 기술적 시나리오에 적용된다. 복수의 마스터 사용자는 마스터 사용자가 역할인, 라이브 브로드캐스트 룸 내의 클라이언트의 지정된 수효(즉, 사전설정된 상한)가 2 이상임을 의미한다. 또한, 복수의 마스터 사용자는 하나의 주 마스터 사용자(이는 주 마스터 사용자로서 식별될 수 있음)를 포함하고; 복수의 부 마스터 사용자(이는 부 마스터 사용자로서 식별될 수 있음)를 포함하고; 슬레이브 사용자가 역할인 적어도 하나의 클라이언트를 더 포함한다. 이 방법에서 라이브 브로드캐스트 룸에 입장하기를 요청하고 라이브 미디어 스트림을 획득하는 프로세스는 실시예 1에 기술된 프로세스와 동일하다. 차이점은 클라이언트의 역할을 식별하고 변경하는 것 및 라이브 미디어 스트림의 전달에 있다.
실시예 1을 기반으로, 이 실시예에서, 제3 클라이언트 C3가 더 포함되고, 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효는 2로 설정되는바, 즉, 사전설정된 상한은 2이다. 이 경우에, 각각의 클라이언트가 라이브 브로드캐스트 룸에 입장하고 라이브 미디어 스트림을 획득하기를 요청하는 프로세스는, 도 6a 및 도 6b에 도시된 바와 같이, 다음의 단계를 포함한다.
S1 내지 S12는 클라이언트 C1이 라이브 브로드캐스트 룸에 입장하고, 라이브 미디어 스트림을 획득하기를 요청하는 프로세스이다. 이 프로세스는 실시예 1에서의 S1 내지 S12와 동일하고, 오직 차이점은 다음에 있다: S6에서, "라이브 브로드캐스트 룸 사용자 관계 테이블"이 수립되는 경우에 클라이언트 C1의 역할은 주 마스터 사용자(main-master user)로서 설정된다. 다른 단계에 대해, 실시예 1에서의 설명을 참조하시오. 세부사항은 여기에서 다시 기술되지 않는다.
프록시 서버가 미디어 서버에 의해 발신된 제1 라이브 미디어 스트림을 획득하는 경우에, 프록시 서버는 GOP 단위로 제1 라이브 미디어 스트림의 몇 개의 세그먼트를 로컬로 캐싱하고, 실시간으로 제1 라이브 미디어 스트림의 세그먼트를 갱신하고, 클라이언트 C1에 제1 라이브 미디어 스트림의 세그먼트를 발신한다.
S13 내지 S29는 클라이언트 C2가 라이브 브로드캐스트 룸에 입장하고, 라이브 미디어 스트림을 획득하기를 요청하는 프로세스이다. 구체적으로, 세부사항은 다음과 같다.
S13 및 S14는 클라이언트 C2가 라이브 브로드캐스트 룸에 입장하고, 액세스될 수 있는 미디어 서버를 획득하기 위한 요청 메시지를 발동하고, 응답 메시지를 획득하는 프로세스이다. 이는 실시예 1에서의 S13 및 S14과 동일하고, 세부사항은 다시 기술되지 않는다.
S15: 클라이언트 C2는 프록시 서버에 제2 라이브 브로드캐스트 룸 요청 메시지를 발신한다.
S16: 클라이언트 C2에 의해 발신된 제2 라이브 브로드캐스트 룸 요청 메시지를 수신한 후에, 프록시 서버는 현재의 라이브 브로드캐스트 룸 내의 라이브 브로드캐스트 룸 요청 메시지의 수효를 계산하고, 계산된 수효에 기반하여 클라이언트 C2의 역할을 판정한다. 이 실시예에서, 프록시 서버는 2개의 라이브 브로드캐스트 룸 요청 메시지를 클라이언트 C1 및 클라이언트 C2로부터 획득한다. 추가로, 만일 수효가 사전설정된 상한 2와 같은 경우, 프록시 서버는 클라이언트 C2의 역할이 부 마스터 사용자(secondary-master user)임을 판정한다. 대안적으로, 프록시 서버가 제2 라이브 브로드캐스트 룸 요청 메시지를 수신하고, 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는 경우에, 프록시 서버는 클라이언트 C2의 역할이 슬레이브 사용자임을 판정한다.
선택적으로, 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 0이 아니나 사전설정된 상한에 도달하지 않은 경우, 프록시 서버는 클라이언트 C2의 역할이 부 마스터 사용자임을 판정한다. 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 0인 경우, 프록시 서버는 클라이언트 C2의 역할이 주 마스터 사용자임을 판정한다.
추가로, 방법은 다음을 더 포함한다: 클라이언트 C2에 대한 엔트리를 "라이브 브로드캐스트 룸 사용자 관계 테이블"에 추가하는 것.
S17: 프록시 서버는 미디어 서버에 제2 라이브 브로드캐스트 룸 요청 메시지를 전송한다.
S18: RDC 내의 미디어 서버는 제2 라이브 브로드캐스트 룸 요청 메시지를 수신하고, 클라이언트 C2에 제2 라이브 브로드캐스트 룸 응답 메시지를 발신하는데, 제2 라이브 브로드캐스트 룸 응답 메시지는 클라이언트 C2가 라이브 브로드캐스트 룸에 성공적으로 입장함을 클라이언트 C2에 통지하는 데에 사용된다.
S19: 클라이언트 C2는 프록시 서버에 제2 미디어 요청 메시지를 발신한다.
S20: 제2 미디어 요청 메시지를 수신한 후에, 프록시 서버는 미디어 서버에 제2 미디어 요청 메시지를 전송한다. 제2 미디어 요청 메시지는 클라이언트 C2의 제2 식별자를 포함하여서, 클라이언트 C2는, 클라이언트 C2의 부 마스터 사용자의 역할을 사용함으로써, 미디어 서버에 라이브 미디어 스트림을 요청한다.
S21: 미디어 서버는, 클라이언트 C2가 제1 라이브 미디어 스트림을 획득하도록 허용됨을 클라이언트 C2에 통지하기 위해, 클라이언트 C2에 제2 미디어 응답 메시지를 발신한다.
S22: 프록시 서버는 로컬로 캐싱된 제1 라이브 미디어 스트림을 클라이언트 C2에 발신하는데, 제1 라이브 미디어 스트림은 GOP 단위로 캐싱된 미디어 스트림 세그먼트이다. 예를 들어, 프록시 서버는 3개의 GOP 세그먼트를 캐싱한다. 선택적으로, 방법은 다음을 더 포함한다: 프록시 서버는 클라이언트 C2에 의해 획득된 비디오 프레임의 재생 시간에 기반하여 제1 라이브 미디어 스트림의 타임스탬프를 조절하여서, 조절된 타임스탬프는 클라이언트 C2에 발신된 제1 라이브 미디어 스트림의 제1 프레임의 타임스탬프가 0이고 클라이언트 C2에 발신된 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 만족시킨다.
S23: 미디어 서버는 실시간으로 클라이언트 C2에 제2 라이브 미디어 스트림을 발신한다.
S24: 프록시 서버는 제2 라이브 미디어 스트림의 세그먼트를 수신하고 GOP 단위로 세그먼트를 캐싱한다. 클라이언트에 의해 부 마스터 사용자의 역할을 사용함으로써 제2 라이브 미디어 스트림이 획득되기 때문에, 단지 제2 라이브 미디어 스트림이 프록시 서버 내에 로컬로 캐싱되며, "라이브 브로드캐스트 룸 사용자 관계 테이블"에 기반하여 복제되고 다른 클라이언트에 전달되지 않는다.
추가로, 방법은 다음을 더 포함한다: 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림을 정렬하는 것. 구체적으로, 두 라이브 미디어 스트림을 정렬하는 프로세스는 전술한 실시예 1에서의 S34와 동일하다. 세부사항은 여기에서 다시 기술되지 않는다.
S25: 미디어 서버는 실시간으로 클라이언트 C1에 제1 라이브 미디어 스트림을 발신한다.
S26: 제1 라이브 미디어 스트림을 수신한 후에, 프록시 서버는 GOP 단위로 제1 라이브 미디어 스트림의 몇 개의 세그먼트를 캐싱한다.
S27: 현재의 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트 C1에 더하여, 오직 하나의 클라이언트 C2가 있기 때문에 프록시 서버는 "라이브 브로드캐스트 룸 사용자 관계 테이블"에 기반하여 제1 라이브 미디어 스트림의 하나의 사본(copy)을 만든다. 만일 더 많은 클라이언트가 있는 경우, 사본의 수효는 현재의 라이브 브로드캐스트 룸에서 사용자 역할이 퇴장 사용자가 아닌 클라이언트의 수효와 동일함이 이해되어야 한다.
이 실시예에서, 프록시 서버는 주 마스터 사용자가 역할인 클라이언트의 라이브 미디어 스트림 및 부 마스터 사용자가 역할인 클라이언트의 라이브 미디어 스트림을 로컬로 캐싱한다. 프록시 서버는 주 마스터 사용자가 역할인 클라이언트의 라이브 미디어 스트림을 라이브 브로드캐스트 룸 내의 모든 클라이언트에 직접적으로 전달할 수 있다. 차후의 전환 및 전달에 대한 준비를 하기 위해, 프록시 서버는 부 마스터 사용자가 역할인 클라이언트의 대응하는 라이브 미디어 스트림을 로컬로 캐싱한다. 구체적인 트리거(trigger) 조건은 다음이다: 부 마스터 사용자로서 이바지하는 클라이언트의 역할이 주 마스터 사용자로 변경된 경우에, 새로운 주 마스터 사용자의 (프록시 서버 내에 로컬로 캐싱된) 미디어 스트림이 라이브 브로드캐스트 룸 내의 다른 클라이언트에 전달된다. 프록시 서버는 새로운 라이브 미디어 스트림을 신속히 전달할 수 있다. 이는 전달 속도를 증가시키고 미디어 스트림의 효율을 개선하며, 대기 시간을 감소시킨다.
S28: 프록시 서버는 클라이언트 C1에 제1 라이브 미디어 스트림을 발신한다.
S29: 프록시 서버는 클라이언트 C2에 제1 라이브 미디어 스트림을 발신한다.
선택적으로, 단계 S28 및 S29에서, 방법은 다음을 더 포함한다: 프록시 서버는 클라이언트 C1의 재생 시간 및 클라이언트 C2의 재생 시간에 기반하여 제1 라이브 미디어 스트림의 타임스탬프를 조절하여, 라이브 브로드캐스트 룸 내의 클라이언트에 의해 관람되는 라이브 콘텐트의 동기화를 보장한다.
S30 내지 S44는 클라이언트 C3가 라이브 브로드캐스트 룸에 입장하고, 라이브 미디어 스트림을 요청하고 획득하는 프로세스이다. 도 7a 및 도 7b에 도시된 바와 같이, 세부사항은 다음과 같다.
S30 및 S31은 클라이언트 C3가 라이브 브로드캐스트 룸에 입장하고, 액세스될 수 있는 미디어 서버를 획득하기 위한 요청 메시지를 발동하고, 응답 메시지를 획득하는 프로세스이다. 프로세스는 실시예 1에서의 S13 및 S14과 동일하다. 세부사항은 다시 기술되지 않는다.
S32: 클라이언트 C3는 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제3 라이브 브로드캐스트 룸 요청 메시지를 프록시 서버에 발신하는데, 제3 라이브 브로드캐스트 룸 요청 메시지는 클라이언트 C3의 제3 식별자를 포함한다.
S33: 프록시 서버는 제3 라이브 브로드캐스트 룸 요청 메시지를 수신하고, 클라이언트 C3의 사용자 역할을 판정한다. 구체적으로, 제3 라이브 브로드캐스트 룸 요청 메시지가 획득된 경우에, 만일 현재의 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한(사전설정된 상한은 2임)에 도달하면, 프록시 서버는 클라이언트 C3의 역할이 슬레이브 사용자임을 판정한다.
추가로, 방법은 다음을 더 포함한다: 클라이언트 C3에 대한 엔트리를 "라이브 브로드캐스트 룸 사용자 관계 테이블"에 추가하는 것(엔트리의 콘텐트는 클라이언트 C3의 이름, IP 주소, 포트 번호 및 사용자 역할, 라이브 브로드캐스트 룸의 이름, 그리고 미디어 서버의 이름, IP 주소 및 포트 번호와 같은 정보를 포함함).
S34: 프록시 서버는 미디어 서버에 제3 라이브 브로드캐스트 룸 요청 메시지를 전송한다.
S35: 미디어 서버는 클라이언트 C3에 제3 라이브 브로드캐스트 룸 응답 메시지를 발신하는데, 제3 라이브 브로드캐스트 룸 응답 메시지는 클라이언트 C3가 라이브 브로드캐스트 룸에 성공적으로 입장함을 클라이언트 C3에 통지하는 데에 사용된다.
S36: 클라이언트 C3는 프록시 서버에 제3 미디어 요청 메시지를 발신하는데, 제3 미디어 요청 메시지는 미디어 서버로부터 라이브 미디어 스트림을 획득하기를 요청하는 데에 사용되고, 제3 미디어 요청 메시지는 클라이언트 C3의 식별자를 포함한다.
S37: 클라이언트 C3는 프록시 서버에 의해 제3 미디어 요청 메시지에 기반하여 피드백된(fed back) 제3 미디어 응답 메시지를 수신한다. 이 경우에, 클라이언트 C3의 역할은 슬레이브 사용자이다.
S38: 프록시 서버는 로컬로 캐싱된 제1 라이브 미디어 스트림을 클라이언트 C3에 발신한다.
S39: 미디어 서버는 실시간으로 클라이언트 C1에 제1 라이브 미디어 스트림을 발신한다.
S40: 제1 라이브 미디어 스트림을 수신한 후에, 프록시 서버는 GOP 단위로 제1 라이브 미디어 스트림의 세그먼트를 캐싱한다.
S41: 프록시 서버는 "라이브 브로드캐스트 룸 사용자 관계 테이블"에 기반하여 제1 라이브 미디어 스트림을 복제하고, 구체적으로 제1 라이브 미디어 스트림의 2개의 사본을 만드는데, 하나의 사본은 부 마스터 사용자가 역할인 클라이언트 C2를 위한 것이고 다른 사본은 슬레이브 사용자가 역할인 클라이언트 C3를 위한 것이다.
S42: 프록시 서버는 클라이언트 C1에 제1 라이브 미디어 스트림을 발신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제1 라이브 미디어 스트림의 타임스탬프를 조절한다.
S43: 프록시 서버는 클라이언트 C2에 제1 라이브 미디어 스트림을 발신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제1 라이브 미디어 스트림의 타임스탬프를 조절한다.
S44: 프록시 서버는 클라이언트 C3에 제1 라이브 미디어 스트림을 발신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제1 라이브 미디어 스트림의 타임스탬프를 조절한다.
이 실시예의 방법에 따르면, 상이한 클라이언트의 미디어 요청을 획득하는 경우에, 프록시 서버가 마스터 사용자의 라이브 미디어 스트림만을 미디어 서버로부터 획득하도록, 프록시 서버는 각각의 클라이언트의 사용자 역할을 식별한다. 주 마스터 사용자 및 부 마스터 사용자가 있다. 라이브 미디어 스트림은 슬레이브 사용자를 위해 획득되지 않으나, 프록시 서버에 의해 로컬로 캐싱된 제1 라이브 미디어 스트림의 세그먼트는 대응하는 클라이언트에 발신된다. 이는 미디어 서버로 하여금 슬레이브 사용자로서 이바지하는 클라이언트에 라이브 미디어 스트림을 발신하지 않도록 하고, 또한 라이브 브로드캐스트 룸 내에서 슬레이브 사용자가 역할인 클라이언트에 의해 요청된 라이브 미디어 스트림의 수효를 감소시킨다. 이 방법을 사용하는 것은 미디어 서버 및 프록시 서버 간의 라이브 미디어 스트림 송신을 위한 리소스 오버헤드를 감소시킨다.
추가로, 이 실시예에서 제공되는 방법은 다음의 프로세스를 더 포함한다: 클라이언트 C1이 라이브 브로드캐스트 룸에서 퇴장한 후에, 미디어 서버는 계속해서 라이브 미디어 스트림을 라이브 브로드캐스트 룸 내의 클라이언트 C2 및 클라이언트 C3에 발신한다. 구체적으로, 도 8a 및 도 8b에 도시된 바와 같이, 프로세스는 S45 내지 S59를 포함한다. 방법 절차는 실시예 1에서의 클라이언트 C1의 기존 프로세스와 유사하나, 라이브 브로드캐스트 룸 내의 클라이언트 C2 및 클라이언트 C3를 위해 구성되는 신원 역할이 상이하며 클라이언트 C2 및 클라이언트 C3에 발신되는 라이브 미디어 스트림이 상이하다는 데에 차이가 있다. 구체적으로, 도 8a 및 도 8b에 도시된 바와 같이, 방법은 다음의 단계를 포함한다.
S45: 클라이언트 C1은 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 프록시 서버에 발신한다.
S46: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 클라이언트 C1으로부터 수신하고, "라이브 브로드캐스트 룸 사용자 관계 테이블" 내에 클라이언트 C1의 사용자 역할을 퇴장(Exiting) 사용자로서 표지하고, 클라이언트 C2의 사용자 역할을 주 마스터 사용자로 변경한다.
S47: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 미디어 서버에 전송한다.
S48: 프록시 서버는 라이브 브로드캐스트 룸 사용자 관계 테이블 내에 식별된 모든 슬레이브 사용자로부터 하나의 슬레이브 사용자를 선택하고, 슬레이브 사용자를 슬레이브로부터의 부 마스터(slave to secondary master) 사용자로 변경한다. 이 실시예에서, 선택되고 변경된 클라이언트는 클라이언트 C3이다.
S49: 프록시 서버는 미디어 서버에 제3 미디어 요청 메시지를 발신하는데, 제3 미디어 요청 메시지는 클라이언트 C3의 제3 식별자를 반송한다. 다시 말해, 프록시 서버는 클라이언트 C3의 역할을 사용함으로써 미디어 서버에 제3 미디어 요청 메시지를 발신한다.
S50: 미디어 서버는 프록시 서버를 통해서 클라이언트 C1에 라이브 브로드캐스트 룸에서 퇴장하기 위한 응답 메시지를 발신하는데, 라이브 브로드캐스트 룸에서 퇴장하기 위한 응답 메시지는 클라이언트 C1이 라이브 브로드캐스트 룸에서 성공적으로 퇴장함을 클라이언트 C1에 통지하는 데에 사용된다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 "라이브 브로드캐스트 룸 사용자 관계 테이블"로부터 클라이언트 C1의 관련된 엔트리를 삭제한다.
S51: 프록시 서버는 제3 미디어 요청 메시지에 기반하여 미디어 서버에 의해 피드백된 제3 미디어 응답 메시지를 수신한다.
S52: 클라이언트 C3의 현재의 역할은 슬레이브로부터의 부 마스터 사용자이고, 프록시 서버는 일시적으로 제3 미디어 응답 메시지를 전송하지 않으나, "라이브 브로드캐스트 룸 사용자 관계 테이블" 내에 클라이언트 C3의 사용자 역할을 부 마스터 사용자로 변경한다.
S53: 미디어 서버는 프록시 서버를 통해서 클라이언트 C3에 제3 라이브 미디어 스트림을 발신하고, 이에 따라 프록시 서버는 제3 라이브 미디어 스트림을 수신한다.
S54: 프록시 서버는 GOP 단위로 제3 라이브 미디어 스트림을 캐싱하고, 정렬 알고리즘에 따라 제3 라이브 미디어 스트림 및 제2 라이브 미디어 스트림을 정렬한다. 라이브 미디어 스트림을 정렬하는 구체적인 프로세스는 전술한 실시예 1에서의 S34와 유사하다. 세부사항에 대해, S34에서의 관련된 설명을 참조하시오. 세부사항은 여기에서 다시 기술되지 않는다.
이 실시예에서, 라이브 브로드캐스트 룸 내에서 주 마스터 사용자로서 이바지하는 클라이언트가 퇴장하는 경우에, 라이브 브로드캐스트 룸에서 퇴장하지 않는 부 마스터 사용자의 신원을 사용함으로써 라이브 미디어 스트림이 요청되고, 라이브 미디어 스트림을 획득하는 클라이언트의 역할이 변경되고, 수신된 새로운 라이브 미디어 스트림에 대해 정렬이 수행된다. 이 방식으로, 다른 사용자가 라이브 비디오를 관람하는 경우에 어떤 반복적으로 재생되는 픽처도 없고 재생되는 비디오 콘텐트는 온전하여서, 마스터 사용자가 라이브 브로드캐스트 룸에서 퇴장하는 경우에 다른 사용자가 영향을 받지 않는다.
단계 S46 및 단계 S47 사이에, 프록시 서버는 라이브 브로드캐스트 룸 내의 클라이언트(예를 들어, 클라이언트 C2)에 발신된 제1 라이브 미디어 스트림을 제2 라이브 미디어 스트림으로 전환한다. 미디어 서버는 프록시 서버를 통해서 클라이언트 C2에 제2 라이브 미디어 스트림을 계속해서 발신한다. 전환 후에, 프록시 서버는 계속해서 수신된 제2 라이브 미디어 스트림을 라이브 브로드캐스트 룸 내의 클라이언트에 전달한다. 세부사항에 대해, 차후의 단계를 참조하시오.
S55: 미디어 서버는 클라이언트 C2에 제2 라이브 미디어 스트림을 발신한다.
S56: 프록시 서버는 GOP 단위로 제2 라이브 미디어 스트림을 캐싱한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제2 라이브 미디어 스트림의 타임스탬프를 조절한다.
S57: 프록시 서버는 "라이브 브로드캐스트 룸 사용자 관계 테이블"에 기반하여 제2 라이브 미디어 스트림을 복제하는데, 사본의 수효는 라이브 브로드캐스트 룸 내에서 역할이 퇴장 사용자가 아닌 모든 클라이언트의 수효이다.
S58: 프록시 서버는 클라이언트 C2에 제2 라이브 미디어 스트림을 발신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제2 라이브 미디어 스트림의 타임스탬프를 조절한다.
S59: 프록시 서버는 클라이언트 C3에 제2 라이브 미디어 스트림을 발신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 제2 라이브 미디어 스트림의 타임스탬프를 조절한다.
구체적으로, 타임스탬프 조절 프로세스에 대해, 전술한 실시예에서의 설명을 참조하시오. 세부사항은 이 실시예에서 기술되지 않는다.
이 실시예에서 제공되는 방법에 따르면, 주 마스터 사용자가 역할인 클라이언트 C1이 라이브 브로드캐스트 룸에서 퇴장하기를 요청하는 경우에, 프록시 서버가 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 주 마스터 사용자로서 이바지하는 클라이언트 C1으로부터 수신한 후에, 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한, 사용자로부터의 요청 메시지를 일시적으로 전송하지 않는다. 대신에, 프록시 서버는 어떤 클라이언트를 새로운 주 마스터 사용자로서 선택하고, 라이브 미디어 스트림을 요청하는 데에 새로운 주 마스터 사용자의 역할이 사용된다. 프록시 서버는 라이브 미디어 스트림을 복제하고 다른 클라이언트에 전달하며, 미디어 스트림의 전달 동안에 정렬을 행한다. 이는 미디어 스트림을 관람하고 있는 다른 클라이언트가, 관람되는 미디어 스트림에 대응하는 마스터 사용자가 퇴장하는 경우에, 영향을 받지 않음을 보장한다.
선택적으로, 이 실시예에서 제공된 방법은 부 마스터 사용자가 역할인 클라이언트 C2가 또한 라이브 브로드캐스트 룸에서 퇴장하기를 요청하는 프로세스를 더 포함한다. 이 프로세스는 클라이언트 C1이 라이브 브로드캐스트 룸에서 퇴장하는 전술한 프로세스와 유사하다.
구체적으로, 도 8a 및 도 8b에 도시된 바와 같이, 단계 S52 및 단계 S53 사이에, 다음의 단계가 더 포함된다: 클라이언트 C2는 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 프록시 서버에 발신하는데, 요청 메시지는 클라이언트 C2의 관련된 정보를 포함한다. 프록시 서버가 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 클라이언트 C2로부터 수신하는 경우에, 클라이언트 C2에 발신된 라이브 미디어 스트림이 관람되고 있으므로, 클라이언트 C2의 사용자 역할은 퇴장(exiting) 사용자로 쇄신된다(refreshed). 이 경우에, 라이브 브로드캐스트 룸에서 퇴장하기 위한, 클라이언트 C2로부터의 요청 메시지는 일시적으로 전송되지 않는다.
이후에, S54 후에, 방법은 다음을 더 포함한다: 프록시 서버는 관람되고 있는 미디어 스트림에 대응하는 클라이언트 C2가 퇴장함을 판정하고, 프록시 서버는, 각각의 사용자가 관람하는 프레임의 상대적인 위치에 기반하여, 라이브 미디어 스트림을 클라이언트 C3에 발신된 미디어 스트림으로 원활하게 전환하고, 클라이언트 C3의 역할을 주 마스터 사용자로 쇄신한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 라이브 브로드캐스트 룸에서 퇴장하기 위한, 클라이언트 C2로부터의 요청 메시지를 미디어 서버에 전송하고; 라이브 브로드캐스트 룸에서 퇴장하기 위한 것이고 미디어 서버에 의해 클라이언트 C2에 발신된 응답 메시지를 수신하고; 라이브 브로드캐스트 룸에서 퇴장하기 위한 응답 메시지를 클라이언트 C2에 전송한다. 추가로, 방법은 다음을 더 포함한다: 프록시 서버는 "라이브 브로드캐스트 룸 사용자 관계 테이블"로부터 클라이언트 C2에 대응하는 엔트리를 삭제한다.
끝으로, 미디어 서버로부터 제3 라이브 미디어 스트림을 수신한 후에, 프록시 서버는 GOP 단위로 제3 라이브 미디어 스트림을 로컬로 캐싱하고, 제3 라이브 미디어 스트림을 복제하고 라이브 브로드캐스트 룸 내에서 퇴장 사용자가 아닌 모든 클라이언트에 전달한다. 이 경우에, 라이브 브로드캐스트 룸 내에 오직 클라이언트 C3가 있고, 프록시 서버는 미디어 서버에 의해 발신된 라이브 미디어 스트림을 클라이언트 C3에 발신한다. 선택적으로, 클라이언트 C3에 라이브 미디어 스트림을 발신하는 경우에, 프록시 서버는 또한, 클라이언트 C3의 사용자 경험에 영향을 미치는 것을 방지하기 위해, 사용자의 비디오 프레임의 재생 시간에 기반하여 미디어 스트림 내의 타임스탬프를 조절한다. 이 방식으로, 클라이언트 C1 및 클라이언트 C2가 라이브 브로드캐스트 룸에서 퇴장하는 경우에 미디어 스트림 비디오의 어떤 반복적으로 재생되는 부분도 없고 재생되는 비디오 콘텐트는 온전하다.
이 출원의 이 실시예에서 제공된 단측 비디오 라이브 브로드캐스트 기술에 따르면, 프록시 서버는, 사용자 역할을 식별하고 사용함으로써 미디어 서버로부터, 마스터 사용자가 역할인 클라이언트의 미디어 스트림을 요청하고 획득하며; 주 마스터 사용자에 의해 요청된 미디어 스트림을 동일한 라이브 브로드캐스트 룸 내의 다른 사용자에 전달한다. 이 방식으로, 동일한 라이브 브로드캐스트 룸 내의 사용자가 미디어 비디오를 관람하는 경우에, 미디어 서버로부터 프록시 서버에 전송된 미디어 스트림에 대해, 마스터 사용자에 의해 요청된 미디어 스트림만이 대역폭을 소비한다. 이는 이출 대역폭 비용 및 광역 네트워크 링크 로드를 효과적으로 감소시킨다. 추가로, 방법에 따르면, 미디어 서버는 클라이언트를 위해 독립적인 인증을 구성할 필요가 없는바, 이로써 운영 및 유지 비용을 감소시킨다.
다음은 이 출원의 전술한 방법 실시예에 대응하는 장치 및 하드웨어 디바이스 실시예를 기술한다.
도 9는 이 출원의 실시예에 따른 미디어 스트림 발신 장치의 개략적인 구조도이다. 장치는 전술한 실시예에서 기술된 프록시 서버일 수 있다.
또한, 장치는 수신 유닛(receiving unit)(901), 처리 유닛(processing unit)(902) 및 발신 유닛(sending unit)(903)을 포함한다. 추가로, 장치는 다른 기능적 모듈 또는 유닛, 예를 들어, 저장 유닛(storage unit)을 더 포함할 수 있다. 장치는 서버일 수 있고, 전술한 실시예에서의 미디어 스트림 발신 방법을 수행하도록 구성된다. 예를 들어, 장치는 라이브 브로드캐스트 룸에 입장하는 적어도 두 사용자를 위해 라이브 미디어 스트림을 제공한다.
구체적으로, 수신 유닛(901)은, 제1 클라이언트로부터, 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하도록 구성된다. 처리 유닛(902)은, 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 제1 클라이언트의 역할을 판정하도록 구성된다. 발신 유닛(903)은, 제1 클라이언트의 역할이 슬레이브 사용자임이 판정된 경우에, 로컬로 캐싱된 제1 라이브 미디어 스트림을 제1 클라이언트에 발신하도록 구성되되, 제1 라이브 미디어 스트림은 프록시 서버를 통해서 제2 클라이언트에 미디어 서버에 의해 전송된 미디어 스트림이고, 제2 클라이언트의 역할은 마스터 사용자이다.
선택적으로, 이 실시예의 구체적인 구현에서, 처리 유닛(902)은 구체적으로, 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는지를 판정하고, 만일 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는 경우, 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하거나, 만일 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 없는 경우, 제1 클라이언트의 역할이 마스터 사용자임을 판정하도록 구성된다.
선택적으로, 이 실시예의 다른 구체적인 구현에서, 수신 유닛(901)은 또한, 제1 라이브 미디어 스트림이 제1 클라이언트에 발신되기 전에, 제1 클라이언트로부터 제1 미디어 요청 메시지를 수신하고, 미디어 서버에 제1 미디어 요청 메시지를 전송하는 것을 생략하도록 구성되고, 발신 유닛(903)은 또한, 제1 클라이언트에 제1 미디어 응답 메시지를 발신하도록 구성되되, 제1 미디어 응답 메시지는 제1 클라이언트가 미디어 스트림을 획득하도록 허용됨을 제1 클라이언트에 통지하는 데에 사용된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 제1 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함한다. 수신 유닛(901)은 또한, 제1 라이브 미디어 스트림이 제1 클라이언트에 발신된 후에, 제2 클라이언트로부터, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하도록 구성된다. 처리 유닛(902)은 또한, 제1 클라이언트를 새로운 마스터 사용자로서 판정하는 경우에, 제1 클라이언트의 역할을 슬레이브 사용자로부터 마스터 사용자로 변경하도록 구성된다. 발신 유닛(903)은 또한, 미디어 서버에 제2 미디어 요청 메시지를 발신하도록 구성되되, 제2 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함한다. 수신 유닛(901)은 또한, 제2 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제2 라이브 미디어 스트림을 수신하도록 구성된다. 처리 유닛(902)은 또한, 제2 라이브 미디어 스트림으로, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 전환하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 처리 유닛(902)은 구체적으로, 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는지를 판정하고(사전설정된 상한은 1보다 큼), 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는 경우, 제1 클라이언트의 역할이 슬레이브 사용자임을 판정하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 처리 유닛(902)은 또한, 만일 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 0이 아니나 사전설정된 상한에 도달하지 않는 경우, 제1 클라이언트의 역할이 부 마스터 사용자임을 판정하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 제1 클라이언트가 슬레이브 사용자인 경우에, 수신 유닛(901)은 또한, 제2 클라이언트로부터, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하도록 구성된다. 처리 유닛(902)은 또한, 제1 클라이언트를 새로운 부 마스터 사용자로서 판정하는 경우에, 제1 클라이언트의 역할을 슬레이브 사용자로부터 부 마스터 사용자로 변경하도록 구성된다. 발신 유닛(903)은 또한, 미디어 서버에 제3 미디어 요청 메시지를 발신하도록 구성되되, 제3 미디어 요청 메시지는 제1 클라이언트의 식별자를 포함한다. 수신 유닛(901)은 또한, 제3 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제3 라이브 미디어 스트림을 수신하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 제2 클라이언트가 주 마스터 사용자이고, 제1 클라이언트가 부 마스터 사용자인 경우에, 발신 유닛(903)은 또한, 제1 클라이언트에 제1 라이브 미디어 스트림을 발신하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 제1 클라이언트가 부 마스터 사용자인 경우에, 수신 유닛(901)은 또한, 제1 클라이언트로부터 제4 미디어 요청 메시지를 수신하도록 구성된다. 발신 유닛(903)은 또한, 미디어 서버에 제4 미디어 요청 메시지를 발신하도록 구성된다. 수신 유닛(901)은 또한, 제4 미디어 요청 메시지에 기반하여 미디어 서버에 의해 발신된 제4 라이브 미디어 스트림을 수신하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 제1 클라이언트가 부 마스터 사용자인 경우에, 수신 유닛(901)은 또한, 제2 클라이언트로부터, 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하도록 구성된다. 처리 유닛(902)은 또한, 제1 클라이언트를 새로운 주 마스터 사용자로서 판정하는 경우에, 제1 클라이언트의 역할을 부 마스터 사용자로부터 주 마스터 사용자로 변경하도록 구성된다. 발신 유닛(903)은 또한, 제4 라이브 미디어 스트림으로, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 전환하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 처리 유닛(902)은 또한, 제4 라이브 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시키도록, 조절하도록 구성된다.
제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다.
처리 유닛(902)은 또한, 제4 라이브 미디어 스트림으로, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 전환하기 전에, 캐싱된 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하고(제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임임), 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제4 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제4 라이브 미디어 스트림의 제1 프레임으로서 사용하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 장치는 또한, 픽처 그룹(GOP) 단위로 제1 라이브 미디어 스트림을 캐싱하도록 구성된 저장 유닛을 더 포함한다. 추가로, 저장 유닛은 또한, GOP 단위로 제2 라이브 미디어 스트림 및 제3 라이브 미디어 스트림을 로컬로 저장한다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 처리 유닛(902)은 또한, 제2 라이브 미디어 스트림으로, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 전환하기 전에, 제2 라이브 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 제1 클라이언트에 발신된 제2 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시키도록, 조절하도록 구성된다. "연속적"은 클라이언트에 의해 수신된 제2 라이브 미디어 스트림의 인접한 비디오 프레임의 시간 길이가 동일하다는 것으로서 이해될 수 있고, 시간 길이는 프레임 레이트 파라미터 f의 역수이다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제2 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이다.
처리 유닛(902)은 또한, 제2 라이브 미디어 스트림으로, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림을 전환하기 전에, 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 기반하여, 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하고(제1 I 프레임 및 제2 I 프레임은 동일한 비디오 프레임임), 제1 I 프레임 및 제2 I 프레임에 기반하여, 서로 인접하고 각각 제1 라이브 미디어 스트림 및 제2 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 제1 전환 프레임 및 제2 전환 프레임을 각각 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 마지막 프레임 및 제1 클라이언트에 발신된 제2 라이브 미디어 스트림의 제1 프레임으로서 사용하도록 구성된다.
발신 유닛(903)은 또한, 제1 전환 프레임 및 제2 전환 프레임이 판정된 후에, 미디어 서버에, 라이브 브로드캐스트 룸에서 퇴장하기 위한, 제2 클라이언트로부터의 요청 메시지를 전송하도록 구성된다.
선택적으로, 이 실시예의 또 다른 구체적인 구현에서, 처리 유닛(902)은 또한, 제1 라이브 미디어 스트림이 제1 클라이언트에 발신되기 전에, 제1 라이브 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 제1 프레임의 타임스탬프가 0이고, 제1 클라이언트에 발신된 제1 라이브 미디어 스트림의 인접한 프레임의 타임스탬프가 연속적임을 만족시키도록, 조절하도록 구성된다.
구체적인 하드웨어 구현에서, 도 10에 도시된 바와 같이, 이 출원은 네트워크 디바이스를 또한 제공한다. 네트워크 디바이스(200)는 전술한 방법 실시예에서의 프록시 서버일 수 있다.
구체적으로, 네트워크 디바이스(200)는 송수신기(201), 프로세서(202) 및 메모리(203)를 포함한다. 네트워크 디바이스는 또한 더 많거나 더 적은 컴포넌트를 포함하거나, 몇몇 컴포넌트를 조합하거나, 상이한 컴포넌트 배열을 가질 수 있다. 이것은 이 출원에서 한정되지 않는다.
송수신기(201)는 라이브 미디어 스트림을 수신하고 발신하며, 네트워크 내의 다른 디바이스(예를 들면 클라이언트 또는 RDC)와의 데이터 송신을 수행하도록, 예를 들어, 요청 메시지 및 응답 메시지를 발신하고 수신하도록 구성된다. 또한, 송수신기(201)는 수신기(2011), 송신기(2012) 및 안테나(2013)와 같은 컴포넌트를 포함할 수 있거나, 송수신기 모듈을 포함할 수 있다. 또한, 송수신기 모듈은 무선 로컬 영역 네트워크(wireless local area network, WLAN) 모듈, 블루투스(Bluetooth) 모듈, 또는 기저대역(base band) 모듈과 같은 통신 모듈을 포함할 수 있고, 통신 모듈에 대응하는 무선 주파수(radio frequency, RF) 회로를 포함할 수 있는데, 무선 주파수 회로는 무선 로컬 영역 네트워크 통신, 블루투스 통신, 적외선 통신 및/또는 셀룰러 통신 시스템 통신, 예를 들어, 광대역 코드 분할 다중 액세스(wideband code division multiple access, WCDMA) 및/또는 고속 다운링크 패킷 액세스(high speed downlink packet access, HSPDA)를 수행하도록 구성된다. 송수신기 모듈은 네트워크 디바이스 내의 컴포넌트 간의 통신을 제어하도록 구성되며, 직접 메모리 액세스(direct memory access)를 지원할 수 있다.
프로세서(202)는 네트워크 디바이스의 제어 센터(control center)이고, 다양한 인터페이스와 라인을 통해서 전체 네트워크 디바이스의 다양한 부분에 연결된다. 프로세서(202)는 메모리(203) 내에 저장된 소프트웨어 프로그램 및/또는 유닛을 가동 또는 실행하고, 메모리(203) 내에 저장된 데이터를 호출하여, 네트워크 디바이스의 다양한 기능을 수행하고/거나 데이터를 처리한다.
또한, 프로세서(202)는 집적 회로(integrated circuit, IC)를 포함할 수 있는데, 예를 들어, 단일의 패키징된(packaged) IC를 포함할 수 있거나, 동일한 기능 또는 상이한 기능을 갖는 복수의 연결된 패키징된 IC를 포함할 수 있다. 예를 들어, 프로세서는 단지 중앙 처리 유닛(Central Processing Unit, CPU)을 포함할 수 있거나, GPU, 디지털 신호 프로세서(Digital Signal Processor, DSP) 및 송수신기 내의 제어 칩(예를 들면 기저대역 칩)의 조합일 수 있다.
메모리(203)는 휘발성 메모리(volatile memory), 예를 들어, 랜덤 액세스 메모리(Random Access Memory, RAM)를 포함할 수 있거나; 비휘발성 메모리(nonvolatile memory), 예를 들어, 플래쉬 메모리(flash memory), 하드 디스크 드라이브(Hard Disk Drive, HDD), 또는 솔리드 스테이트 드라이브(Solid-State Drive, SSD)를 포함할 수 있다. 메모리는 또한 전술한 타입의 메모리의 조합을 포함할 수 있다. 메모리는 프로그램 또는 코드를 저장할 수 있다. 프로세서(202)는 통신 디바이스의 기능을 구현하기 위해 프로그램 또는 코드를 실행한다.
이 실시예에서, 네트워크 디바이스가 프록시 서버로서 사용되는 경우에, 도 9에 도시된 장치 실시예에서의 수신 유닛(901) 및 발신 유닛(903)의 기능은 송수신기(201)에 의해 구현되거나, 프로세서(202)에 의해 제어되는 송수신기(201)에 의해 구현될 수 있고; 처리 유닛(902)에 의해 구현될 기능은 프로세서(202)에 의해 구현될 수 있고; 저장 유닛의 기능은 메모리(203)에 의해 구현될 수 있다.
추가로, 이 출원의 실시예는 미디어 스트림 발신 시스템을 또한 제공한다. 시스템은 도 9에 도시된 미디어 스트림 발신 장치 또는 도 10에 도시된 네트워크 디바이스를 포함하고, 복수의 클라이언트, RDC, EDC 및 콘텐트 소스와 같은 디바이스를 더 포함하여, 전술한 방법 실시예에서의 미디어 스트림 발신 방법을 구현한다.
선택적으로, 미디어 스트림 발신 시스템은 비디오 라이브 브로드캐스트 시스템, 예를 들어, CDN 시스템이다.
추가로, 이 출원은 컴퓨터 저장 매체를 또한 제공한다. 컴퓨터 저장 매체는 프로그램을 저장할 수 있고, 프로그램이 실행되는 경우에, 이 출원에서 제공되는 미디어 스트림 발신 방법의 실시예의 단계 중 일부 또는 전부가 수행될 수 있다. 저장 매체는 자기 디스크(magnetic disk), 광학 디스크(optical disc), 판독 전용 메모리(read-only memory)(ROM), 랜덤 액세스 메모리(random access memory)(RAM), 또는 유사한 것일 수 있다.
전술한 실시예 중 전부 또는 일부는 소프트웨어, 하드웨어, 펌웨어, 또는 이의 임의의 조합을 사용함으로써 구현될 수 있다. 실시예를 구현하는 데에 소프트웨어가 사용되는 경우에, 실시예 중 전부 또는 일부는 컴퓨터 프로그램 제품의 형태로 구현될 수 있다.
컴퓨터 프로그램 제품은 하나 이상의 컴퓨터 명령어를 포함한다. 컴퓨터 프로그램이 컴퓨터 상에 로딩되고 실행되는 경우에, 이 출원의 전술한 실시예에 따른 절차 또는 기능 중 전부 또는 일부가 생성된다. 컴퓨터는 일반 목적 컴퓨터, 전용 컴퓨터, 컴퓨터 네트워크, 또는 다른 프로그램가능 장치일 수 있다.
컴퓨터 명령어는 컴퓨터 판독가능 저장 매체 내에 저장될 수 있거나, 컴퓨터 판독가능 저장 매체로부터 다른 컴퓨터 판독가능 저장 매체로 송신될 수 있다. 예를 들어, 컴퓨터 명령어는 웹사이트, 컴퓨터, 서버, 또는 데이터 센터로부터 다른 웹사이트, 컴퓨터, 서버, 또는 데이터 센터로 유선 또는 무선 방식으로 송신될 수 있다.
이 명세서에서의 실시예에서의 동일한 또는 유사한 부분에 대해, 서로 참조하시오. 특별히, 미디어 스트림 발신 장치의 실시예는 기본적으로 방법 실시예와 유사하고, 따라서 간략하게 기술된다. 관련된 부분에 대해, 방법 실시예에서의 서술을 참조하시오.
당업자는, 본 발명의 실시예에서의 기술이, 필요한 일반 하드웨어 플랫폼에 더하여 소프트웨어에 의해 구현될 수 있음을 명확히 이해할 수 있다. 그러한 이해에 기반하여, 본 발명의 실시예에서의 기술적 해결안은 본질적으로 또는 종래 기술에 기여하는 부분은 소프트웨어 제품의 형태로 구현될 수 있다. 컴퓨터 소프트웨어 제품은 저장 매체, 예를 들면 ROM/RAM, 자기 디스크, 또는 광학 디스크 내에 저장될 수 있고, 본 발명의 실시예 또는 실시예의 몇몇 부분에서 기술된 방법을 수행할 것을 컴퓨터 디바이스(이는 개인용 컴퓨터, 서버, 네트워크 디바이스, 또는 유사한 것일 수 있음)에 지시하기 위한 몇 개의 명령어를 포함한다.
이 명세서에서의 실시예에서의 동일한 또는 유사한 부분에 대해, 서로 참조하시오. 특히, 미디어 스트림 발신 장치의 실시예는 기본적으로 방법 실시예와 유사하고, 따라서 간략하게 기술된다. 관련된 부분에 대해, 방법 실시예에서의 서술을 참조하시오.
추가로, 이 출원의 설명에서, 달리 명시되지 않는 한, "복수의"는 둘 또는 둘보다 많음을 의미한다. 추가로, 이 출원의 실시예에서의 기술적 해결안의 명확한 설명의 편의를 위해, "제1", "제2" 및 유사한 것과 같은 용어는 동일한 객체 또는 유사한 객체(이의 기능 및 목적은 기본적으로 동일함) 간을 구별하는 데에 사용된다. "제1" 및 "제2"와 같은 용어가 수효 또는 실행 순차를 한정하지 않으며, "제1" 및 "제2"와 같은 용어가 분명한 차이를 지시하지 않음을 당업자는 이해할 수 있다.
이 출원의 전술한 구현은 이 출원의 보호 범위를 한정하도록 의도되지 않는다.

Claims (34)

  1. 미디어 스트림(media stream) 발신 방법으로서, 상기 방법은 라이브 브로드캐스트 룸(live broadcast room)에 입장하는 클라이언트를 위해 라이브 미디어 스트림을 제공하고, 상기 방법은,
    프록시 서버에 의해 제1 클라이언트로부터, 상기 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하는 단계와,
    상기 프록시 서버에 의해, 상기 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 상기 제1 클라이언트의 역할을 판정하는 단계와,
    상기 제1 클라이언트의 역할이 슬레이브(slave) 사용자인 경우, 상기 프록시 서버 내에 캐싱된(cached) 제1 라이브 미디어 스트림을 상기 제1 클라이언트에 발신하는 단계 - 상기 제1 라이브 미디어 스트림은 상기 프록시 서버를 통해서 제2 클라이언트에 미디어 서버에 의해 발신된 미디어 스트림이고, 상기 제2 클라이언트의 역할은 마스터(master) 사용자임 - 와,
    상기 프록시 서버에 의해 상기 제2 클라이언트로부터, 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하는 단계 - 상기 프록시 서버는 일시적으로 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 상기 미디어 서버에 전송하지 않음 -와,
    상기 제1 클라이언트를 새로운 마스터 사용자로서 판정하는 경우에, 상기 프록시 서버에 의해, 상기 제1 클라이언트의 역할을 상기 슬레이브 사용자로부터 상기 마스터 사용자로 변경하는 단계와,
    상기 프록시 서버에 의해, 상기 미디어 서버에 제2 미디어 요청 메시지를 발신하는 단계 - 상기 제2 미디어 요청 메시지는 상기 제1 클라이언트의 식별자를 포함함 - 와,
    상기 프록시 서버에 의해, 상기 제2 미디어 요청 메시지에 기반하여 상기 미디어 서버에 의해 발신된 제2 라이브 미디어 스트림을 수신하는 단계와,
    상기 프록시 서버에 의해 상기 제2 라이브 미디어 스트림으로, 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림을 전환하는 단계와,
    상기 프록시 서버에 의해 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 상기 미디어 서버에 전송하는 단계를 포함하는,
    방법.
  2. 제1항에 있어서,
    상기 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 상기 제1 클라이언트의 역할을 판정하는 단계는,
    상기 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 상기 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는지를 판정하는 단계와,
    상기 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는 경우, 상기 제1 클라이언트의 역할이 상기 슬레이브 사용자임을 판정하는 단계를 포함하는,
    방법.
  3. 제2항에 있어서,
    상기 프록시 서버 내에 캐싱된 제1 라이브 미디어 스트림을 상기 제1 클라이언트에 발신하는 단계 전에, 상기 방법은,
    상기 프록시 서버에 의해, 상기 제1 클라이언트로부터 제1 미디어 요청 메시지를 수신하고, 상기 미디어 서버에 상기 제1 미디어 요청 메시지를 전송하는 것을 생략하는 단계와,
    상기 프록시 서버에 의해, 상기 제1 클라이언트에 제1 미디어 응답 메시지를 발신하는 단계를 더 포함하되,
    상기 제1 미디어 응답 메시지는 상기 제1 클라이언트가 미디어 스트림을 획득하도록 허용됨을 상기 제1 클라이언트에 통지하는 데에 사용되는,
    방법.
  4. 제3항에 있어서,
    상기 제1 미디어 요청 메시지는 상기 제1 클라이언트의 상기 식별자를 포함하는,
    방법.
  5. 제1항에 있어서,
    상기 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 상기 제1 클라이언트의 역할을 판정하는 단계는,
    상기 프록시 서버에 의해, 상기 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하는 경우에 상기 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는지를 판정하는 단계 - 상기 사전설정된 상한은 1보다 큼 - 와,
    상기 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 상기 수효가 상기 사전설정된 상한에 도달하는 경우, 상기 제1 클라이언트의 역할이 상기 슬레이브 사용자임을 판정하는 단계를 포함하는,
    방법.
  6. 제5항에 있어서,
    상기 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 상기 수효가 0이 아니지만 상기 사전설정된 상한에 도달하지 않는 경우, 상기 제1 클라이언트의 역할이 부 마스터(secondary-master) 사용자임을 판정하는 단계를 더 포함하는,
    방법.
  7. 제5항에 있어서,
    상기 제1 클라이언트가 상기 슬레이브 사용자인 경우에, 상기 방법은,
    상기 프록시 서버에 의해 상기 제2 클라이언트로부터, 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하는 단계와,
    상기 제1 클라이언트를 새로운 부 마스터 사용자로서 판정하는 경우에, 상기 프록시 서버에 의해, 상기 제1 클라이언트의 역할을 상기 슬레이브 사용자로부터 상기 부 마스터 사용자로 변경하는 단계와,
    상기 프록시 서버에 의해, 상기 미디어 서버에 제3 미디어 요청 메시지를 발신하는 단계 - 상기 제3 미디어 요청 메시지는 상기 제1 클라이언트의 식별자를 포함함 - 와,
    상기 프록시 서버에 의해, 상기 제3 미디어 요청 메시지에 기반하여 상기 미디어 서버에 의해 발신된 제3 라이브 미디어 스트림을 수신하는 단계를 더 포함하는,
    방법.
  8. 제1항 내지 제7항 중 어느 한 항에 있어서,
    상기 프록시 서버에 의해, 픽처 그룹(group of pictures, GOP) 단위로 상기 제1 라이브 미디어 스트림을 캐싱하는 단계를 더 포함하는,
    방법.
  9. 제4항에 있어서,
    상기 프록시 서버에 의해, 상기 제2 라이브 미디어 스트림으로, 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림을 전환하는 단계 전에, 상기 방법은,
    상기 프록시 서버에 의해, 상기 제2 라이브 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 상기 제1 클라이언트에 상기 프록시 서버에 의해 발신된 상기 제2 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 상기 제1 클라이언트에 상기 프록시 서버에 의해 발신된 상기 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시키도록, 조절하는 단계를 더 포함하는,
    방법.
  10. 제4항 또는 제9항에 있어서,
    상기 제1 클라이언트에 상기 프록시 서버에 의해 발신된 상기 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제1 클라이언트에 상기 프록시 서버에 의해 발신된 상기 제2 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이고,
    상기 프록시 서버에 의해, 상기 제2 라이브 미디어 스트림으로, 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림을 전환하는 단계 전에, 상기 방법은,
    상기 프록시 서버에 의해 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 기반하여, 각각 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별하는 단계 - 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임임 - 와,
    상기 프록시 서버에 의해 상기 제1 I 프레임 및 상기 제2 I 프레임에 기반하여, 서로 인접하고 각각 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 상기 제1 전환 프레임 및 상기 제2 전환 프레임을 각각 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제1 클라이언트에 발신된 상기 제2 라이브 미디어 스트림의 제1 프레임으로서 사용하는 단계와,
    상기 프록시 서버가 상기 제1 전환 프레임 및 상기 제2 전환 프레임을 판정한 후에, 상기 방법은, 상기 프록시 서버에 의해 상기 미디어 서버에, 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한, 상기 제2 클라이언트로부터의 상기 요청 메시지를 전송하는 단계를 더 포함하는,
    방법.
  11. 미디어 스트림 발신 장치로서, 상기 장치는 라이브 브로드캐스트 룸에 입장하는 클라이언트를 위해 라이브 미디어 스트림을 제공하고, 상기 장치는,
    제1 클라이언트로부터, 상기 라이브 브로드캐스트 룸에 입장하기를 요청하기 위한 제1 라이브 브로드캐스트 룸 요청 메시지를 수신하도록 구성된 수신 유닛과,
    상기 제1 라이브 브로드캐스트 룸 요청 메시지에 기반하여 상기 제1 클라이언트의 역할을 판정하도록 구성된 처리 유닛과,
    상기 제1 클라이언트의 역할이 슬레이브 사용자임이 판정된 경우에, 상기 장치 내에 캐싱된 제1 라이브 미디어 스트림을 상기 제1 클라이언트에 발신하도록 구성된 발신 유닛을 포함하되,
    상기 제1 라이브 미디어 스트림은 상기 장치를 통해서 제2 클라이언트에 미디어 서버에 의해 발신된 미디어 스트림이고, 상기 제2 클라이언트의 역할은 마스터 사용자이고,
    상기 수신 유닛은 또한, 상기 제1 라이브 미디어 스트림이 상기 제1 클라이언트에 발신된 후에, 상기 제2 클라이언트로부터, 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하도록 구성되고 - 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지는 일시적으로 상기 미디어 서버에 전송되지 않음 -,
    상기 처리 유닛은 또한, 상기 제1 클라이언트를 새로운 마스터 사용자로서 판정하는 경우에, 상기 제1 클라이언트의 역할을 상기 슬레이브 사용자로부터 상기 마스터 사용자로 변경하도록 구성되고,
    상기 발신 유닛은 또한, 상기 미디어 서버에 제2 미디어 요청 메시지를 발신하도록 구성되되, 상기 제2 미디어 요청 메시지는 상기 제1 클라이언트의 식별자를 포함하고,
    상기 수신 유닛은 또한, 상기 제2 미디어 요청 메시지에 기반하여 상기 미디어 서버에 의해 발신된 제2 라이브 미디어 스트림을 수신하도록 구성되고,
    상기 처리 유닛은 또한, 상기 제2 라이브 미디어 스트림으로, 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림을 전환하도록 구성되고
    상기 발신 유닛은 또한, 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 상기 미디어 서버에 전송하도록 구성되는,
    장치.
  12. 제11항에 있어서,
    상기 처리 유닛은 구체적으로, 상기 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 상기 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는지를 판정하고, 상기 라이브 브로드캐스트 룸 내에 마스터 사용자가 역할인 클라이언트가 있는 경우, 상기 제1 클라이언트의 역할이 상기 슬레이브 사용자임을 판정하도록 구성된,
    장치.
  13. 제12항에 있어서,
    상기 수신 유닛은 또한, 상기 캐싱된 제1 라이브 미디어 스트림이 상기 제1 클라이언트에 발신되기 전에, 상기 제1 클라이언트로부터 제1 미디어 요청 메시지를 수신하고, 상기 미디어 서버에 상기 제1 미디어 요청 메시지를 전송하는 것을 생략하도록 구성되고,
    상기 발신 유닛은 또한, 상기 제1 클라이언트에 제1 미디어 응답 메시지를 발신하도록 구성되되, 상기 상기 제1 미디어 응답 메시지는 상기 제1 클라이언트가 미디어 스트림을 획득하도록 허용됨을 상기 제1 클라이언트에 통지하는 데에 사용되는,
    장치.
  14. 제13항에 있어서,
    상기 제1 미디어 요청 메시지는 상기 제1 클라이언트의 상기 식별자를 포함하는,
    장치.
  15. 제11항에 있어서,
    상기 처리 유닛은 구체적으로, 상기 제1 라이브 브로드캐스트 룸 요청 메시지가 수신된 경우에 상기 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 수효가 사전설정된 상한에 도달하는지를 판정 - 상기 사전설정된 상한은 1보다 큼 - 하고, 상기 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 상기 수효가 상기 사전설정된 상한에 도달하는 경우, 상기 제1 클라이언트의 상기 역할이 상기 슬레이브 사용자임을 판정하도록 구성된,
    장치.
  16. 제15항에 있어서,
    상기 처리 유닛은 또한, 상기 라이브 브로드캐스트 룸 내에서 마스터 사용자가 역할인 클라이언트의 상기 수효가 0이 아니나 상기 사전설정된 상한에 도달하지 않는 경우, 상기 제1 클라이언트의 역할이 부 마스터 사용자임을 판정하도록 구성된,
    장치.
  17. 제15항에 있어서,
    상기 제1 클라이언트가 상기 슬레이브 사용자인 경우에,
    상기 수신 유닛은 또한, 상기 제2 클라이언트로부터, 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한 요청 메시지를 수신하도록 구성되고,
    상기 처리 유닛은 또한, 상기 제1 클라이언트를 새로운 부 마스터 사용자로서 판정하는 경우에, 상기 제1 클라이언트의 역할을 상기 슬레이브 사용자로부터 상기 부 마스터 사용자로 변경하도록 구성되고,
    상기 발신 유닛은 또한, 상기 미디어 서버에 제3 미디어 요청 메시지를 발신하도록 구성되되, 상기 제3 미디어 요청 메시지는 상기 제1 클라이언트의 식별자를 포함하고,
    상기 수신 유닛은 또한, 상기 제3 미디어 요청 메시지에 기반하여 상기 미디어 서버에 의해 발신된 제3 라이브 미디어 스트림을 수신하도록 구성된,
    장치.
  18. 제14항에 있어서,
    상기 처리 유닛은 또한, 상기 제2 라이브 미디어 스트림으로, 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림을 전환하기 전에, 상기 제2 라이브 미디어 스트림의 타임스탬프를, 조절된 타임스탬프가 상기 제1 클라이언트에 발신된 상기 제2 라이브 미디어 스트림의 제1 프레임의 타임스탬프 및 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림의 마지막 프레임의 타임스탬프가 연속적임을 만족시키도록, 조절하도록 구성된,
    장치.
  19. 제14항 또는 제18항에 있어서,
    상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제1 클라이언트에 발신된 상기 제2 라이브 미디어 스트림의 제1 프레임은 인접한 프레임이고,
    상기 처리 유닛은 또한, 상기 제2 라이브 미디어 스트림으로, 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림을 전환하기 전에, 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 기반하여, 각각 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 속한 제1 I 프레임 및 제2 I 프레임을 식별 - 상기 제1 I 프레임 및 상기 제2 I 프레임은 동일한 비디오 프레임임 - 하고, 상기 제1 I 프레임 및 상기 제2 I 프레임에 기반하여, 서로 인접하고 각각 상기 제1 라이브 미디어 스트림 및 상기 제2 라이브 미디어 스트림에 속한 제1 전환 프레임 및 제2 전환 프레임을 판정하고, 상기 제1 전환 프레임 및 상기 제2 전환 프레임을 각각 상기 제1 클라이언트에 발신된 상기 제1 라이브 미디어 스트림의 마지막 프레임 및 상기 제1 클라이언트에 발신된 상기 제2 라이브 미디어 스트림의 제1 프레임으로서 사용하도록 구성되고,
    상기 발신 유닛은 또한, 상기 제1 전환 프레임 및 상기 제2 전환 프레임이 판정된 후에, 상기 미디어 서버에, 상기 라이브 브로드캐스트 룸에서 퇴장하기 위한, 상기 제2 클라이언트로부터의 상기 요청 메시지를 전송하도록 구성된,
    장치.
  20. 네트워크 디바이스로서, 프로세서를 포함하되, 상기 프로세서는 메모리에 커플링되고,
    상기 메모리는 명령어를 저장하도록 구성되고,
    상기 프로세서는, 상기 네트워크 디바이스가 제1항 내지 제7항 및 제9항 중 어느 한 항에 따른 방법을 수행하도록, 상기 메모리 내의 상기 명령어를 실행하도록 구성된,
    네트워크 디바이스.
  21. 컴퓨터 판독가능 저장 매체로서, 상기 저장 매체는 명령어를 저장하고,
    상기 명령어가 가동되는 경우에, 제1항 내지 제7항 및 제9항 중 어느 한 항에 따른 방법이 구현되는,
    컴퓨터 판독가능 저장 매체.
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 삭제
  34. 삭제
KR1020217020731A 2019-04-23 2020-04-23 미디어 스트림 발신 방법과 장치 및 디바이스 KR102525289B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201910330894.3A CN111836059B (zh) 2019-04-23 2019-04-23 一种媒体流发送方法、装置和设备
CN201910330894.3 2019-04-23
PCT/CN2020/086349 WO2020216279A1 (zh) 2019-04-23 2020-04-23 一种媒体流发送方法、装置和设备

Publications (2)

Publication Number Publication Date
KR20210094081A KR20210094081A (ko) 2021-07-28
KR102525289B1 true KR102525289B1 (ko) 2023-04-24

Family

ID=72911675

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020217020731A KR102525289B1 (ko) 2019-04-23 2020-04-23 미디어 스트림 발신 방법과 장치 및 디바이스

Country Status (6)

Country Link
US (1) US20210352336A1 (ko)
EP (1) EP3883249B1 (ko)
JP (1) JP7256881B2 (ko)
KR (1) KR102525289B1 (ko)
CN (2) CN111836059B (ko)
WO (1) WO2020216279A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113301377B (zh) * 2021-05-24 2023-04-07 广州市百果园信息技术有限公司 直播管理系统、方法、设备及存储介质
US11924479B2 (en) * 2021-07-07 2024-03-05 Rovi Guides, Inc. Systems and methods for generating metadata for a live media stream
CN113824987B (zh) * 2021-09-30 2024-04-30 杭州网易云音乐科技有限公司 直播间首帧耗时的确定方法、介质、装置和计算设备
CN113949892B (zh) * 2021-10-14 2024-03-29 广州方硅信息技术有限公司 基于虚拟资源消耗的直播互动方法、系统、设备及介质
CN114363665B (zh) * 2021-12-16 2023-11-07 深圳市捷视飞通科技股份有限公司 多业务码流推送方法、系统、计算机设备和存储介质
CN114501052B (zh) * 2022-01-26 2022-10-25 腾讯科技（深圳）有限公司 直播数据处理方法、云平台、计算机设备和存储介质
CN116132751A (zh) * 2022-12-30 2023-05-16 郑州小鸟信息科技有限公司 一种基于web窗口场景同步回放的方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100851634B1 (ko) 2008-02-05 2008-08-13 주식회사 셀런 라이브 멀티미디어 스트림을 풀방식으로 스트리밍하는 방법및 시스템
CN103475900A (zh) 2012-06-06 2013-12-25 中国移动通信集团公司 手机电视业务视频帧的封装方法、装置及前端系统
KR101533368B1 (ko) * 2014-04-18 2015-07-02 숭실대학교산학협력단 마스터 이동 단말 및 슬레이브 이동 단말의 제어 방법, 이를 수행하기 위한 기록매체
KR101727310B1 (ko) * 2016-12-09 2017-04-14 주식회사 대경바스컴 다방향성 크로스캐스팅 방송 시스템 및 방법
CN109104614A (zh) * 2018-07-02 2018-12-28 北京东方网信科技股份有限公司 一种直播缓存系统及方法

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3875504B2 (ja) 2001-03-23 2007-01-31 日本電信電話株式会社 共通情報キャッシング中継方法及び中継装置
US8621083B2 (en) * 2003-05-15 2013-12-31 Hewlett-Packard Development Company, L.P. System and method for multicasting through a localized computer network
US9038116B1 (en) * 2009-12-28 2015-05-19 Akamai Technologies, Inc. Method and system for recording streams
CN101778104A (zh) * 2009-12-29 2010-07-14 常州中流电子科技有限公司 一种实现自适应带宽播放流媒体的系统及其方法
CN102075562B (zh) * 2010-12-03 2014-08-20 华为技术有限公司 协作缓存的方法和装置
CN102075728B (zh) * 2011-01-18 2015-08-12 中兴通讯股份有限公司 一种共享音频和/或视频的方法及系统
CN103841468B (zh) * 2014-02-27 2018-04-20 北京六间房科技有限公司 实时流媒体数据传输方法
JP2015165349A (ja) 2014-02-28 2015-09-17 株式会社東芝 一次応答装置、制御方法及びコンピュータプログラム
US9445048B1 (en) * 2014-07-29 2016-09-13 Google Inc. Gesture-initiated actions in videoconferences
US9402054B2 (en) * 2014-12-08 2016-07-26 Blue Jeans Network Provision of video conference services
CN106302566B (zh) * 2015-05-12 2019-07-23 华为技术有限公司 直播媒体数据的方法、设备和系统
JP6220917B2 (ja) 2016-04-19 2017-10-25 株式会社 ディー・エヌ・エー リアルタイムの動画を配信するシステム、方法、及びプログラム
WO2018027237A1 (en) * 2016-08-05 2018-02-08 Sportscastr.Live Llc Systems, apparatus, and methods for scalable low-latency viewing of broadcast digital content streams of live events
CN106162235B (zh) * 2016-08-17 2018-06-01 北京百度网讯科技有限公司 用于切换视频流的方法和装置
CN106534877B (zh) * 2016-10-24 2019-06-25 广州酷狗计算机科技有限公司 一种发送媒体流的方法及装置
CN108235042B (zh) * 2016-12-14 2019-12-17 腾讯科技（深圳）有限公司 一种多人网络直播方法、装置、加入装置、系统、服务器和计算机可读存储介质
CN106604064A (zh) * 2016-12-30 2017-04-26 北京奇艺世纪科技有限公司 一种快速开播方法及装置
CN107332894B (zh) * 2017-06-23 2020-08-11 广州市百果园信息技术有限公司 直播方法、装置及系统、服务器、存储介质
CN108322787A (zh) * 2018-02-08 2018-07-24 北京潘达互娱科技有限公司 视频流分发方法、装置及电子设备
CN109618178A (zh) * 2019-01-21 2019-04-12 北京奇艺世纪科技有限公司 一种直播方法、装置及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100851634B1 (ko) 2008-02-05 2008-08-13 주식회사 셀런 라이브 멀티미디어 스트림을 풀방식으로 스트리밍하는 방법및 시스템
CN103475900A (zh) 2012-06-06 2013-12-25 中国移动通信集团公司 手机电视业务视频帧的封装方法、装置及前端系统
KR101533368B1 (ko) * 2014-04-18 2015-07-02 숭실대학교산학협력단 마스터 이동 단말 및 슬레이브 이동 단말의 제어 방법, 이를 수행하기 위한 기록매체
KR101727310B1 (ko) * 2016-12-09 2017-04-14 주식회사 대경바스컴 다방향성 크로스캐스팅 방송 시스템 및 방법
CN109104614A (zh) * 2018-07-02 2018-12-28 北京东方网信科技股份有限公司 一种直播缓存系统及方法

Also Published As

Publication number Publication date
CN111836059A (zh) 2020-10-27
JP2022518216A (ja) 2022-03-14
WO2020216279A1 (zh) 2020-10-29
JP7256881B2 (ja) 2023-04-12
US20210352336A1 (en) 2021-11-11
KR20210094081A (ko) 2021-07-28
CN111836059B (zh) 2022-03-29
CN114666614A (zh) 2022-06-24
EP3883249A1 (en) 2021-09-22
EP3883249B1 (en) 2024-03-27
EP3883249A4 (en) 2022-05-11

Similar Documents

Publication Publication Date Title
KR102525289B1 (ko) 미디어 스트림 발신 방법과 장치 및 디바이스
US10547659B2 (en) Signaling and processing content with variable bitrates for adaptive streaming
US9769236B2 (en) Combined broadcast and unicast delivery
CN112369038B (zh) 用于在实时上行链路流式传输服务中分发媒体的方法
US8751679B2 (en) HTTP adaptive streaming server with automatic rate shaping
US11095701B2 (en) Method and apparatus for providing adaptive streaming service
US10547883B2 (en) Data flow control method and system
EP2946542B1 (en) Supporting transport diversity and time-shifted buffers for media streaming over a network
US9118738B2 (en) Systems and methods for controlling access to a media stream
CN102598628A (zh) 用于多媒体传送的自适应分块和内容感知同步设备及方法
Ma et al. HTTP live streaming bandwidth management using intelligent segment selection
US11848973B2 (en) Media stream sending method, apparatus, system and device
CN108476333A (zh) 媒体流的邻接流送
US20210392384A1 (en) Distribution system, information processing server, and distribution method

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant