KR102110627B1 - 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들 - Google Patents

적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들 Download PDF

Info

Publication number
KR102110627B1
KR102110627B1 KR1020157002890A KR20157002890A KR102110627B1 KR 102110627 B1 KR102110627 B1 KR 102110627B1 KR 1020157002890 A KR1020157002890 A KR 1020157002890A KR 20157002890 A KR20157002890 A KR 20157002890A KR 102110627 B1 KR102110627 B1 KR 102110627B1
Authority
KR
South Korea
Prior art keywords
media
server
client
media devices
video
Prior art date
Application number
KR1020157002890A
Other languages
English (en)
Other versions
KR20150042191A (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 KR20150042191A publication Critical patent/KR20150042191A/ko
Application granted granted Critical
Publication of KR102110627B1 publication Critical patent/KR102110627B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365Multiplexing of several video streams
    • H04N21/23655Statistical multiplexing, e.g. by controlling the encoder to alter its bitrate to optimize the bandwidth utilization
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234345Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401Monitoring of the client buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/65Transmission of management data between client and server
    • H04N21/654Transmission by server directed to the client
    • H04N21/6547Transmission by server directed to the client comprising parameters, e.g. for client setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

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

Abstract

서버(305)로부터의 비디오 콘텐트를 복수의 미디어 디바이스들(320)에 제공하기 위한 방법이 개시되며, 상기 방법은: 서버(305)에 의해, 하이퍼텍스트 전송 프로토콜-기반 라이브 스트리밍 클라이언트 모델 또는 요구 파라미터 벡터를 사용하여 복수의 미디어 디바이스들(320)의 각각에 할당할 대역폭을 결정하는 단계 및 할당된 대역폭을 복수의 미디어 디바이스들(320)의 각각에 제공하는 단계를 포함하며, 상기 비디오 콘텐트는 서버(305)로부터 복수의 세그먼트들로 송신되며, 각각의 세그먼트는 세그먼트에서 세그먼트로 변할 수 있는 비트레이트로 송신된다.

Description

적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들{METHODS AND DEVICES FOR BANDWIDTH ALLOCATION IN ADAPTIVE BITRATE STREAMING}
콘텐트 서버(content server)로부터 미디어 디바이스(media device)로의 네트워크(network)를 통한 미디어의 스트리밍(streaming)은 미디어 이용을 위해 광범위하게 채택되어 왔다. 미디어 스트리밍을 위해 사용되는 두 개의 네트워크 프로토콜들(network protocols)은 사용자 데이터그램 프로토콜 인터넷 프로토콜(“UDP IP”; user datagram protocol Internet protocol) 및 전송 제어 프로토콜(“TCP”; transfer control protocol) IP를 포함한다. UDP IP는 종종 유선 연결들을 통해 가정 내 스트리밍과 같은, 비교적 신뢰성 있는 네트워크들에 대한 미디어 스트리밍을 위해 사용된다. TCP IP는 종종 덜 신뢰성 있는 네트워크들을 통한 스트리밍을 위해 사용된다.
TCP IP와 함께 사용되는, 하이퍼텍스트 전송 프로토콜(“HTTP”; HyperText Transfer Protocol) 기반 라이브 스트리밍(live streaming)(“HLS”) 프로토콜은 콘텐트 서버가 미디어 디바이스들로 변형 재생리스트 파일들을 공개하도록 허용한다. 변형 재생리스트 파일은 영화, 텔레비전 프로그램 등과 같은, 미디어 프로그램을 위한 많은 세트들의 비디오 스트림들을 식별하며, 여기서 비디오 스트림들의 각각의 세트는 미디어 프로그램에 대한 고유 인코딩 파라미터들(예컨대, 비트 레이트들, 해상도 등)을 가진다. 미디어 디바이스들은 비디오 스트림들의 세트들이 콘텐트 서버로부터 미디어 디바이스들로 송신됨에 따라 변형 재생리스트 파일에서 식별된 비디오 스트림들의 세트들 사이를 동적으로 스위칭할 수 있다. 미디어 디바이스들은 초기 네트워크 상태들, 초기 버퍼 상태들 등에 기초하여 변형 재생리스트 파일에서 식별된 비디오 스트림들의 초기 세트를 수신하도록 선택할 수 있다. 예를 들면, 미디어 디바이스들은 초기 네트워크 상태들, 초기 버퍼 상태들 등이 비디오 스트림들의 HD 세트의 스트리밍을 지원한다면 변형 재생리스트 파일에서 식별된 고 화질(“HD”; high definition) 비디오 스트림들의 세트를 수신하도록 선택할 수 있다. 초기 네트워크 상태들이 저하된다면, 또는 초기 버퍼 상태들이 저하된다면, 미디어 디바이스들은 변형 재생리스트 파일에서 식별된 저 화질 비디오 스트림들의 세트를 수신하도록 선택할 수 있다. 즉, 미디어 디바이스는 비디오 스트림들의 상이한 세트들이 상이한 인코딩 파라미터들을 갖는 콘텐트 서버로부터 수신하도록 비디오 스트림들의 상이한 세트들을 동적으로 선택할 수 있다.
비디오 스트림들의 세트들의 선택 및 송신은 미디어 디바이스들에 의해 동작된다. 변형 재생리스트 파일에서 식별된 비디오 스트림들의 세트의 선택에 응답하여, 콘텐트 서버는 비디오 스트림들의 세트를 미디어 디바이스로 수동적으로 송신한다. 미디어 디바이스는 네트워크 상태들에 대한 제한된 정보를 가질 수 있으며 현재 네트워크 상태들에 적합한 비디오 스트림들의 세트를 선택하지 않을 수 있다. 뿐만 아니라, 몇몇 유형들의 미디어 디바이스들은 수신할 최고 해상도 및 최고 비트 레이트 세트들의 비디오 스트림들을 선택한다. 통상적으로 콘텐트 서버는 비디오 스트림들의 다수의 세트들을 미디어 디바이스들로 송신하면서, 많은 미디어 디바이스들을 서비스한다. 미디어 디바이스가 높은 해상도 및 높은 비트 레이트를 가진 비디오 스트림들의 세트를 요청한다면, 콘텐트 서버 리소스들 또는 네트워크 대역폭의 많은 부분이 상기 미디어 디바이스를 서비스하기 위해 할당되어야 할 수 있다. 결과적으로, 콘텐트 서버에 의해 서비스된 다른 미디어 디바이스들은 비디오 스트림들의 송신에서 간헐적인 중단들과 같은 저하된 성능을 경험할 수 있다.
첨부된 청구항들은 구체적으로 본 기술들의 특징들을 제시하지만, 이들 목적들 및 이점들과 더불어, 이들 기술들은 첨부한 도면들과 함께 취해진 다음의 상세한 설명으로부터 가장 잘 이해될 수 있다.
도 1a는 본 발명의 실시예들이 사용될 수 있는 예시적인 시스템 구현을 예시한다.
도 1b는 본 발명의 실시예들이 사용될 수 있는 예시적인 미디어-스트리밍 시스템 구현을 예시한다.
도 2는 본 발명의 실시예들에 따른 서로 통신하는 클라이언트 구성요소들 및 서버 구성요소들 및 통상적인 적응적 스트리밍을 위한 메시지 흐름들을 포함하는 시스템을 예시한다.
도 3a는 본 발명의 실시예들에 따른 비디오 스트리밍 시스템을 예시한다.
도 3b는 본 발명의 실시예들에 따른 스케줄 모듈(schedule module)에 의해 제공된 예시적인 스케줄 윈도우를 예시한다.
도 4는 본 발명의 실시예들에 따른 미디어-디바이스 버퍼(buffer)를 위한 버퍼링 단계 및 재생 단계를 도시한 예시적인 그래프를 예시한다.
도 5는 본 발명의 실시예들에 따른 예시적인 HLS 클라이언트 모델(“HCM”; HLS Client Model) 블록도를 예시한다.
도 6은 본 발명의 실시예들에 따른 비트 레이트(bit rate) 대 요구 파라미터 벡터(“NPV”; Need Parameter Vector)의 곡선들의 예시적인 그래프를 예시한다.
도 7은 본 발명의 실시예들에 따른 HCM 및 스케줄 큐(schedule queue)를 구현하는 시스템의 예시적인 블록도를 예시한다.
도면들에 따라, 유사한 참조 번호들은 유사한 요소들을 나타내며, 본 발명의 기술들은 적절한 환경에서 구현되는 것으로 예시된다. 다음의 설명은 청구항들의 실시예들에 기초하며 본 명세서에 명시적으로 설명되지 않은 대안적인 실시예들에 관하여 청구항들을 제한하는 것으로서 취해져서는 안 된다.
도 1a를 참조하면, 예시적인 미디어 디바이스(100)는 프로세싱 유닛(processing unit)(120) 및 판독-전용 메모리(“ROM”; read-only memory)(140) 및 랜덤-액세스 메모리(“RAM”; random access memory)(150)와 같은 시스템 메모리(system memory)(130)를 포함하는 다양한 시스템 구성요소들을 프로세서(120)에 결합하는 시스템 버스(110)를 포함한다. 미디어 디바이스(100)는 프로세서(120)와 직접, 프로세서(120)에 근접하여 연결되거나, 또는 프로세서(120)의 일부로서 통합되는 고속 메모리의 캐시(cache)(122)를 포함할 수 있다. 미디어 디바이스(100)는 프로세서(120)에 의한 빠른 액세스를 위해 메모리(130) 또는 저장 디바이스(160)로부터 캐시(122)로 데이터를 복사하도록 구성될 수 있다. 이러한 방식으로, 캐시(122)는 데이터를 기다리면서 프로세서 지연들을 회피하는 성능 증가를 제공한다. 이들 및 다른 모듈들은 다양한 동작들을 수행하도록 프로세서(120)를 제어하거나 또는 제어하도록 구성될 수 있다. 또한 다른 시스템 메모리(130)가 사용을 위해 이용 가능할 수 있다. 메모리(130)는 상이한 성능 특성들을 가진 많은 상이한 유형들의 메모리를 포함할 수 있다. 본 발명은 하나보다 많은 프로세서(120)를 가진 미디어 디바이스(100) 상에서 또는 보다 나은 프로세싱 성능을 제공하기 위해 함께 네트워킹된 컴퓨팅 디바이스들의 그룹 또는 클러스터(cluster) 상에서 동작할 수 있다는 것이 이해될 수 있다. 프로세서(120)는 소프트웨어 지시들이 실제 프로세서 설계로 통합되는 특수-목적 프로세서뿐만 아니라 저장 디바이스(160)에 저장되며 프로세서(120)를 제어하도록 구성된, 모듈 1(162), 모듈 2(164), 및 모듈 3(166)과 같은, 임의의 범용 프로세서 및 하드웨어 모듈 또는 소프트웨어 모듈을 포함할 수 있다. 프로세서(120)는 근본적으로, 다수의 코어들(cores) 또는 프로세서들, 버스(bus), 메모리 제어기, 캐시 등을 포함하는, 완전한 독립형 컴퓨팅 시스템일 수 있다. 다중-코어 프로세서는 대칭 또는 비대칭일 수 있다.
시스템 버스(110)는 다양한 버스 아키텍처들 중 임의의 것을 사용하는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 로컬 버스를 포함하는 여러 유형들의 버스 구조들 중 임의의 유형일 수 있다. ROM(140) 등에 저장된 기본 입력/출력 시스템은 시작 동안과 같이, 미디어 디바이스(100) 내 요소들 사이에서 정보를 전달하도록 돕는 기본 루틴을 제공할 수 있다. 미디어 디바이스(100)는 하드 디스크 드라이브(hard disk drive), 자기 디스크 드라이브, 광 디스크 드라이브, 테이프 드라이브(tape drive) 등과 같은, 저장 디바이스들(160)을 더 포함한다. 저장 디바이스(160)는 드라이브 인터페이스에 의해 시스템 버스(110)에 연결된다. 드라이브들 및 연관된 컴퓨터-판독 가능한 저장 미디어는 미디어 디바이스(100)를 위한 컴퓨터-판독 가능한 지시들, 데이터 구조들, 프로그램 모듈들, 및 다른 데이터의 비휘발성 저장을 제공한다. 몇몇 실시예들에서, 특정한 기능을 수행하는 하드웨어 모듈은 기능을 실행하기 위해, 프로세서(120), 버스(110), 디스플레이(170) 등과 같은, 필요한 하드웨어 구성요소들과 관련하여 비-일시적 컴퓨터-판독 가능한 매체에 저장된 소프트웨어 구성요소를 포함한다. 기본 구성요소들은 이 기술분야의 숙련자들에게 알려져 있으며 적절한 변형들이 디바이스(100)가 작은, 핸드헬드(handheld) 컴퓨팅 디바이스, 데스크탑 컴퓨터, 컴퓨터 서버 등인지와 같이, 디바이스의 유형에 따라 고려된다.
몇몇 구현예들이 하드 디스크(160)를 이용하지만, 자기 카세트들(magnetic cassettes), 플래시 메모리 카드들(flash memory cards), 디지털 다목적 디스크들, 카트리지들(cartridges), RAM(150), ROM(140), 비트스트림을 포함하는 케이블(cable) 또는 무선 신호 등과 같은, 컴퓨터에 의해 액세스 가능한 데이터를 저장할 수 있는 다른 유형들의 컴퓨터-판독 가능한 미디어도 대표적인 동작 환경에서 사용될 수 있다는 것이 이 기술분야의 숙련자들에 의해 이해되어야 한다. 비-일시적 컴퓨터-판독 가능한 저장 미디어는 에너지, 캐리어 신호들(carrier signals), 전자기 파들, 및 신호들 자체로와 같은 미디어를 명확하게 제외한다.
또한 미디어 디바이스(100)는 3개의 버퍼 섹션들(buffer sections)(105a, 105b, 및 105c)을 포함하는 수신 버퍼(105)를 포함한다. 제 1 버퍼 섹션(105a)은 미디어 디바이스(100)가 콘텐트 서버로부터 수신되지만 미디어 플레이를 위해 이용되지 않는 비디오 패킷들(video packets)을 위한 것일 수 있다. 미디어 디바이스(100)는 확인 응답을 통해 콘텐트 서버로 제 1 버퍼 섹션(105a) 내 비디오 패킷들의 수신을 확인 응답할 수 있다. 버퍼 관리 모듈(도시되지 않음)은 제 1 버퍼 섹션(105a) 내 비디오 패킷들이 미디어 디바이스(100)에 의한 이용을 위해 검색되는 레이트(rate)를 모니터링할 수 있다.
제 2 버퍼 섹션(105b)은 미디어 디바이스(100)가 콘텐트 서버로부터 수신되었지만 미디어 플레이를 위해 이용되지 않는 비디오 패킷들을 위한 것일 수 있다. 미디어 디바이스(100)는 제 2 버퍼 섹션(105b)에서 비디오 패킷들을 위한 확인 응답들을 콘텐트 서버에 전송하지 않을 수 있다. 제 2 버퍼 섹션(105b)의 부분들은 제 2 버퍼 섹션(105b) 내 비디오 패킷들을 위한 확인 응답들이 미디어 디바이스(100)로부터 콘텐트 서버에 송신됨에 따라 제 1 버퍼 섹션(105a)의 일 부분으로 분류될 수 있다. 버퍼 관리 모듈(도시되지 않음)은 미디어 디바이스(100)가 제 2 버퍼 섹션(105b) 내 비디오 패킷들의 수신을 확인 응답하기 위한 확인 응답을 콘텐트 서버에 전송할 때 제 1 비디오 버퍼(105a)의 일 부분으로 분류되는 제 2 버퍼 섹션(105b)의 부분들을 추적할 수 있다.
제 3 버퍼 섹션(105c)은 비디오 패킷들의 수신을 위해 이용 가능할 수 있다. 버퍼 관리 모듈(도시되지 않음)은 제 3 버퍼 섹션(105c)이 비디오 패킷들을 수신하고 제 2 버퍼 섹션(105b)의 일 부분으로 분류될 때를 결정하기 위해 제 3 버퍼 섹션(105c)을 모니터링할 수 있다. 제 1 버퍼 섹션(105a)의 부분들은 제 1 버퍼 섹션(105a)으로부터의 비디오 패킷들이 이용됨에 따라 제 3 버퍼 섹션(105c)의 일 부분으로서 분류될 수 있다. 즉, 비디오 패킷들이 이용되는 제 1 버퍼 섹션(105a)의 상기 부분은 콘텐트 서버로부터 새로운 비디오 패킷들을 수신할 수 있다.
제 1, 제 2, 및 제 3 버퍼 섹션들(105a 내지 105c)의 크기들은 몇몇 실시예들에 따라 비디오-패킷 버퍼링을 위한 최대 버퍼 크기를 함께 정의한다. 최대 버퍼 크기는 콘텐트 서버와의 초기 연결을 개방할 때 미디어 디바이스(100)에 의해 할당될 수 있다. 최대 버퍼 크기는 통상적으로 할당 후에 변경되지 않은 채로 있다.
미디어 디바이스(100)와의 사용자 상호작용을 가능하게 하기 위해, 입력 디바이스(190)는 대화를 위한 마이크로폰(microphone), 제스처 또는 그래픽 입력을 위한 터치-민감 스크린, 키보드, 마우스, 모션 입력, 대화 등과 같은, 많은 입력 메커니즘들을 나타낸다. 또한 출력 디바이스(170)는 이 기술분야의 숙련자들에게 알려진 다수의 출력 메커니즘들 중 하나 이상일 수 있다. 몇몇 경우들에서, 다중모드 시스템들은 사용자가 미디어 디바이스(100)와 통신하기 위해 다수의 유형들의 입력을 제공할 수 있게 한다. 통신 인터페이스(180)는 일반적으로 사용자 입력 및 시스템 출력을 통제 및 관리한다. 임의의 특정한 하드웨어 배열상에서 동작할 때 제한은 없으며, 그에 따라 본 명세서에서의 기본 특징들은 하드웨어 또는 펌웨어 배열들이 개발됨에 따라 개선된 하드웨어 또는 펌웨어 배열들로 쉽게 대체될 수 있다.
명료한 설명을 위해, 예시적인 시스템 실시예는 “프로세서” 또는 프로세서(120)로 라벨링된 기능 블록들을 포함하여, 개개의 기능 블록들을 포함하는 것으로 제시된다. 이들 블록들이 나타내는 기능들은 이에 제한되지 않지만, 범용 프로세서상에서 실행하는 소프트웨어와 같은 것으로 동작하도록 특별히-만들어진, 프로세서(120)와 같은, 소프트웨어 및 하드웨어를 실행할 수 있는 하드웨어를 포함하는, 공유 또는 전용 하드웨어의 사용을 통해 제공될 수 있다. 예를 들면, 도 1a에 제시된 하나 이상의 프로세서들의 기능들은 단일 공유 프로세서 또는 다중 프로세서들에 의해 제공될 수 있다. 예시적인 실시예들은 마이크로프로세서 또는 디지털 신호 프로세서(“DSP”; digital signal processor) 하드웨어, 이하에서 논의되는 동작들을 수행하는 소프트웨어를 저장하기 위한 ROM(140), 및 결과들을 저장하기 위한 RAM(150)을 포함할 수 있다. 범용 DSP 회로와 조합하여, 맞춤 VLSI 회로뿐만 아니라, 초 대규모 집적(“VLSI”; Very large scale integration) 하드웨어 실시예들이 제공될 수 있다.
다양한 실시예들의 논리적 동작들은 (1) 범용 컴퓨터 내의 프로그램 가능한 회로 상에서 기능하는 컴퓨터-구현 단계들, 동작들, 또는 절차들의 시퀀스(일반적으로, “지시들”), (2) 특수 프로그램 가능한 회로 상에서 기능하는 컴퓨터-구현 단계들, 동작들, 또는 절차들의 시퀀스, 또는 (3) 프로그램 가능한 회로들 내의 상호 연결된 기계 모듈들 또는 프로그램 엔진들로 구현될 수 있다. 도 1a에 도시된 미디어 디바이스(100)는 개시된 방법들의 전부 또는 일부를 실시할 수 있거나, 또는 개시된 시스템들의 일부일 수 있거나, 또는 개시된 컴퓨터-판독 가능한 저장 미디어 내 지시들에 따라 동작할 수 있다. 이러한 논리적 동작들은 모듈의 프로그래밍에 따라 특정한 기능들을 수행하도록 프로세서(120)를 제어하기 위해 구성된 모듈들로 구현될 수 있다. 예를 들면, 도 1a는 프로세서(120)를 제어하도록 구성된 모듈들인 3개의 모듈들 Mod1(162), Mod2(164), 및 Mod3(166)을 예시한다. 이들 모듈들은 저장 디바이스(160) 상에 저장되며 런타임(runtime) 시 RAM(150) 또는 메모리(130)로 로딩될 수 있거나 또는 이 기술분야에 알려질 바와 같이 다른 컴퓨터-판독 가능한 메모리 위치들에 저장될 수 있다.
콘텐트 전달은 방송 또는 인터넷과 같은 전달 매체를 통해 오디오 또는 비디오 또는 컴퓨터 소프트웨어 및 게임들과 같은 미디어 “콘텐트”의 전달을 설명한다. 콘텐트 전달은 일반적으로 두 개의 부분들, 즉 콘텐트의 첨부 메타데이터(metadata)를 가진, 디지털 분배를 위한 완성된 콘텐트의 전달; 및 최종-사용자로의 최종 생성물의 전달을 가진다.
본 명세서에 사용된 바와 같이, “스트리밍 미디어”는 적응적 비트 레이트(“ABR”; Adaptive Bit Rate) 스트리밍 방법들을 사용하여 스트리밍 제공자에 의해 전달되면서 최종-사용자에 의해 수신되며 최종-사용자에게 제공되는 미디어이다. 이름은 매체 자체보다는 매체의 전달 방법을 나타낸다. 구별은 보통, 대부분의 다른 전달 시스템들이 본질적으로 스트리밍(예컨대, 라디오, 텔레비전) 또는 본질적으로 비-스트리밍(예컨대, 책들, 비디오 카세트들, 오디오 CD들)이므로, 전기통신 네트워크들을 통해, 예컨대, “온-라인으로” 분배되는 미디어에 적용된다. 이후, ABR 방법들을 사용하는 온-라인 미디어 및 온-라인 스트리밍이 “미디어” 및 “스트리밍”으로 나타내어진다.
ABR 스트리밍은 전체 미디어 스트림 또는 미디어 파일을 작은 HTTP-기반 파일 다운로드들의 시퀀스로 분해함으로써 작동하는 기술이며, 각각의 다운로드는 전체 잠재적으로 무한한 수송 스트림 또는 미디어 기본 스트림들의 하나의 짧은 세그먼트를 로딩한다. 스트림이 플레이됨에 따라, 클라이언트(client)(예컨대, 미디어 플레이어)는 다양한 데이터 레이트들로 인코딩된 동일한 재료를 포함하는 다수의 상이한 교번 스트림들로부터 선택할 수 있어서, 스트리밍 세션(streaming session)이 이용 가능한 데이터 레이트에 적응하도록 허용한다. 스트리밍 세션의 처음에, 플레이어는 이용 가능한 다양한 서브-스트림들을 위한 메타데이터를 포함하는 매니페스트(manifest)를 다운로드한다. 그것의 요청들은 단지 표준 HTTP 트랜잭션들(transactions)만을 사용하기 때문에, ABR 스트리밍은 실시간 전송 프로토콜과 같은 UDP-기반 프로토콜들과 달리, 표준 HTTP 트래픽을 통과시키는 방화벽 또는 프록시 서버(proxy server)를 트래버스(traverse)할 수 있다. 또한 이것은 콘텐트 전달 네트워크가 임의의 주어진 스트림에 대해 쉽게 구현되도록 허용한다. ABR-스트리밍 방법들은 애플사에 의한 HTTP 라이브 스트리밍(Live Streaming), 및 마이크로소프트사에 의한 HTTP 스무스 스트리밍(Smooth Streaming)을 포함하는 독점 포맷들로 구현되어 왔다. ABR 스트리밍은 ISO/IEC 23009-1, 인포메이션 테크놀로지(Information Technology)―HTTP: 파트 1: 미디어 프리젠테이션 디스크립션 및 세그먼트 포맷들(Media presentation description and segment formats)을 통한 동적 적응적 스트리밍(Dynamic adaptive streaming)으로 표준화되어 왔다.
애플 아이패드(iPad)와 같은, 증가하는 수의 비디오 재생 디바이스들은 비디오 콘텐트가 계속해서 스트리밍되기보다는 ABR 스트리밍을 통해 전달되는 것을 선호한다. 애플의 HTTP 라이브 스트리밍 포맷을 사용하는, 아이패드는 비디오 콘텐트의 세그먼트들 또는 “청크들”의 각각에 대한 링크들, 미디어 고유 리소스 식별자들(URI들; uniform resource identifiers)을 포함하는 m3u8 파일로서 매니페스트를 수신하며, 각각의 미디어 세그먼트를 차례로 검색 및 재생하기 위해 매니페스트 파일을 프로세싱한다. 본 발명에서, “HLS”는 재생을 관리하기 위해 재생리스트를 이용하며 미디어 콘텐트를 분할하는 프로토콜들의 범위를 나타낸다.
컴퓨팅 시스템의 몇몇 구성요소들을 개시하면, 본 발명은 이제 예시적인 미디어-스트리밍 시스템 실시예(1000)를 예시하는, 도 1b에 따른다. 도 1b에 도시된 개체들 사이의 통신들은 하나 이상의 유선 또는 무선 네트워크들을 통해 이루어질 수 있다. 뿐만 아니라, 디바이스들은 직접, 월드 와이드 웹(World Wide Web)을 통해, 또는 애플리케이션-프로그래밍 인터페이스를 통해 통신할 수 있다. 태블릿 디바이스(tablet device), 스마트폰(smartphone), 데스크탑(desktop) 또는 휴대용 컴퓨터, 셋-탑 박스(set-top box), 인터넷-가능 텔레비전, 미디어 센터 PC, 또는 임의의 다른 적절한 디바이스와 같은, 재생 디바이스(1002)는 먼저 미디어 콘텐트의 재생을 위해 미디어 서버(1004)에 요청을 한다. 통상적으로, 미디어 서버(1004)는 인터넷 또는 제 3 콘텐트-분배 네트워크와 같은, 네트워크 내에 존재한다.
HLS에서, 미디어 서버(1004)는 요청을 수신하며 상기 요청에 응답하여 미디어 디바이스(1002)에 전송하기 위한 매니페이스 파일(1006)을 생성 또는 인출한다. 매니페스트 파일(1006)에 대한 예시적인 포맷들은 m3u 및 m3u8 포맷들을 포함한다. m3u8 파일은 UTF-8 유니코드(Unicode) 문자들을 사용하여 인코딩된 m3u의 특정 변형이다. m3u 파일 포맷은 처음에는 오디오-전용 파일들을 위한 WINAMP 미디어 플레이어에서 사용되었지만, 음악 및 다른 미디어 유형들을 포함하여, 로컬 또는 스트리밍 미디어를 위한 많은 미디어 디바이스들 상에서 사실상의 재생리스트 표준이 되어 왔다. 많은 미디어 디바이스들은 m3u 파일 포맷의 변형들을 이용하며, 그 중 임의의 변형이 본 발명에 따라 사용될 수 있다. 매니페스트 파일은 URI 경로와 같은, 네트워크 어드레스 또는 로컬 파일 시스템상의 위치로의 상대적 또는 절대적 경로들로서 미디어 파일들에 대한 링크들을 포함할 수 있다. m3u8 포맷은 본 명세서에서 비-표준 변형들을 포함하는 매니페스트 파일들의 원리들을 예시하기 위한 비-제한적인 예로서 사용된다.
매니페스트 파일(1006)은 요청된 분할된 미디어 콘텐트의 상이한 표현들에 대한 고유 리소스 로케이터들(“URL들”; Uniform Resource Locators)의 리스트를 포함한다. 요청 전 또는 요청 시, 미디어 서버(1004)는 스트리밍 미디어 콘텐트(1010)로서 요청된 미디어 콘텐트의 미디어 세그먼트들을 생성 또는 식별한다. 스트리밍 미디어 콘텐트(1010)의 미디어 세그먼트들이, 미디어 서버(1004)에 의해, 콘텐트 생성기에 의해, 또는 몇몇 다른 개체에 의해, 최초 미디어 콘텐트(1008)를 분할, 트랜스코드, 또는 트랜스레이트(transrate)함으로써 생성된다. 매니페스트 파일(1006)을 수신할 때, 미디어 디바이스(1002)는 스트리밍 미디어 콘텐트(1010)로부터 재생을 위한 제 1 미디어 세그먼트를 인출할 수 있으며, 그 후, 상기 미디어 세그먼트의 재생 동안, 제 1 미디어 세그먼트 후, 및 미디어 콘텐트의 끝까지, 재생을 위한 다음의 미디어 세그먼트를 인출할 수 있다.
도 2를 참조하면, 서로 통신하는 클라이언트 구성요소들(210) 및 서버 구성요소들(250) 및 통상적인 적응적 스트리밍을 위한 메시지 흐름들을 포함하는 시스템(200)이 제시된다. 클라이언트 구성요소들(210) 및 서버 구성요소들(250) 사이의 보안과 관련된 흐름들은 명료함을 위해 생략되었다.
클라이언트 구성요소들(210)은 애플리케이션 그래픽 사용자 인터페이스(“App GUI”)(220) 및 ABR 플레이어(230)를 포함할 수 있다. 서버 구성요소들(250)은, 다중-비트레이트 미디어 스트림들 및 매니페스트 파일들을 저장 또는 생성하도록 구성될 수 있는, 콘텐트 서버(260)를 포함할 수 있다.
제 1 단계(205)에서, 사용자는 영화 목록을 통해 내비게이션하며 시청을 위한 시청각 미디어 자산을 선택한다. 몇몇 실시예들에서, 시청각 미디어 자산은 고-레벨 재생리스트를 나타내는 URL에 연계된다.
다음 단계(215)에서, ABR 플레이어(230)는 ABR 프로파일들(profiles)에 대한 정보 및 각각의 미디어 대역폭에 대응하는 매니페스트들에 대한 링크들을 포함하는 시청각 미디어 자산을 위한 고-레벨 매니페스트 파일을 요청한다.
다음 단계(225)에서, ABR 플레이어(230)는 고-레벨 매니페스트 또는 마스터 재생리스트를 검토하고 제 1 매니페스트 파일, 최저 대역폭 매니페스트 파일을 요청함으로써 시작하거나, 또는 선택적으로 몇몇 대역폭 이용 가능성 추정을 하며 대응하는 대역폭 매니페스트 파일을 선택할 수 있다.
다음 단계(235)에서, ABR 플레이어(230)는 대응하는 대역폭을 위한 제 2 레벨 매니페스트를 요청한다. 다음 단계(245)에서, ABR 플레이어(230)는 제 2 레벨 매니페스트에서 미디어 세그먼트 파일을 결정한다.
다음 단계(255)에서, ABR 플레이어(230)는 연속하여 미디어 세그먼트 파일들을 요청한다. 다음 단계(265)에서, ABR 플레이어(230)는 보다 낮은 또는 보다 높은 대역폭 미디어-세그먼트 표현들을 요청할 필요가 있는지를 결정하기 위해 미디어 버퍼 충만도(buffer fullness)를 계속해서 모니터링한다. 예를 들면, 대역폭 상태들이 변한다면, 플레이어는 대응하는 대역폭 매니페스트 파일을 선택하며 연속하여 미디어 세그먼트들을 선택한다.
다음 단계(275)에서, 매니페스트의 끝이 도달될 때, ABR 플레이어(230)는 시청각 미디어 자산의 재생이 완료됨을 App GUI(220)에 시그널링(signaling)한다. 스트림 재생이 완료되었다는 시그널링은 단계(285)로 제시된다.
상기 설명된 바와 같이, 콘텐트 서버(260)는 많은 미디어 디바이스들 또는 ABR 프레이어들(230)을 서비스하여, 비디오 스트림들의 다수의 세트들을 미디어 디바이스들에 송신한다. 미디어 디바이스가 높은 해상도 및 높은 비트 레이트를 가진 비디오 스트림들의 세트를 요청한다면, 콘텐트-서버 리소스들 또는 네트워크 대역폭의 많은 부분이 상기 미디어 디바이스를 서비스하기 위해 할당되어야 할 수 있다. 결과적으로, 콘텐트 서버에 의해 서비스되는 다른 미디어 디바이스들은 비디오 스트림들의 송신에서 간헐적인 중단들과 같은 저하된 성능을 경험할 수 있다.
결과적으로, 다수의 클라이언트들을 위한 ABR 스트리밍으로 다중화 기술들을 효율적으로 이용할 수 있는 서버-측 접근법이 매우 바람직하다. 예를 들면, 각각의 클라이언트에 대한 성능을 최대화하면서, 예컨대, 클라이언트에 많은 옵션들을 제공하지 않음으로써, 각각의 클라이언트에 할당할 리소스들을 결정할 수 있는 시스템 및 방법은 현재 클라이언트-동작 모델에 대해 많은 이점들을 제공한다.
도 3a는 몇몇 실시예들에 따른 비디오 스트리밍 시스템(300)을 도시한다. 비디오 스트리밍 시스템(300)은 콘텐트 서버(305), 네트워크(315), 미디어 디바이스들의 세트(320), 및 트랜스코더 요소(322)를 포함한다. 콘텐트 서버(305)는 비디오 콘텐트 또는 비디오 스트림들의 세트들을 네트워크(315)를 통해 미디어 디바이스들(320)에 송신할 수 있다. 비디오 스트림들의 세트는 영화, 텔레비전 프로그램 등과 같은, 미디어 프로그램을 위한 것일 수 있다. 비디오 스트림들의 세트 내 각각의 비디오 스트림은 비디오의 짧은 세그먼트(예컨대, 2초, 10초 등)일 수 있다. 비디오 스트림들의 세트는 2-시간 영화와 같이, 미디어 프로그램을 위한 수천 개의 비디오 스트림들을 포함할 수 있다. 본 명세서에서 사용된 바와 같이, 비디오 수송 또는 기본 스트림과 같은 인코딩된 콘텐트는 고정-지속 기간 세그먼트들(예컨대, 청크들)로 분할될 수 있다. 세그먼트들 또는 청크들은, 그것들이 더 길거나 또는 더 짧을 수 있을지라도, 통상적으로 지속 기간이 2 및 10초 사이이다. 몇몇 실시예들에서, 보다 짧은 세그먼트들은 코딩 효율성을 감소시키는 반면 보다 큰 세그먼트들은 네트워크 스루풋(throughput)의 변화들에 적응하기 위해 속도에 영향을 미친다. 몇몇 실시예들에서, 비디오 및 오디오 수송 스트림은 HLS 청크들 또는 세그먼트들로 함께 그룹핑되는 188-바이트 수송 패킷들로 구성된다. 그러나, 마이크로소프트 HTTP 스무스 스트리밍에 대해, 비디오 및 오디오 기본 스트림들은 별개의 데이터 블록들로 그룹핑되고, 파일 조각들로 청크되며, 이들 컨테이너들에서 샘플들(코딩된 비디오 및 오디오 프레임들)을 찾는 방법을 플레이어에 암시하기 위해 MP4 또는 ISO-MBFF “박스들” 또는 “원자들”로 인덱싱된다.
비디오 스트림들의 세트들은 트랜스코더 요소(322)로부터 콘텐트 서버(305)에 제공될 수 있다. 트랜스코더 요소(322)는 각각의 트랜스코더 리소스가 고유 인코딩 파라미터들(예컨대, 비트 레이트, 해상도 등)을 가진 비디오 스트림들의 세트를 제공하는 다수의 트랜스코더 리소스들(323)을 포함한다. 네트워크(315)는 인터넷, 다양한 인트라넷들(intranets) 등을 포함할 수 있다. 네트워크(315)는 유선 링크들 및 무선 링크들을 포함할 수 있다. “미디어” 및 “비디오”에 대해 본 명세서에서 이루어진 다양한 참조들은 비디오 콘텐트 및 오디오 콘텐트 양자 모두를 포함한다는 것이 이해될 것이다.
콘텐트 서버(305)는 프로세서들의 세트(305a) 및 비-일시적 컴퓨터-판독 가능한 저장 매체(메모리)(305b)를 포함한다. 메모리(305b)는, 프로세서들의 세트(305a)가 본 명세서에 설명된 다양한 실시예들을 실행하기 위해 실행할 수 있는, 지시들을 저장할 수 있다. 콘텐트 서버(305)는 도메인을 공유하는 다수의 컴퓨터 디바이스들을 포함한다. 또한 콘텐트 서버(305)는 도 3b를 참조하여 더 상세히 설명되는, 스케줄 모듈(305c)을 포함한다.
이제 도 3b를 참조하면, 스케줄 모듈(305c)에 의해 제공되는 예시적인 스케줄 윈도우(310)가 제시된다. 이상적으로, 콘텐트 서버(305)는 네트워크 이용을 최대화하며 미디어 디바이스들(320)로 전송된 미디어 스트림들 전체에 걸쳐 비교 가능한 비디오 품질 레벨들을 유지한다. 콘텐트 서버(305)는 스케줄 모듈(305c)을 이용함으로써 이러한 목적을 부분적으로 성취할 수 있다. 스케줄 모듈(305c)은 그것이 하나 이상의 트랜스코더들, 콘텐트-관리 서비스들, 콘텐트-전달 서버들, 또는 콘텐트 서버(305)와 통신하는 미디어 디바이스들로부터 수신, 결정, 또는 가정하는 하나 이상의 인자들에 기초하여 스케줄 윈도우(310)를 구성 및 구현할 수 있다. 몇몇 실시예들에서, 스케줄 모듈(305c)은 클라이언트의 가입 파라미터들(예컨대, 운영자-관리 콘텐트-디렉토리 서비스들 또는 이행 관리기들로부터 올 수 있는, 예컨대, SD 또는 HD 서비스 또는 금/은/동 등에 대해 클라이언트가 지불했던, 스트리밍 서비스를 위한 서비스 레벨 협약), 클라이언트 미디어 디바이스로부터 직접 보고된 클라이언트 디바이스 정보(스크린 크기, A/V 디코더 성능들) 등과 같은 정보뿐만 아니라, (업스트림 트랜스코더들 또는 콘텐트 서버들로부터 올 수 있는) 트랜스코딩된 비디오에 대응하는 요구 벡터들(Need Vectors)의 형태로 메타데이터를 사용한다.
도시된 바와 같이, 스케줄 윈도우(310)는 복수의 클라이언트 또는 미디어 디바이스 개개의 스케줄들(320)을 포함한다. 예를 들면, 클라이언트 #1은 스케줄(320a)을 할당받고, 클라이언트 #2는 스케줄(320b)을 할당받으며, 클라이언트 #N는 스케줄(320n)을 할당받는다. 각각의 개개의 스케줄(320)은 클라이언트에 전달될 세그먼트들의 순서이다. 예를 들면, 클라이언트 #1은 세그먼트들(청크 S1+1, 청크 S1+2, 청크 S1+3, …, 청크 S1+K1)이 스케줄-윈도우 시간 기간(TSW)에 걸쳐 전달되는 것을 제시한다.
알려진 바와 같이, 미디어-디바이스 수신 버퍼는 네트워크 지터(jitter)를 수용하기 위해 필요한 구성요소이다. 다시 말해서, 미디어 디바이스를 위한 비디오 데이터의 도착에 대한 타이밍 제약들이 버퍼 충만도에 기초하여 완화될 수 있다. 예를 들면, 미디어 디바이스가 그것의 버퍼에 T 양의 비디오 데이터 세그먼트들을 갖는다면, 다음 비디오 세그먼트의 도착은 비디오 디바이스가 미디어 데이터를 다 쓰거나 또는 언더플로우(underflow)하기 전에 (T-Tchunk)초만큼 지연될 수 있다. 몇몇 실시예들에서, 플레이어는 그것의 버퍼에 T초의 미디어 프리젠테이션 데이터를 가진다. 그것이 다음 T초 전체에 걸쳐 임의의 새로운 데이터를 다운로드하지 않는다면, T초가 만료될 때, 플레이어의 버퍼는 언더플로우할 것이며, 그것은 오디오 및 비디오를 플레이하는 것을 정지할 것이다. 몇몇 실시예들에서, 플레이어는 지연들을 처리하기 위해 T-초 버퍼를 사용하여, 평균하여, 비디오가 디코딩되고 렌더링되는 레이트와 같아야 하는 레이트로 Tchunk 초 길이의 새로운 세그먼트들을 다운로드해야 한다.
또한 부가적으로, 미디어-디바이스 수신 버퍼는 미디어-디바이스 사용자 경험에 영향을 미치지 않고 세그먼트 또는 청크 다운로드들에 대한 타이밍 제약들을 완화시키기 위한 기회를 제공한다. 따라서, 청크들을 스케줄링하며 스케줄 윈도우(스케줄 윈도우(310)와 같은)에 의해 정의된 시간의 기간 동안 각각의 클라이언트에 대한 그것들의 비트레이트들을 결정하는 해결책이 바람직하다. 스케줄-윈도우 모델 하에서, 통계적 다중화가 다음과 같이 설명될 수 있다: 윈도우 크기(TWS)를 가진 스케줄 윈도우(Schedule Window)라 불리우는 미리 정의된 시간 기간, 및 상이한 HLS 프로그램들을 플레이하는 N개의 클라이언트들을 고려해볼 때, 각각의 클라이언트에 대한 양호한 비디오 품질을 유지하면서 네트워크 대역폭의 이용을 최대화하는 각각의 HLS 클라이언트에 대한 최적의 레이트들을 결정한다.
도 3b에 표시된 바와 같이, 미디어 디바이스들에 대한 세그먼트들의 수 및 상이한 레이트들을 선택하기 위한 문제점은 스케줄링 문제가 된다.
Figure 112015011419826-pct00001
로서 정의된 시간 기간에서,
Figure 112015011419826-pct00002
수의 청크들은 미디어 디바이스(i)에 대해 스케줄링된다.
Figure 112015011419826-pct00003
는 미디어 디바이스 상태에 및 미디어-디바이스 버퍼에서 미디어-디바이스 버퍼의 충만도를 뺀 값, 예컨대 이용 가능한 버퍼 또는 (
Figure 112015011419826-pct00004
)에 의존적이다. 스케줄링된 청크들에 대한 최적의 비트레이트들을 선택하기 위해, 콘텐트 서버(305)는 어떤 전체 품질 레벨(Q)이 네트워크 대역폭에 기초하여 지원될 것인지를 결정한다.
미디어-디바이스 상태 및 이용 가능한 버퍼는 HLS 클라이언트 모델을 사용하여 결정될 수 있다.
임의의 특정한 이론에 의해 제한되도록 원하지 않고, HLS 클라이언트 행동이 특성화될 수 있으며 따라서 예측 가능하다는 것이 발견되어 왔다. 예를 들면, 클라이언트가 저장된 HLS 프로그램을 플레이하기 시작할 때, 그것은 먼저 특정된 URI를 가진 HLS 서버로부터 매니페스트 파일(재생리스트 파일)을 판독하고, 파일의 콘텐트를 파싱하며, 가장 낮은 시퀀스 번호(도 2를 참조하여 설명된 바와 같이)의 청크로 순차적으로 시작하는 HLS 청크들을 요청하기 시작한다. HLS 프로그램의 플레이 전체에 걸쳐, 두 개의 재생 단계들이 관찰되며 버퍼링 단계 및 재생 단계로서 정의된다. 도 4는 두 개의 단계들, 즉 버퍼링 단계(410) 및 재생 단계(420)를 도시하는 예시적인 그래프(400)이다. 클라이언트가 시작할 때, 클라이언트는 비어 있는 HLS 클라이언트 버퍼를 가진 버퍼링 단계(410)에 있을 것이며, 클라이언트는 클라이언트가 이전 청크를 다운로드하는 것을 완료한 직후 세그먼트들 또는 청크들을 요청함으로써 그것의 HLS 클라이언트 버퍼(Client Buffer)를 가득 채우려고 노력한다. 클라이언트가 클라이언트의 HLS 클라이언트 버퍼를 가득 채울 때, 재생 단계(420)로 이동한다. 이 단계에서, 클라이언트는 청크 지속 기간 동안 하나의 HLS 청크를 인출할 것이다. 다시 말해서, 전체 다운로드 청크 속도는 그것의 실시간 재생 속도와 일치한다.
클라이언트 행동을 예측하며 클라이언트의 상태를 학습하기 위해, 콘텐트 서버(305)는 각각의 클라이언트 또는 미디어 디바이스에 대한 상태-기반 HCM을 형성한다. HCM은 클라이언트가 버퍼링 단계에 있는지 또는 재생 단계에 있는지에 대한 정보를 제공한다. 또한 HCM은 HLS 클라이언트 버퍼의 충만도 레벨을 추정하기 위한 수단을 제공한다. 도 5는 예시적인 HCM 블록도(500)를 예시한다.
HCM 블록도(500)는 플레이어 상태(510)를 포함한다. 플레이어 상태(510)는 HCM의 현재 상태, 예컨대 플레이, 탐색, 중지, 재개를 제공한다. 미디어 시간(520)이 플레이어 상태(510)와 함께 또한 포함된다. 미디어 시간(520)은 현재 플레잉 미디어 프레임의 미디어 시간스탬프이다.
또한 HCM 블록도(500)는 버퍼 충만도(530), 버퍼 크기(540), 및 현재 요청 청크(550)를 포함한다. 버퍼 충만도(530)는 HLS 클라이언트 버퍼로 다운로드되지만 아직 미디어 디바이스에 의해 이용되지 않은 청크들의 수이다. 버퍼 크기(540)는 HLS 클라이언트 버퍼의 총 크기이며, 현재 요청 청크(550)는 HLS 클라이언트에 의한 현재 요청 청크의 시퀀스 번호이다.
이제 도 4 및 도 5를 참조하여, HCM을 구성하기 위해 사용되는 몇 개의 변수들이 여기에 설명된다. 예를 들면, Tstart는 클라이언트가 제 1 미디어 청크를 다운로드하는 것을 완료하고 비디오를 플레이하기 시작할 때의 시스템 시간을 표시한다. Tcurrent는 클라이언트가 현재 요청 청크(550)를 요청할 때의 시스템 시간을 표시한다. Tstart_pts는 제 1 미디어 청크에서 제 1 비디오 프레임의 프리젠테이션 시간 스탬프(“PTS”; presentation time stamp)를 나타낸다. Tcurrent_pts는 현재 요청 청크(550)에서 제 1 비디오 프레임의 PTS를 나타낸다.
버퍼 충만도(530)는 버퍼의 충만도(상대적인 경과 시간)에서 버퍼의 배출(실제 경과 시간)을 뺀 것에 의해 나타내어진다. 예를 들면,
Figure 112015011419826-pct00005
가 시간에 맞춰 측정된 클라이언트 버퍼 충만도(530)를 나타내게 하자. HCM으로 스트리밍된 시간(초)에 측정된 비디오 데이터,
Figure 112015011419826-pct00006
은 다음과 같이 쓰여질 수 있다:
Figure 112015011419826-pct00007
(식 1)
HCM에 의해 이용되는 시간(초)에서 측정된 비디오 데이터,
Figure 112015011419826-pct00008
는 다음과 같이 쓰여질 수 있는 한편:
Figure 112015011419826-pct00009
(식 2)
그 후
Figure 112015011419826-pct00010
는 다음과 같이 산출될 수 있다:
Figure 112015011419826-pct00011
(식 3)
TMAX가 HLS 클라이언트 버퍼 크기(540)의 크기를 나타내며, 그 후 HLS 클라이언트는
Figure 112015011419826-pct00012
일 때 버퍼링 단계에 있으며, 그렇지 않다면 그것은 정상 재생 단계에서 동작한다.
도 3을 참조하여 상기 설명된 바와 같이, 스케줄링된 청크들에 대한 최적의 비트레이트들을 선택하기 위해, 콘텐트 서버(305)는 어떤 전체 품질 레벨(Q)이 네트워크 대역폭에 기초하여 지원될지를 결정한다. 품질 레벨(Q)을 달성하기 위해, 인코딩된 비트레이트는 그것의 NPV에 기초하여 산출될 수 있다.
NPV는 비디오 복잡도(“VC”; Video Complexity), 디바이스 프로파일(Device Profile), 서비스 우선순위 레벨(Service Priority Level), 코덱 프로파일(Codec Profile) 등을 포함하는 여러 인자들의 합성물이다. VC는 비디오 콘텐트의 복잡도 레벨의 추정치로서 비디오 콘텐트로부터 도출된다. NPV를 고려해볼 때, 콘텐트 서버(305)는 비트레이트가 품질의 타겟 레벨을 획득하기 위해 요구되는 것을 산출한다. 이러한 정보는 도 6에 도시된 바와 같이, 일정한 품질을 위한 일군의 비트 레이트 대 NPV의 곡선들에 의해 제공될 수 있다. 디바이스 프로파일은 스크린 크기, 지원되는 코덱 프로파일들(예컨대, 비디오를 위한 MPEG2 및 AVC 또는 오디오를 위한 Dolby AC-3 또는 AAC), 소프트웨어/하드웨어/펌웨어 버전들, OS 버전들, 플레이어-애플리케이션 버전 등을 포함할 수 있다. 서비스 우선순위 레벨은 지원되는 보장 대역폭들 또는 각각 보다 높은 및 보다 낮은 비용 가입 서비스들과 연관된 고화질 비디오들 대 표준 화질에 대한 액세스와 같은 서비스 레벨 협약들에 포함된 것들과 같은 파라미터들을 포함할 수 있다.
NPV는 임의의 주어진 품질 레벨에 대해 선형인 비트 레이트 대 NPV의 곡선을 갖고, 각각의 세그먼트에 대한 콘텐트의 복잡도에 기초하여 계산될 수 있다. 이것은 프로그램(A)에 대한 NPV가 프로그램(B)에 대한 NPV의 두 배인 경우, 그것은 유사한 비디오 품질을 유지하기 위해 프로그램(B)보다 비트 레이트가 두 배인 프로그램(A)을 취할 것임을 의미한다.
인코딩된 비트레이트는 다음의 식에 도시된 바와 같이 그것의 NPV에 기초하여(초당 바이트들로) 산출될 수 있다:
Figure 112015011419826-pct00013
(식 4)
여기서
Figure 112015011419826-pct00014
는 인코딩된 비디오의 품질 레벨을 나타내며 스칼라이고 정규화될 때
Figure 112015011419826-pct00015
는 0 내지 1의 범위에 있다. 보다 높은
Figure 112015011419826-pct00016
는 보다 높은 비디오 품질을 표시한다. 그 후 K개의 청크들에 걸쳐 단일 클라이언트에 대한 바이트들에서의 총 스케줄링 버짓(budget)은 다음과 같다:
Figure 112015011419826-pct00017
(식 5)
임의의 주어진 버짓에 대해, 콘텐트 서버(305)는 단일 클라이언트에 대한
Figure 112015011419826-pct00018
, 및 그에 따라 주어진 버짓 하에서 달성 가능한 비디오 품질을 결정한다. 다음으로, 콘텐트 서버(305)는 다수의 HLS 클라이언트들에 걸쳐
Figure 112015011419826-pct00019
의 계산을 확장한다. 각각의 HLS 클라이언트에 대한 비교할 만한 품질을 유지하기 위해, 동일한
Figure 112015011419826-pct00020
값이 선택될 수 있다. 그러므로, 스케줄링 윈도우(“SW”) 동안 모든 클라이언트들에 대한 총 바이트들은 다음과 같이 산출될 수 있다:
Figure 112015011419826-pct00021
(식 6)
여기서 N은 HLS 클라이언트들의 수이고, Si는 클라이언트(i)에 대해 마지막 다운로드된 청크의 시퀀스 번호이며, Ki는 HLS 클라이언트(i)에 대해 스케줄링된 청크들의 수이다. 간소화를 위해, 모든 청크들은 동일한 지속 기간(Tchunk)을 갖는 것으로 가정될 수 있다.
고정-레이트 채널에 대해, 총 이용 가능한 네트워크 대역폭은 바이트들/초에서 “BW”로 정의된다. 따라서 모든 HLS 클라이언트들에 대한 총 버짓은
Figure 112015011419826-pct00022
이다. 그러므로,
Figure 112015011419826-pct00023
로서 정의된 윈도우 크기를 가진 SW 동안
Figure 112015011419826-pct00024
를 전송하기 위해,
Figure 112015011419826-pct00025
는 이하의 식을 만족해야 한다:
Figure 112015011419826-pct00026
(식 7)
스케줄링된 청크들에 대한 알려진 NPV 값들을 갖고, 콘텐트 서버(305)는 다음과 같이
Figure 112015011419826-pct00027
를 산출할 수 있다:
Figure 112015011419826-pct00028
(식 8)
그 후
Figure 112015011419826-pct00029
(식 9)
임의의 특정한 이론에 의해 제한되도록 원하지 않지만, 미디어 디바이스 또는 클라이언트가 정상 재생 단계에 있을 때, 그것은 단지
Figure 112015011419826-pct00030
수의 청크들을 다운로드하려고 시도할 것이라는 것이 발견되어 왔다. 그러나, 그것의 초기 전-버퍼링 단계 동안, 그것은 그것의 클라이언트 버퍼가 가득 찰 때까지 가능한 많은 청크들을 다운로드하려고 시도할 것이다. SW 동안 클라이언트에 대한 청크들의 수를 결정하기 위해, 클라이언트 버퍼 충만도를 추정하며 SW 동안 다운로드할 청크들의 수를 알아내는 것이 중요하다. 클라이언트 버퍼 충만도를 추정하기 위해, 콘텐트 서버(305)는 식 3을 이용한다.
Figure 112015011419826-pct00031
의 값에 기초하여, K(예컨대, 다운로드할 청크들의 스케줄링된 수)가 다음에 따라 결정된다:
Figure 112015011419826-pct00032
(식 10)
여기서
Figure 112015011419826-pct00033
는 버퍼링 단계를 위한 가중 인자이다. 보다 큰
Figure 112015011419826-pct00034
는 클라이언트 버퍼를 가득 채우기 위한 보다 짧은 시간, 그에 따라 보다 짧은 버퍼링 단계를 표시한다.
각각의 클라이언트에 대한 청크들의 스케줄링된 수 및 알려진 NPV 값들을 갖고, 콘텐트 서버(305)는 식 9를 갖고
Figure 112015011419826-pct00035
을 결정하며, 모든 HLS 클라이언트들에 대해 달성 가능한 최적의 품질을 결정한다. 그 뒤, 콘텐트 서버(305)는
Figure 112015011419826-pct00036
에 가장 가까운 스케줄링된 청크에 대한 비트레이트를 선택한다.
도 7은 HCM(710) 및 스케줄 큐(720)를 구현하는 시스템(700)의 예시적인 블록도이다. 몇몇 실시예들에서, HCM(710)은 프로그램 ID(730)(예컨대, 그것이 요청하는 것을 도시하는 것) 및 콘텐트 서버(740) 내 대응하는 프로그램(745)을 표시한다. HCM(710)은 연관된 HLS 클라이언트 상태(735)(예컨대, 구동, 탐색, 중지, 재개 등)를 추적한다. 또한 HCM(710)은 그것의 연관된 HLS 클라이언트를 위한 버퍼 시간(750)을 추정한다. 몇몇 실시예들에서, 스케줄 큐(720)는 스케줄 윈도우(도시되지 않음)로부터의 최근 스케줄 결과들을 저장하며 현재 서비스하는 청크 번호 또는 요청 청크 번호(755)에 대한 포인터를 유지한다.
몇몇 실시예들에서, 클라이언트(예컨대, HCM(710)과 연관된)는 콘텐트 서버(305)로부터 프로그램(745)을 요청할 것이다. 클라이언트로 하여금 클라이언트가 프로그램 콘텐트를 수신하는 비트 레이트를 선택하도록 허용하기보다, 콘텐트 서버(305)는 수신할 클라이언트에 대한 단일의 이용 가능한 비트 레이트를 공개한다. 따라서, 도 7에서, 스케줄 큐(720)는 클라이언트가 단지 상기 특정한 세그먼트 요청에 대한 비트레이트 #2 스트림의 청크 #1만을 수신할 것임을 표시한다. 콘텐트 서버(305)가 특정한 클라이언트에 대한 상이한 할당을 결정함에 따라, 스케줄 큐(720)는 거의 즉시, 예컨대, 적은 지연을 갖거나 또는 지연 없이, 할당 변화를 반영한다. 몇몇 실시예들에서, 콘텐트 서버(305)로부터의 할당은 세그먼트마다 달라질 수 있다. 몇몇 실시예들에서, 클라이언트가 수신하는 비트 레이트를 변경할 때의 이러한 유연성은 클라이언트가 재-버퍼링할 세그먼트들의 수를 방지하거나 또는 최소화할 수 있다.
여전히 도 7을 참조하면, 정상 재생 동작들뿐만 아니라, HLS 클라이언트는 스케줄링 결정들에 영향을 미칠 수 있는 몇몇 공통 동작들도 수행할 수 있다. 예를 들면, HLS 클라이언트는 상이한 비디오 콘텐트로 스위칭할 수 있다(예컨대, 채널 변화). HLS 클라이언트는 콘텐트를 중지하며 잠시 후에 재생을 재개할 수 있다. HLS 클라이언트는 특정 위치를 탐색하며 새로운 위치로부터 살펴보기 시작할 수 있다. HLS 클라이언트는 재생을 완료하고 떠날 수 있다. 모든 이들 클라이언트 이벤트들은 전이 시간을 표시하여, HLS 클라이언트에 할당된 대역폭에 대한 수정을 요구한다.
본 명세서에 사용된 바와 같이, 채널 변화는 동일한 클라이언트가 그것이 현재 플레이하는 프로그램과 상이한 프로그램을 요청할 때이다. 중지 및 재개는 클라이언트가 연장된 시간 기간 동안 임의의 청크 다운로드를 요청하지 않을 때이다. 그러나, 그것은 그 후 연장된 시간 기간 전에 그것이 다운로드하는 청크를 따르는 시퀀스 번호를 가진 청크를 요청한다. 탐색은 클라이언트가 그것이 다운로드하는 이전 청크를 따르지 않는 시퀀스 번호를 가진 청크를 요청할 때이다. 완료는 클라이언트가 프로그램의 마지막 청크를 다운로드할 때이다.
몇몇 실시예들에서, 조정 인자 형태의 부가적인 개선들이 클라이언트들에 대역폭을 할당하기 위해 사용될 수 있다. 예를 들면, 특정한 비디오 프로그램들을 위해, 클라이언트들은
Figure 112015011419826-pct00037
를 만족시키는 비트 레이트들의 동적 범위를 가진 다수의 스트림들을 제공하지 않을 수 있다. 이러한 경우에, 콘텐트 서버(305)는 버짓 초과 또는 버짓 미달의 비트-레이트 할당들에 대한 경우들을 핸들링해야 한다. 본 명세서에 사용된 바와 같이, 버짓 초과는 산출된
Figure 112015011419826-pct00038
가 이용 가능한 최저 비트레이트보다 훨씬 더 낮을 때이다(예컨대, 청크의 비트 레이트는 클라이언트를 위해 할당된 대역폭보다 더 크다). 유사하게, 버짓 미달은 산출된
Figure 112015011419826-pct00039
가 이용 가능한 보다 높은 비트레이트보다 훨씬 더 높을 때이다(예컨대, 청크의 비트 레이트는 클라이언트를 위해 할당된 대역폭보다 낮다).
몇몇 실시예들에서, 콘텐트 서버(305)는 식 6에서 버짓 미달 또는 버짓 초과 클라이언트를 제거할 수 있다. 예를 들면, 클라이언트(P)가 버짓 초과/미달이라고 가정하면, 클라이언트(P)에 대한 버짓은 다음과 같이 산출된다:
Figure 112015011419826-pct00040
(식 11)
Figure 112015011419826-pct00041
(식 12)
몇몇 실시예들에서, 비트 스트림들이 사전-인코딩되고 저장되면, 이용 가능한 비트 레이트들이 버짓 초과 또는 미달인 것이 발생할 수 있다. 이러한 경우에, 트랜스코더는
Figure 112015011419826-pct00042
에 가까운 비트 스트림들을 생성하기 위해 사용될 수 있다. 콘텐트 서버(305)는
Figure 112015011419826-pct00043
을 계산하고 각각의 청크 간격을 두고
Figure 112015011419826-pct00044
로서 트랜스코더의 출력 비트레이트를 조정함으로써 트랜스코더와 밀접하게 작동할 수 있다.
상기 제공된 바와 같이, 전이 기간은 클라이언트 재생이 프로그램의 끝에 도달할 때 발생한다. 이것은 클라이언트 재생이 프로그램의 끝에 도달할 때(예컨대, 스케줄링하기 위해 이용 가능한 청크들의 수가 K보다 작다), 스케줄 윈도우를 채우도록 다운로드하기 위해 충분한 청크들이 없을 수 있기 때문이다. 이 경우에, 식 13은 스케줄 윈도우에서의 차이를 보상하기 위해 사용될 수 있다.
식 13에서, M은 다운로드를 위해 총 남아있는 청크들의 수를 나타내며, K는 스케줄 윈도우를 위한 스케줄링 청크들의 수를 나타낸다. 이 경우에, M<K이다. 스케줄링된 청크들이 제때 클라이언트 도착함을 보장하기 위해, 식 5에 대한 수정이 이루어진다. M개의 청크들의 NPV들의 합을 사용하는 대신에, 콘텐트 서버(305)는 다음과 같이 합을 결정한다:
Figure 112015011419826-pct00045
(식 13)
이것은 클라이언트가 TSW 스케줄 윈도우 시간보다 짧은 시간 내에 M<K 청크들의 다운로드를 완료하도록 클라이언트에 보다 높은 비트레이트를 할당한다. 클라이언트는 콘텐트 서버와 통신하는 나머지 클라이언트들에 적용되는 새로운 스케줄 윈도우의 산출을 트리거(trigger)하는 때에 세션을 종료할 수 있다.
마지막으로, 몇몇 실시예들에서, 클라이언트 단부 상의 네트워크 병목현상 문제가 발생할 수 있다. 이것은 클라이언트 측 상의 엔드 네트워크(end network)(예컨대, 802.11g/n Wi-Fi 가정 네트워크)가 속도를 상당히 낮추며, 그것의 대역폭이 스케줄링된 비트 레이트 이하로 떨어질 때 발생할 수 있다. 이러한 문제를 해결하기 위해, 이전 HLS 청크들의 다운로드 레이트의 이력이 저장될 수 있다. 따라서, 몇몇 실시예들에서, 콘텐트 서버(305)는 클라이언트의 이전 다운로드 레이트가 HLS 클라이언트에 의해 요청되는 청크를 전송하기 전에 스케줄링된 가중 네트워크 대역폭보다 더 높은지를 검사한다. 그렇지 않다면, 새로운 보다 낮은 레이트가 이전 다운로드 레이트 이력 및 HLS 클라이언트 정보에 기초하여 산출된다.
본 논의의 원리들이 적용될 수 있는 많은 가능한 실시예들을 고려해볼 때, 그려진 도면들에 대하여 본 명세서에 설명된 실시예들이 단지 예시적인 것으로 의도되며 청구항들의 범위를 제한하는 것으로서 취해져서는 안 된다는 것이 인식되어야 한다. 그러므로, 본 명세서에 설명된 바와 같은 기술들은 모든 이러한 실시예들을 다음의 청구항들 및 그것의 등가물들의 범위 내에 올 수 있는 것으로 고려한다.

Claims (9)

  1. 서버에 의해, 하이퍼텍스트 전송 프로토콜-기반 라이브 스트리밍 클라이언트 모델(“HCM”; HyperText Transfer Protocol-based live streaming model) 및 대응하는 요구 파라미터 벡터(“NPV”; need parameter vector)에 기초한 비트레이트(bitrate)를 사용하여 비디오 콘텐트를 제공하는 복수의 미디어 디바이스들의 각각에 할당할 대역폭을 결정하는 단계 - 상기 대응하는 NPV는 상기 복수의 미디어 디바이스들의 각각에 대한 스칼라 품질 값에 의해 달라짐 - ; 및
    상기 복수의 미디어 디바이스들의 각각에 할당할 상기 결정된 대역폭을 제공하는 단계
    를 포함하고,
    상기 비디오 콘텐트는 상기 서버로부터 복수의 세그먼트들(segments)로 송신되며;
    각각의 세그먼트는 세그먼트마다 달라질 수 있는 비트레이트를 사용하여 송신되는, 방법.
  2. 청구항 1에 있어서,
    상기 서버는 상기 복수의 미디어 디바이스들의 각각에 대한 상태-기반 HCM을 구성하는, 방법.
  3. 청구항 2에 있어서,
    상기 HCM은 미디어 디바이스가 버퍼링 상태 또는 재생 상태에 있는지를 제공하는, 방법.
  4. 청구항 2에 있어서,
    상기 HCM은 미디어-디바이스 버퍼의 충만도(fullness)의 추정을 제공하는, 방법.
  5. 청구항 2에 있어서,
    상기 복수의 미디어 디바이스들의 각각에 할당할 상기 결정된 대역폭은 미디어 디바이스가 상기 서버로부터 이미 수신된 콘텐트를 버퍼링하는 것을 방지하는, 방법.
  6. 청구항 1에 있어서,
    상기 서버 또는 프록시(proxy)는 상기 복수의 미디어 디바이스들의 각각에 대한 NPV를 구성하는, 방법.
  7. 청구항 6에 있어서,
    상기 NPV는 비디오 복잡도, 디바이스 프로파일(device profile), 서비스 우선순위 레벨, 및 코덱 프로파일(codec profile) 중 하나 이상에 기초하는, 방법.
  8. 청구항 1에 있어서,
    각각의 미디어 디바이스에 대해 할당할 상기 결정된 대역폭의 범위 내에 있는 비트 레이트에서 상기 비디오 콘텐트를 상기 서버로부터 하나 이상의 미디어 디바이스들로 송신하는 단계를 더 포함하는, 방법.
  9. 비디오 콘텐트를 제공하는 서버로서,
    프로세서들의 세트; 및
    명령어들을 포함하는 컴퓨터-판독 가능한 저장 매체
    를 포함하고, 상기 명령어들은:
    하이퍼텍스트 전송 프로토콜-기반 라이브 스트리밍 클라이언트 모델(HCM) 및 대응하는 요구 파라미터 벡터(NPV)에 기초한 비트레이트를 사용하여 복수의 미디어 디바이스들의 각각에 할당할 대역폭을 결정하고 - 상기 대응하는 NPV는 상기 복수의 미디어 디바이스들의 각각에 대한 스칼라 품질 값에 의해 달라짐 - ;
    상기 복수의 미디어 디바이스들의 각각에 할당할 상기 결정된 대역폭을 제공
    하도록 상기 프로세서들의 세트를 제어하기 위한 명령어들이고,
    상기 비디오 콘텐트는 상기 서버로부터 복수의 세그먼트들로 송신되며;
    각각의 세그먼트는 세그먼트마다 달라질 수 있는 비트레이트를 사용하여 송신되는, 비디오 콘텐트를 제공하는 서버.
KR1020157002890A 2012-07-05 2013-07-01 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들 KR102110627B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261668286P 2012-07-05 2012-07-05
US61/668,286 2012-07-05
US13/932,056 2013-07-01
PCT/US2013/048955 WO2014008200A1 (en) 2012-07-05 2013-07-01 Methods and devices for bandwidth allocation in adaptive bitrate streaming
US13/932,056 US8910229B2 (en) 2012-07-05 2013-07-01 Methods and devices for efficient adaptive bitrate streaming

Publications (2)

Publication Number Publication Date
KR20150042191A KR20150042191A (ko) 2015-04-20
KR102110627B1 true KR102110627B1 (ko) 2020-05-13

Family

ID=49879562

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020157002890A KR102110627B1 (ko) 2012-07-05 2013-07-01 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들

Country Status (5)

Country Link
US (1) US8910229B2 (ko)
EP (1) EP2870776B8 (ko)
KR (1) KR102110627B1 (ko)
CN (1) CN104471955B (ko)
WO (1) WO2014008200A1 (ko)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10003851B2 (en) * 2009-11-24 2018-06-19 Imagine Communications Corp. Managed multiplexing of video in an adaptive bit rate environment
US20140181266A1 (en) * 2011-09-29 2014-06-26 Avvasi Inc. System, streaming media optimizer and methods for use therewith
US9628542B2 (en) * 2012-08-24 2017-04-18 Akamai Technologies, Inc. Hybrid HTTP and UDP content delivery
US9560392B2 (en) * 2012-09-07 2017-01-31 Google Inc. Dynamic bit rate encoding
KR102023582B1 (ko) * 2012-10-11 2019-11-04 삼성전자주식회사 무선 통신 시스템에서 청크 기반 스케줄링 방법 및 장치
EP2728829A1 (en) * 2012-10-30 2014-05-07 Thomson Licensing Method for downloading content according to communication parameters, and associated content receiver
US9967302B2 (en) * 2012-11-14 2018-05-08 Samsung Electronics Co., Ltd. Method and system for complexity adaptive streaming
CN103873926B (zh) * 2012-12-13 2017-03-22 腾讯科技(深圳)有限公司 下载并播放媒体文件的方法及系统
US9549000B2 (en) 2013-03-15 2017-01-17 Arris Enterprises, Inc. Streaming media from a server delivering individualized content streams to clients
CN105409226B (zh) * 2013-07-25 2018-05-04 华为技术有限公司 有效控制自适应流媒体中的客户端行为的系统和方法
KR102064792B1 (ko) * 2013-12-17 2020-01-10 한국전자통신연구원 Http 기반의 멀티미디어 스트리밍 서비스를 위한 네트워크 대역폭 적응적 콘텐츠 생성 방법 및 시스템
US9542953B2 (en) * 2014-01-22 2017-01-10 Comcast Cable Communications, Llc Intelligent data delivery
US9584577B2 (en) 2014-04-03 2017-02-28 Cisco Technology, Inc. Method for enabling use of HLS as a common intermediate format
JP6419848B2 (ja) * 2014-06-30 2018-11-07 ディッシュ テクノロジーズ エル.エル.シー.DISH Technologies L.L.C. 帯域幅最適化のための適応的データセグメント配信調停
US9838455B2 (en) * 2014-09-19 2017-12-05 Mobitv, Inc. Fast encoding of live streaming media content
US10135748B2 (en) 2014-09-29 2018-11-20 Apple Inc. Switching between media streams
US9578395B1 (en) * 2014-09-30 2017-02-21 Amazon Technologies, Inc. Embedded manifests for content streaming
US9407968B2 (en) * 2014-12-22 2016-08-02 Verizon Patent And Licensing Inc. Multicast and unicast adaptive bitrate services
US20160188196A1 (en) * 2014-12-30 2016-06-30 Airwatch Llc Floating media player
US9800903B2 (en) 2015-04-09 2017-10-24 Dejero Labs Inc. Systems, devices and methods for distributing data with multi-tiered encoding
US10476926B2 (en) * 2015-06-12 2019-11-12 Telefonaktiebolaget Lm Ericsson (Publ) System and method for managing ABR bitrate delivery responsive to video buffer characteristics of a client
US10349104B2 (en) 2015-08-19 2019-07-09 Ericsson Ab System and method for managing segment delivery and bandwidth responsive to encoding complexity metrics
US20170055007A1 (en) * 2015-08-19 2017-02-23 Ericsson Ab System and method for managing segment delivery and bandwidth responsive to encoding complexity metrics
US9788026B2 (en) * 2015-08-25 2017-10-10 Imagine Communications Corp. Converting adaptive bitrate chunks to a streaming format
KR102209292B1 (ko) * 2015-11-04 2021-01-29 삼성전자 주식회사 멀티미디어 시스템에서 데이터 제공 방법 및 장치
KR101780247B1 (ko) * 2016-03-04 2017-09-20 주식회사 큐버 동적 적응 버퍼링 기반의 ott 데이터 처리 방법
US11956512B2 (en) * 2016-04-07 2024-04-09 Telefonaktiebolaget Lm Ericsson (Publ) Media stream prioritization
US10491649B2 (en) * 2016-04-12 2019-11-26 Harmonic, Inc. Statistical multiplexing using a plurality of encoders operating upon different sets of unique and shared digital content
WO2018017839A1 (en) 2016-07-20 2018-01-25 Arris Enterprises Llc Video and data multiplexing in an adaptive bitrate server
US11677799B2 (en) * 2016-07-20 2023-06-13 Arris Enterprises Llc Client feedback enhanced methods and devices for efficient adaptive bitrate streaming
US10547856B2 (en) * 2016-10-18 2020-01-28 Netflix, Inc. Constant-slope bitrate allocation for distributed encoding
US10812559B2 (en) * 2017-01-18 2020-10-20 Amazon Technologies, Inc. Just-in-time variable adaptive encoding and delivery of media content
US10491645B2 (en) 2017-03-01 2019-11-26 At&T Intellectual Property I, L.P. System and method for switching between adaptive bit rate and fixed rate streams
US11444887B2 (en) * 2017-03-08 2022-09-13 Arris Enterprises Llc Excess bitrate distribution based on quality gain in sabr server
US10397286B2 (en) * 2017-05-05 2019-08-27 At&T Intellectual Property I, L.P. Estimating network data streaming rate
US10182269B1 (en) * 2018-04-24 2019-01-15 Verizon Patent And Licensing Inc. HTTP live streaming delivery over multicast
US11089346B2 (en) * 2018-07-24 2021-08-10 At&T Intellectual Property I, L.P. Adaptive bitrate streaming techniques
US10945005B2 (en) * 2018-12-07 2021-03-09 Arris Enterprises Llc Multiple parental rating content and method of presentation
CN110798643B (zh) * 2019-11-25 2022-02-22 广州市奥威亚电子科技有限公司 一种用户终端设备及使用其的视音频质量保证系统
CN111107387B (zh) * 2019-12-30 2021-12-28 广州酷狗计算机科技有限公司 视频转码方法、装置及计算机存储介质
EP4101175A1 (en) * 2020-02-04 2022-12-14 Dolby International AB Method and device for adaptive playout of media content
US11290513B1 (en) 2021-04-14 2022-03-29 Synamedia Limited Distributed adaptive bitrate (ABR) asset delivery
CN114727131A (zh) * 2022-03-28 2022-07-08 慧之安信息技术股份有限公司 基于机器学习的流媒体推流性能提升方法和装置
WO2024080597A1 (ko) * 2022-10-12 2024-04-18 삼성전자주식회사 오디오 비트스트림을 적응적으로 처리하는 전자 장치, 방법, 및 비일시적 컴퓨터 판독가능 저장 매체

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000068362A (ko) 1997-07-01 2000-11-25 이데이 노부유끼 화상 부호화 제어장치와 방법, 부호화 시스템, 전송 시스템 및방송 시스템
US8122145B2 (en) 2004-05-17 2012-02-21 Nokia Corporation System, method and computer program product for grouping clients and transferring content in accordance with the same
GB0706424D0 (en) * 2007-04-02 2007-05-09 British Telecomm Video streaming
EP2200319A1 (en) * 2008-12-10 2010-06-23 BRITISH TELECOMMUNICATIONS public limited company Multiplexed video streaming
CN102498715B (zh) * 2009-05-19 2015-09-30 宝美瑞思网络有限公司 带宽回收用受管理自适应比特率的方法、装置
US9917874B2 (en) * 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
EP2486491A4 (en) * 2009-10-06 2013-10-23 Unwired Planet Llc MANAGING NETWORK TRAFFIC BY EDITING A MANIFEST FILE AND / OR USING A INTERMEDIATE FLOW CONTROL
US10003851B2 (en) * 2009-11-24 2018-06-19 Imagine Communications Corp. Managed multiplexing of video in an adaptive bit rate environment
US9137278B2 (en) 2010-04-08 2015-09-15 Vasona Networks Inc. Managing streaming bandwidth for multiple clients
KR101744974B1 (ko) * 2010-09-16 2017-06-08 삼성전자주식회사 하이퍼텍스트 전송 프로토콜 스트리밍 서비스에서 복수의 컨텐츠 구성 요소에 대한 공통 속성 표현 방법 및 장치
US8930559B2 (en) * 2012-06-01 2015-01-06 Verizon Patent And Licensing Inc. Adaptive hypertext transfer protocol (“HTTP”) media streaming systems and methods

Also Published As

Publication number Publication date
EP2870776B1 (en) 2017-11-01
WO2014008200A1 (en) 2014-01-09
EP2870776A1 (en) 2015-05-13
KR20150042191A (ko) 2015-04-20
US20140013376A1 (en) 2014-01-09
CN104471955A (zh) 2015-03-25
EP2870776B8 (en) 2017-12-13
US8910229B2 (en) 2014-12-09
CN104471955B (zh) 2017-08-11

Similar Documents

Publication Publication Date Title
KR102110627B1 (ko) 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들
CA3031584C (en) Client feedback enhanced methods and devices for efficient adaptive bitrate streaming
US11729109B2 (en) Excess bitrate distribution based on quality gain in SABR server
US8516144B2 (en) Startup bitrate in adaptive bitrate streaming
US11665218B2 (en) Fast encoding of live streaming media content
US10116971B2 (en) Method and system for fetching a portion of a live media stream before a first ad finishes playing to detect the subsequent ad indicator for live consecutive ad replacement
KR102048898B1 (ko) 다중 경로 환경에서의 적응적 스트리밍 시스템 및 방법
US8812621B2 (en) Reducing fetching load on cache servers in adaptive streaming
US9015779B2 (en) Streaming video server with segment length control and methods for use therewith
EP2360923A1 (en) Method for selectively requesting adaptive streaming content and a device implementing the method
EP2360924A1 (en) A digital multimedia data transmission device and method
EP3022884A1 (en) Quality optimization with buffer and horizon constraints in adaptive streaming
KR20130044218A (ko) 청크로 스트리밍된 컨텐츠를 복구하기 위한 방법
Bae et al. Why is http adaptive streaming so hard?
US11563990B2 (en) Method and apparatus for automatic HLS bitrate adaptation
EP3371978B1 (en) Contiguous streaming of media stream
Bacega et al. Study about the applicability of low latency in HAS transmission systems
KR102304476B1 (ko) 적응적 스트리밍 서비스를 위한 다중 경로 기반 블록 전송 시스템 및 스트리밍 방법
US11622135B2 (en) Bandwidth allocation for low latency content and buffered content
Yun et al. Dynamic segment duration control for live streaming over HTTP
EP4195626A1 (en) Streaming media content as media stream to a client system
EP4376420A1 (en) Optimized video transcoding based on a timing requirement
Shuai Dynamic adaptive video streaming with minimal buffer sizes
WEIWEI An experimental study of video uploading from mobile devices with HTTP streaming

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