KR101942208B1 - Dlna http 스트리밍 클라이언트들을 위한 서버측 적응형 비트 레이트 제어 - Google Patents
Dlna http 스트리밍 클라이언트들을 위한 서버측 적응형 비트 레이트 제어 Download PDFInfo
- Publication number
- KR101942208B1 KR101942208B1 KR1020177021800A KR20177021800A KR101942208B1 KR 101942208 B1 KR101942208 B1 KR 101942208B1 KR 1020177021800 A KR1020177021800 A KR 1020177021800A KR 20177021800 A KR20177021800 A KR 20177021800A KR 101942208 B1 KR101942208 B1 KR 101942208B1
- Authority
- KR
- South Korea
- Prior art keywords
- video data
- data asset
- server
- bandwidth
- media
- Prior art date
Links
- 230000003044 adaptive effect Effects 0.000 title claims abstract description 30
- 238000004891 communication Methods 0.000 claims abstract description 34
- 238000000034 method Methods 0.000 claims abstract description 34
- 239000012634 fragment Substances 0.000 claims abstract 6
- 239000000872 buffer Substances 0.000 claims description 77
- 230000005540 biological transmission Effects 0.000 claims description 30
- 238000001914 filtration Methods 0.000 claims description 6
- 230000003111 delayed effect Effects 0.000 claims description 4
- 230000000977 initiatory effect Effects 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 4
- 230000009467 reduction Effects 0.000 claims description 3
- 238000004422 calculation algorithm Methods 0.000 description 68
- 238000005259 measurement Methods 0.000 description 65
- 238000010586 diagram Methods 0.000 description 20
- 238000004364 calculation method Methods 0.000 description 19
- 238000004590 computer program Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 13
- 238000012360 testing method Methods 0.000 description 11
- 230000004044 response Effects 0.000 description 9
- 230000006835 compression Effects 0.000 description 8
- 238000007906 compression Methods 0.000 description 8
- 230000000750 progressive effect Effects 0.000 description 8
- 238000007493 shaping process Methods 0.000 description 8
- 238000013139 quantization Methods 0.000 description 7
- 241000251730 Chondrichthyes Species 0.000 description 6
- 230000000694 effects Effects 0.000 description 6
- 238000003860 storage Methods 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 230000000875 corresponding effect Effects 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 230000007423 decrease Effects 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 3
- 230000001143 conditioned effect Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 101150012579 ADSL gene Proteins 0.000 description 2
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 2
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 2
- 230000003750 conditioning effect Effects 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000003595 spectral effect Effects 0.000 description 2
- 238000012935 Averaging Methods 0.000 description 1
- 238000012300 Sequence Analysis Methods 0.000 description 1
- 241001122767 Theaceae Species 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 230000008571 general function Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000000691 measurement method Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/0864—Round trip delays
-
- H04L65/4069—
-
- H04L65/602—
-
- H04L65/607—
-
- 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
-
- 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/70—Media network packetisation
-
- 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/75—Media network packet handling
- H04L65/752—Media network packet handling adapting media to network capabilities
-
- 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/75—Media network packet handling
- H04L65/762—Media network packet handling at the source
-
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing 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
-
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing 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/23439—Processing 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 for generating different versions
-
- 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
- H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Quality & Reliability (AREA)
- Environmental & Geological Engineering (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
스트리밍 데이터를 클라이언트로 적응적으로 송신하기 위한 방법들 및 시스템들이 설명된다. 일 실시예에서, 방법은, 서버에서, 클라이언트로부터 데이터 자산에 대한 요청을 수신하는 단계, 초기 트랜스코딩 파라미터들에 따라 데이터 자산의 적어도 세그먼트를 트랜스코딩하는 단계, 통신 채널을 통해 서버로부터 클라이언트로 데이터 자산의 트랜스코딩된 세그먼트의 제1 프래그먼트를 송신하는 단계, 클라이언트에 의한 데이터 자산의 트랜스코딩된 세그먼트의 적어도 제1 프래그먼트의 수신을 확인응답하는 정보로부터 적어도 부분적으로 통신 채널의 대역폭의 추정치를 생성하는 단계, 통신 채널의 대역폭의 추정치로부터 적어도 부분적으로 적응형 트랜스코딩 파라미터들을 생성하는 단계 - 추정치는 서버에서 생성됨 -, 적응형 트랜스코딩 파라미터들에 따라 데이터 자산의 추가적인 세그먼트를 트랜스코딩하는 단계, 및 데이터 자산의 추가적인 세그먼트를 송신하는 단계를 포함한다.
Description
관련 출원들에 대한 상호 참조
본 출원은 2015년 1월 8일에 출원된 Mark S. Schmidt, Praveen N Moorthy 및 Baozhou Li에 의한 "SERVER-SIDE ADAPTIVE BIT RATE CONTROL FOR DLNA HTTP STREAMING CLIENTS"라는 제목의 미국 가특허 출원 제62/100,934호의 이익을 주장하며, 상기 출원은 본 명세서에 참조로 포함된다.
기술분야
본 발명은 디지털 미디어 스트림들의 적응형 비트 인코딩을 위한 시스템들 및 방법들, 특히 그러한 스트림들의 서버측 적응형 비트 인코딩을 위한 시스템 및 방법에 관한 것이다.
미디어 프로그램들의 보급과 재생은 지난 10년 동안 큰 변화를 겪었다. 이전에는, 아날로그 방송(일반, 위성 또는 케이블)에 의해 또는 미디어 프로그램들의 물리적 사본들을 극장들과 같은 프리젠테이션 장소들에 보급하는 것에 의해, 미디어 프로그램들(오디오, 비디오 또는 둘 다를 포함할 수 있음)이 보급되었다. 미디어 프로그램들의 보급 및 재생에 디지털 기술들이 큰 영향을 미쳤다.
특히, (개선된 대역폭 및 개선된 압축/압축 해제 기술들을 가진) 디지털 기술은 인터넷을 통한 미디어 프로그램들의 보급 및 재생을 허용하였다. 이러한 보급 및 재생 방법들은 통상적인 수단으로 경쟁력을 갖추게 되었다. 인터넷을 통한 미디어 프로그램들의 보급은 단순 다운로드, 프로그레시브 다운로드 또는 스트리밍에 의해 발생할 수 있다.
단순 다운로드는 임의의 편리한 순서로 미디어 파일의 바이트들을 다운로드하는 반면, 프로그레시브 다운로드는 파일의 시작부분에서 바이트들을 다운로드하고 계속해서 파일을 마지막 바이트까지 순차적으로 그리고 연속적으로 다운로드한다. 단순 다운로드 동안의 임의의 특정 시간에서는, 미디어 플레이어가 재생을 시작할 수 있기 전에 전체 파일이 먼저 다운로드되어야 하기 때문에, 파일의 일부들은 재생에 즉시 사용가능하지 않을 것이다.
프로그레시브 다운로드에 의하면, 미디어 프로그램을 갖는 미디어 파일은 다이얼 업, DSL, ADSL, 케이블, T1 또는 다른 고속 접속을 사용하여 인터넷을 통해 다운로드된다. 이러한 다운로드는 통상적으로 인터넷을 통해 웹 서버에 의해 수행된다. 미디어 플레이어들은 파일의 시작부분이 충분히 다운로드되고 나면 재생을 시작할 수 있지만, 미디어 플레이어는 재생이 일어날 수 있기 전에 일부 형태의 재생을 지원하기에 충분한 정보를 다운로드해야 한다. 프로그레시브하게 다운로드되는 미디어 파일들의 재생은 느린 인터넷 접속들에 의해 종종 지연되며, 또한 겨우 수 초 후에 뚝뚝 끊어지고/지거나 중지될 가능성이 높다. 프로그레시브하게 다운로드되는 미디어 프로그램이 완전히 다운로드되고 나면, 나중에 사용하기 위해 최종 사용자 컴퓨터에 저장될 수 있다.
프로그레시브 다운로드의 단점들 중 하나는 데이터를 송신하는 엔티티(웹 서버)가 단순히 데이터를 가능한 한 빨리 클라이언트에게 푸시하는 것이다. 많은 미디어 플레이어들의 프로그레시브 다운로드 능력은 적절한 양의 데이터가 다운로드되자마자 재생될 수 있게 하기 때문에, 비디오를 "스트리밍"하는 것처럼 보일 수 있다. 그러나, 전체 파일이 웹 서버에 의해 전달되고 웹 서버가 비디오 파일의 데이터 레이트를 고려하지 않을 때까지, 사용자는 파일의 끝까지 빨리 감기를 할 수 없다. 예를 들어, 네트워크 대역폭이 비디오 파일에 의해 요구되는 데이터 레이트보다 낮으면, 사용자는 재생이 시작될 수 있기 전에 더 오랜 시간 기간 동안 기다려야 할 것이며, 뚝뚝 끊어지는 "단속적인(on and off)" 재생을 경험할 수 있다.
웹 서버들은 통상적으로 TCP(transfer control protocol)의 상부에서 HTTP(hypertext transport protocol)를 사용하여 네트워크를 통해 파일들을 송신한다. 네트워크를 통해 데이터 패킷들의 전송을 제어하는 TCP는 속도가 아니라, 데이터의 보장된 전달을 위해 최적화되어 있다. 따라서, 브라우저가 데이터가 누락되었음을 감지하면, 재전송 요청이 발행될 것이고, 데이터가 재전송될 것이다. 높은 전달 에러들이 있는 네트워크들에서, 재전송 요청들은 많은 양의 대역폭을 소비할 수 있다. TCP는 적절한 데이터 또는 대역폭 제어의 효율적인 전달을 위해 설계되지 않았기 때문에(오히려, 모든 데이터의 전달 보장), 모든 애플리케이션들, 특히 스트리밍 애플리케이션들에서 비디오 데이터를 전달하는 것은 바람직하지 않다.
스트리밍은 미디어 컨텐츠를 미디어 플레이어에게 연속적으로 전달하고, 미디어 컨텐츠의 전달과 동시에 미디어 재생이 발생한다. 최종 사용자는 미디어를 컨텐츠 제공자에 의해 전달되는 즉시 재생할 수 있다. 통상적인 스트리밍 기술들은 단일 제공자가 데이터의 스트림을 최종 사용자들의 집합에게 전달하는 것을 기초로 한다. 단일 스트림을 많은 관객에게 전달하기 위해서는 높은 대역폭들 및 중앙 처리 장치(CPU) 전력이 필요하며, 최종 사용자들의 수가 증가함에 따라 제공자의 필수 대역폭이 증가한다.
프로그레시브 다운로드와 달리, 스트리밍 미디어는 온-디맨드 또는 라이브로 전달될 수 있다. 프로그레시브 다운로드는 전체 파일을 다운로드할 필요가 있거나 또는 시작부분에서 재생을 시작하기 위해 전체 파일 중 충분한 양을 다운로드할 필요가 있고, 스트리밍은 파일 내의 임의의 포인트에서 즉시 재생을 가능하게 한다. 최종 사용자들은 미디어 파일을 건너뛰어 재생을 시작하거나 또는 미디어 파일 내의 임의의 포인트로 재생을 변경할 수 있다. 따라서, 최종 사용자는 파일이 프로그레시브하게 다운로드되기를 기다릴 필요가 없다. 통상적으로, 스트리밍 미디어는 고 대역폭 능력들을 갖춘 몇 대의 전용 서버들로부터 전달된다.
스트리밍 미디어 서버는 비디오 파일들에 대한 요청들을 수락하는 특수 디바이스이며, 해당 파일들의 포맷, 대역폭 및 구조에 대한 정보를 사용하여, 비디오를 재생하는 데 필요한 양의 데이터를, 이를 재생하는 데 필요한 레이트로 정확히 전달할 수 있다. 스트리밍 미디어 서버들은 또한 미디어 플레이어의 송신 대역폭 및 능력들을 설명할 수 있다. 웹 서버와 달리, 스트리밍 미디어 서버는 제어 메시지들 및 데이터 메시지들을 사용하여 클라이언트 컴퓨터와 통신하여, 비디오가 재생됨에 따라 변화하는 네트워크 조건들에 적응된다.
스트리밍 미디어 서버들은 비디오 스트림들을 전달하기 위해 HTTP 및 TCP를 사용할 수 있지만, 이들은 일반적으로 RTSP(real time streaming protocol) 및 UDP(user datagram protocol)를 사용하는데, 왜냐하면 이들 프로토콜들이 제어 메시지들을 허용하고, 오버 헤드를 줄임으로써 대역폭을 절약하기 때문이다. TCP와 달리, 송신 동안에 데이터가 드롭되면, UDP는 재전송 요청들을 송신하지 않는다. 대신에, 서버가 계속해서 데이터를 전송한다.
주로 모바일 디바이스들용으로 개발된 다른 스트리밍 프로토콜들도 사용되고 있다. 한 가지 그러한 프로토콜이 DLNA(digital living network alliance) 스트리밍 프로토콜이며, 이는 주로 가정 전역에서 미디어를 스트리밍하는 데 사용된다. DLNA는 디바이스들(서비스들을 제공하는 네트워크 엔티티들), 서비스들(재생과 같은 액션들을 제공함) 및 제어 포인트들(네트워크 상의 다른 디바이스들을 발견하고 제어할 수 있는 네트워크 엔티티들)로 구성된 UPnP 모델을 사용한다. DLNA는 UPnP 모델을 확장하여, 디바이스들이 서로 상호작용하여 디지털 데이터를 전달하게 할 수 있고, 제어 포인트들이 필요에 따라 디바이스들을 구성하고, 컨텐츠의 흐름을 개시하고, 그 후, 제어를 포기하게 할 수 있다. DLNA는 TCP/IP 프로토콜을 사용하는 전송에 HTTP를 사용한다. 따라서, DLNA는 서버측 적응형 비트 레이트 제어를 본질적으로 지원하지 않지만, 이러한 응용들에서의 이러한 적응형 비트 레이트 제어에 대한 필요성이 때로는 비모바일 디바이스들에 대한 경우보다 더 크다.
따라서, HLS 및 유사한 프로토콜들에서 서버측 적응형 비트 레이트 제어를 위한 방법 및 장치가 관련 기술분야에 필요하다. 이하, 이 필요성을 만족시키는 방법 및 장치를 설명한다.
전술한 요구사항들을 해결하기 위해, 본 발명은 스트리밍 데이터를 클라이언트에게 적응적으로 송신(adaptively transmitting)하기 위한 방법 및 장치를 개시한다. 일 실시예에서, 방법은, 서버에서, 클라이언트로부터 데이터 자산에 대한 요청을 수신하는 단계; 초기 트랜스코딩 파라미터들에 따라 데이터 자산의 일부를 트랜스코딩하는 단계; 통신 채널을 통해 서버로부터 클라이언트로 데이터 자산의 트랜스코딩된 일부를 송신하는 단계; 클라이언트에 의해 데이터 자산의 트랜스코딩된 일부의 수신을 확인응답(acknowledging)하는 정보로부터 적어도 부분적으로 통신 채널의 대역폭의 추정치를 생성하는 단계- 대역폭의 추정치는 데이터 자산의 송신되는 트랜스코딩된 일부의 왕복 시간(round trip time)(RTT) 및 데이터 자산의 송신되는 트랜스코딩된 적어도 일부의 사이즈에 따라 적어도 부분적으로 생성됨 -; 통신 채널의 대역폭의 추정치로부터 적어도 부분적으로 적응형 트랜스코딩 파라미터들을 생성하는 단계 - 추정치는 서버에서 생성됨 -; 적응형 트랜스코딩 파라미터들에 따라 데이터 자산의 시간적으로 후속하는 추가 부분을 트랜스코딩하는 단계; 및 서버로부터 클라이언트로 데이터 자산의 추가 부분을 송신하는 단계를 포함한다. 다른 실시예는 상기 동작들을 수행하기 위한 프로세서 명령어들을 저장하는 메모리에 통신가능하게 결합된 프로세서를 포함하는 장치에 의해 입증된다.
이제 도면들을 참조하며, 여기서 유사한 참조 번호들은 전체에 걸쳐 대응하는 부분들을 나타낸다.
도 1은 미디어 스트리밍 세션의 서버측 적응형 비트 레이트(adaptive bit rate)(ABR) 제어를 위한 예시적인 아키텍처를 도시하는 도면이다.
도 2는 DLNA ABR 서버 및 클라이언트 시스템을 포함하는 데이터 스트리밍 시스템의 예시적인 구현의 도면이다.
도 3은 HLS 프로토콜을 사용하여 전달되는 동일한 미디어 시퀀스의 비트 레이트 대 순간 미디어 또는 전송 비트 레이트의 차이를 도시한다.
도 4는 DLNA 타이머 기반 대역폭 측정치들을 도시하는 도면이다.
도 5는 동적으로 변하는 스위치 레이트 캡에 대해 플롯화된 TCP 정보 파라미터들을 포함하는 결과를 도시하는 도면이다.
도 6은 마지막 데이터 전송 정보 및 DLNA 번칭을 사용한 비트 레이트 계산들을 비교하는 연구 결과를 도시하는 도면이다.
도 7 및 도 8은 VBR 비디오 스트림에 대해 동작 중인 타이머 기반 알고리즘을 도시하는 플롯들이다.
도 9는 비트 레이트 해상도 및 제어를 수행하기 위한 예시적인 동작들을 도시하는 도면이다.
도 10은 비트 레이트 해상도 및 제어를 수행하기 위한 장치의 실시예를 도시하는 도면이다.
도 11은 서버측 ABR 비디오 비트 레이트 및 해상도 제어 알고리즘의 의사 코드(pseudocode) 구현을 도시하는 도면이다.
도 12는 루프 출력을 양자화하기 위한 예시적인 의사 코드를 도시하는 도면이다.
도 13은 다양한 종횡비들 및 비디오 해상도들에 대한 픽셀 당 코딩된 비디오 비트들 대 비디오 코딩된 비트 레이트를 도시하는 도면이다.
도 14는 서버측 ABR 알고리즘에서 사용되는 2개의 상이한 세트의 루프 이득 파라미터들에 대한 성능의 예를 도시한다.
도 15는 본 발명의 엘리먼트들을 구현하는 데 사용될 수 있는 예시적인 컴퓨터 시스템을 도시하는 도면이다.
도 1은 미디어 스트리밍 세션의 서버측 적응형 비트 레이트(adaptive bit rate)(ABR) 제어를 위한 예시적인 아키텍처를 도시하는 도면이다.
도 2는 DLNA ABR 서버 및 클라이언트 시스템을 포함하는 데이터 스트리밍 시스템의 예시적인 구현의 도면이다.
도 3은 HLS 프로토콜을 사용하여 전달되는 동일한 미디어 시퀀스의 비트 레이트 대 순간 미디어 또는 전송 비트 레이트의 차이를 도시한다.
도 4는 DLNA 타이머 기반 대역폭 측정치들을 도시하는 도면이다.
도 5는 동적으로 변하는 스위치 레이트 캡에 대해 플롯화된 TCP 정보 파라미터들을 포함하는 결과를 도시하는 도면이다.
도 6은 마지막 데이터 전송 정보 및 DLNA 번칭을 사용한 비트 레이트 계산들을 비교하는 연구 결과를 도시하는 도면이다.
도 7 및 도 8은 VBR 비디오 스트림에 대해 동작 중인 타이머 기반 알고리즘을 도시하는 플롯들이다.
도 9는 비트 레이트 해상도 및 제어를 수행하기 위한 예시적인 동작들을 도시하는 도면이다.
도 10은 비트 레이트 해상도 및 제어를 수행하기 위한 장치의 실시예를 도시하는 도면이다.
도 11은 서버측 ABR 비디오 비트 레이트 및 해상도 제어 알고리즘의 의사 코드(pseudocode) 구현을 도시하는 도면이다.
도 12는 루프 출력을 양자화하기 위한 예시적인 의사 코드를 도시하는 도면이다.
도 13은 다양한 종횡비들 및 비디오 해상도들에 대한 픽셀 당 코딩된 비디오 비트들 대 비디오 코딩된 비트 레이트를 도시하는 도면이다.
도 14는 서버측 ABR 알고리즘에서 사용되는 2개의 상이한 세트의 루프 이득 파라미터들에 대한 성능의 예를 도시한다.
도 15는 본 발명의 엘리먼트들을 구현하는 데 사용될 수 있는 예시적인 컴퓨터 시스템을 도시하는 도면이다.
이하의 설명에서는, 본 발명의 일부를 형성하고 본 발명의 몇몇 실시예들을 예시적으로 도시하는 첨부 도면들을 참조한다. 본 발명의 범위를 벗어나지 않고도, 다른 실시예들이 사용될 수 있고, 구조적인 변경들이 이루어질 수 있다는 것이 이해된다.
개요
HTTP를 사용하는 디지털 리빙 네트워크 얼라이언스(Digital Living Network Alliance)(DLNA) 클라이언트 플레이어들과 같은 플레이어들에게 TCP/IP를 통해 연속적인 미디어 스트림들을 전달하기 위한 트랜스코더 비디오 및 오디오 비트 레이트 및 해상도의 서버측 제어를 위한 방법 및 장치가 개발된다. 서버 애플리케이션은 미디어의 TCP/IP 다운로드들을 위해 개별 클라이언트가 사용할 수 있는 네트워크 대역폭을 측정하고, 그에 따라 스트림 비트 레이트 및 구성을 조정하여, 클라이언트가 클라이언트 재생 버퍼들의 언더플로우의 발생을 최소화하기에 충분한 시간 마진을 갖고 미디어 스트림을 검색하게 할 수 있다. 실시예들은 셀룰러(LTE, 3G) 및 WiFi 네트워크들을 통해 DLNA-대-HLS(HTTP Live Streaming) 변환 프록시로 프로비저닝된 DLNA 클라이언트들 또는 Apple의 HLS 클라이언트들로 스트리밍하는 것을 포함한다.
도 1은 미디어 스트리밍 세션의 서버측 적응형 비트 레이트(ABR) 제어를 위한 예시적인 아키텍처(100)를 도시하는 도면이다. 도시된 실시예에서, 아키텍처(100)는 예를 들어, 컨텐츠 배포 네트워크(content distribution network)(CDN) 스토리지 서버들(104)에 포함된 캐싱된 미디어 스트림들의 OTT(over-the-top) 전달을 위해 에지 서버들에서 구현될 수 있는 ABR 서버(102A)를 포함한다. 일 실시예에서, OTT 에지 ABR 서버(102)는 대역폭(BW)이 제약된 네트워크들을 통한 전달에 적합하지 않을 수 있는 높은 품질 및 높은 비트 레이트로 준비된 미디어인 메자닌(mezzanine) 컨텐츠 상에서 동작한다. ABR 서버는 프로세싱된 컨텐츠에 대해 동작하는 케이블, 통신 회사, 위성 또는 다른 인터넷 프로토콜(IP) 다중 시스템 운영자(multiple-system operator)(MSO) 네트워크에 대해 소비자의 가정에서 접속되는 소비자의 게이트웨이(GW) 디바이스(102B)에 의해 구현될 수도 있다. 이 가입자 게이트웨이 디바이스(102B)는 재생을 위해 MSO 네트워크를 통해 전달되는 컨텐츠를 수신, 저장 및 검색하기 위한 하드 디스크 드라이브(HDD) 스토리지 및/또는 디지털 비디오 레코더(DVR) 능력을 가질 수 있다. 소비자 GW 장치(102B)는 또한 MSO 네트워크로부터 수신되는 라이브 튜닝된 스트림들에 대한 ABR 트랜스코딩 제어를 제공한다. 이하, OTT 에지 ABR 서버 및 고객의 GW ABR 서버는 대안적으로 ABR 서버(들)(102)로서 집합적으로 지칭될 수 있다.
이러한 예시적인 서버측 실시예들 모두에서, ABR 서버(102)는 인터넷(114)과 같은 대역폭이 제약된 IP 네트워크들을 통해 무선 또는 유선 클라이언트들(108A-108D)(이하, 대안적으로 클라이언트(들)(108)로서 집합적으로 지칭됨)에게 미디어 스트림들을 제공한다. 미디어 스트림들은 클라이언트(108)가 사용할 수 있는 네트워크 대역폭에 적합하도록 ABR 서버(102)에 의해 트랜스코딩되거나 번역(transrated)된다. 클라이언트들(108)이 TCP/IP를 통해 HTTP를 사용하여 미디어 데이터를 요청하고 다운로드할 때, ABR 서버(102)는 이 대역폭을 측정한다. 클라이언트들(108)은 사용자 또는 가입자의 집에 있으며, 가입자의 케이블 게이트웨이 ABR 서버(102B)로부터 WiFi 라우터(112)에 의해 구현되는 홈 WiFi 네트워크를 통해 컨텐츠를 검색할 수 있고, 또는 이들은 원격에 있으며, 홈 게이트웨이(102B) 또는 OTT ABR 에지 서버(102A)로부터 WiFi 핫스팟(106) 또는 LTE/3G 셀룰러 네트워크(116)를 통한 인터넷을 통해 컨텐츠를 검색할 수 있다. 트랜스코딩된 미디어 스트림들은 TCP/IP를 통해 HTTP를 사용하여 전달하기 위한 MPEG-2 전송 스트림들로서 캡슐화될 수 있다.
중요한 점은, 이하에서 설명되는 방법들 및 시스템들은 IP를 통해 미디어를 전달하기 위해 현재 사용되는 종래의 적응형 비트 레이트 방식들 및 표준들과 상이하다는 점이다. MPEG의 DASH(Dynamic Adaptive Streaming over HTTP), Apple의 HLS(HTTP Live Streaming), MSS(Microsoft Smooth Streaming) 또는 Adobe의 HDS(HTTP Dynamic Streaming)과 같은 프로토콜들 및 표준들은 통상적으로, 스트리밍 클라이언트에게, 그것이 사용가능한 수신되는 네트워크 대역폭을 측정하고 다중 비트 레이트 옵션들을 포함하는 마스터 플레이리스트 또는 매니페스트 파일로부터 적절한 비트 레이트의 미디어 스트림을 선택하라고 요청함으로써 클라이언트 측에서의 적응을 구현한다(HLS 용어에서는, 미디어 플레이리스트는 미디어 세그먼트들에 대한 어드레스들인 URI(uniform resource identifier)들의 리스트를 포함하지만, 마스터 플레이리스트는 미디어 플레이리스트들에 대한 어드레스들인 URI들을 포함한다). 이는 종종 미디어 프로그램에 대한 요청에 앞서, 미디어 자산에 대한 많은 비트 레이트 변형들을 생성하고 유지하는 스토리지 네트워크(104) 또는 게이트웨이(102B)를 필요로 한다. 이는 다수의 스트리밍 클라이언트들 간에 공유되어야 하는 트랜스코더 엔진(들)을 단 하나 또는 몇 개만 가질 수 있는 저비용 소비자 게이트웨이 디바이스들에 있어서는 비용/복잡성 부담으로 될 수 있다. 이하에서 설명되는 시스템들 및 방법들은 클라이언트 측에서 하는 제어 및 비트 레이트 결정의 일부 또는 전부를 제거하고, 이것을 개별적인 클라이언트 디바이스들이 사용가능한 대역폭에 맞는 미디어 스트림들의 JIT(just-in-time) 생성을 위해 서버측 상에 포지셔닝시킨다. 클라이언트 당 오직 하나의 트랜스코더 인스턴스만이 필요하며, 또한 주어진 미디어 자산의 여러 변형들에 대한 서버측 스토리지가 모든 JIT 적응형 스트림들을 만들 수 있는 단지 하나의 변형만을 저장할 필요성으로 대체된다.
청크 파일들로 HTTP를 통해 전달되는 미디어(예를 들어, HLS)에 대한 서버측 적응의 이전의 구현은 2015년 6월 25일자로 출원된 Mark S. Schmidt, Praveen N Moorthy, Ajay Luthra, 및 Paul Moroney에 의한 "SERVER SIDE ADAPTIVE BIT RATE CONTROL FOR HTTP STREAMING CLIENTS"라는 제목의 관련 미국 특허 출원 제14/750,097호에 개시되어 있으며, 이는 2014년 6월 26일자로 출원된 Mark S. Schmidt, Praveen N Moorthy, Ajay Luthra, 및 Paul Moroney에 의한 "SERVER-SIDE ADAPTIVE BIT RATE CONTROL FOR HTTP STREAMING CLIENTS"라는 제목의 미국 가특허 출원 제62/017,380호의 이익을 주장하며, 위의 출원들 모두는 본 명세서에 참조로 포함된다. 본 명세서에서 설명되는 구현은 HTTP를 통한 DLNA 컨텐츠의 연속적인 스트리밍에 적용된다.
본 개시내용은 또한 TCP/IP를 통해 클라이언트에게 전송하고 트랜스코더 제어를 수행하는 게이트웨이 서버에 의해 DLNA 미디어 스트림의 대역폭/스루풋의 측정을 수행하기 위한 다수의 상이한 알고리즘들에 대한 개발, 분석, 테스트 및 절충들을 설명한다. 서버측 ABR 제어 알고리즘 및 제어 알고리즘 실시예에 후보 측정 알고리즘을 통합하는 것도 제공된다.
도 2는 예시적인 DLNA ABR 서버(202) 및 클라이언트 시스템(204)을 포함하는 데이터 스트리밍 시스템(100)의 예시적인 구현의 도면이다. 이 예시적인 구현은 DLNA 프로토콜을 지향하지만(DLNA 호환가능 커맨드들 및 메시지들이 도시됨), 커맨드들 및 메시지들의 아키텍처 및 실질적인 정보 컨텐츠는 HLS, DASH, MSS 또는 HDS와 같은 다른 프로토콜들, 또는 클라이언트 프록시들이 연속적인 미디어 스트림을 청크 파일 포맷들로 변환하는 임의의 프로토콜에도 적용될 수 있다.
도시된 실시예에서, ABR 서버(202)는 대역폭 측정 모듈(217)을 포함하는 컨텐츠 서버(216), 트랜스코더 레이트/해상도 제어기(218), 트랜스코더/미디어 스트림 생성기(220) 및 하나 이상의 컨텐츠 소스들(튜너(222) 또는 DVR 등)을 포함한다. 트랜스코더/미디어 스트림 생성기(220)는 비디오 트랜스코더(221V) 및/또는 오디오 트랜스코더(221A)를 포함할 수 있는 해당 미디어 트랜스코더(221)(이하, 대안적으로 트랜스코더(221)라고 지칭함)를 포함할 수 있다.
DLNA 프로토콜을 사용하는 예시된 실시예에서, 클라이언트(204)는 DLNA 스트리밍 클라이언트 플레이어 애플리케이션을 구현하는 ANDROID 스마트폰 또는 태블릿일 수 있다. 대안적으로는, APPLE의 IOS AVPLAYER를 실행하는 IPAD 또는 IPHONE이 사용될 수 있지만, 연속적인 DLNA HTTP 미디어 스트림을 프록시하고 APPLE의 HLS 포맷으로 변환하는 애플리케이션이 필요하다. ABR 서버(202)가 MSO 컨텐츠 피드(225)에 접속되어, 튜너(222)가 MSO 컨텐츠 피드(225)의 원하는 미디어 채널에 튜닝되도록 명령될 수 있다. 튜너(222)는 위성 또는 케이블 튜너일 수 있고, 또는 전화 회사(TELCO) 제공자의 경우에는, IP 멀티캐스트 조인 기능을 지원하는 디바이스일 수 있다. 튜너(222)에 의해 수신되는 컨텐츠는 라이브로 트랜스코딩될 수 있고, 또는 나중의 트랜스코딩을 위해 DVR과 같은 레코딩 디바이스에 레코딩될 수 있다. 컨텐츠는 또한 트랜스코딩되어, 레코딩 디바이스 상에 저장될 수 있다. ABR 서버(202) 및 클라이언트는 도 2에 도시된 바와 같이 상호작용하여, 데이터 스트림들의 ABR 전달을 제공한다.
단계 1a에서, 클라이언트(204) 상에서 실행되는 클라이언트 플레이어 애플리케이션(206)의 컨텐츠 재생 관리 모듈(208)은 ABR 서버(202)의 컨텐츠 전달 서비스에게 컨텐츠 리스트에 대한 요청을 송신한다. 컨텐츠 리스트는 (도시된 바와 같이) 영화, 축구 게임, TV 쇼, 또는 MSO 컨텐츠 피드의 라이브 텔레비전 채널, 예를 들어, 채널 5를 포함할 수 있다. 일 실시예에서, 클라이언트(204)는 채널 맵의 형태로 사용가능한 컨텐츠의 리스트, 또는 HTTP "GET" 커맨드/기능을 사용하여 ABR 서버(202)의 컨텐츠 관리 서비스로부터 레코딩된 컨텐츠 전송을 검색한다.
단계 1b에서, ABR 서버(202)의 클라이언트 디렉토리 서비스(214)는 클라이언트(204)에게 컨텐츠 리스트를 리턴할 수 있다. 일 실시예에서, 컨텐츠 리스트는 XML 파일을 포함한다. 클라이언트(204)는 컨텐츠 리스트를 수신하고, 클라이언트 플레이어 애플리케이션(206)의 컨텐츠 재생 관리 모듈(208)은 클라이언트 디바이스(204)의 사용자에게 프리젠테이션하기 위해 컨텐츠 리스트 내의 정보를 프로세싱 및 포맷하여, 이에 의해 어떤 미디어 자산이 사용가능한지를 사용자에게 알린다.
단계 2a에서, 사용자는 클라이언트 디바이스(204)를 사용하여 컨텐츠 리스트 내의 미디어 자산들 중 하나의 미디어 자산(예를 들어, 라이브 채널 자산 "채널 5(영화)")을 선택하고, (예를 들어, GET 요청을 송신함으로써) ABR 서버(202)로부터 선택된 미디어 자산으로부터 연관된 컨텐츠 URI를 요청한다. 미디어 자산들 각각은 재생에 필요한 플레이 리스트와 고유하게 연관된다. 이하에서 추가로 설명되는 예에서, 사용자는 플레이 리스트의 파일 이름 "xMovie.ts"와 연관되는 영화 미디어 자산을 선택했다.
단계 2b에서, GET 요청의 수신은 ABR 서버(202)가 채널 튜너(222)를 튜닝하도록 트리거하여, 요청된 채널(채널 5)로 튜닝시킨다.
단계 2c에서, ABR 서버(202)는 컨텐츠 스트리밍 세션 URI를 생성한다. 컨텐츠 스트리밍 세션 URI는 클라이언트(204)에게 리턴된다. 이 예에서, 컨텐츠 미디어 파일 URI는 "xMovie.ts"로 명명된다.
단계 3에서, 클라이언트(204)는 재생을 위한 타겟으로서 xMovie.tx URI를 갖고 적절한 클라이언트 미디어 플레이어 애플리케이션(206)을 인스턴스화한다. 클라이언트 미디어 플레이어(210)는 단일 또는 복수의 아이템들을 재생하기 위한 제어기들 및 사용자 인터페이스를 구현하는 데 사용할 수 있도록 클라이언트(204) 운영 체제에 의해 정의되는 객체일 수 있다.
단계 4에서, 미디어 플레이어(210)는 선택된 데이터 자산에 대한 요청을 ABR 서버(202)에게 송신한다. 일 실시예에서, 이것은 자산("xMovie.ts")에 대한 HTTP GET 요청을 ABR 서버(202)로 송신함으로써 구현된다.
URI GET 요청의 수신은 미디어 스트림 생성기 모듈(220)에서 트랜스코딩 세션의 시작을 트리거한다. 라이브 튜너(222) 소스 미디어 스트림은 (파선으로 도시된 바와 같이) 트랜스코더(221)에 집적 전송되어 트랜스코더 입력 버퍼(230)에 제공될 수 있거나, 또는 단계 5a에 도시된 바와 같이, 라이브 오프 디스크(Live-Off-Disk)(LOD) 기능을 위해 하드 디스크 드라이브(HDD)(224)에 먼저 기입된 후, 트랜스코더 입력 버퍼(230)에 제공될 수 있다. 후자의 경우, 단계 5b에 도시된 바와 같이, 소스 컨텐츠는 그 후 LOD 메모리(224)로부터 트랜스코더(221)로 라우팅된다.
클라이언트(204)에 대한 채널 대역폭 특성이 아직 공지되지 않은 경우, 비디오 트랜스코더(221V)는 초기에는 낮은 비트 레이트 및 해상도, 예를 들어, 384x216(수평x수직 픽셀) 해상도에서 500kbps를 생성하도록 구성되어야 한다. 대안적으로, 트랜스코더(221)는 클라이언트(204) 또는 다른 클라이언트(204)와의 이전의 세션으로부터의 설정들을 재사용할 수 있다. 오디오 트랜스코더(221A)는 고정된 포맷 및 비트 레이트(예를 들어, 64kbps에서의 고효율 AAC)로 설정될 수 있다. 단계 5c에 도시된 바와 같이, 트랜스코더(221) 출력은 미디어 서버(216)로 전송되어, 클라이언트(204)로의 전달을 위해 TCP 소켓 인터페이스로 파이프된다.
단계 4의 "xMovie.ts GET " 요청을 수신하면, 컨텐츠 미디어 서버 및 대역폭 측정 모듈(216)은 클라이언트(204)에 대한 미디어 전달에 사용될 TCP 소켓 상의 대역폭(BW) 측정 기능을 초기화한다. 이 측정은 특정 클라이언트(204)에 대한 자산 xMovie.ts의 트랜스코딩과 연관된 미디어 세션 ID에 의해 식별될 것이다. 미디어 스트림 생성기(220)가 N개의 소스 입력들로부터 최대 N개의 동시 트랜스코딩된 출력들을 생성할 수 있는 경우, N개의 개별 미디어 클라이언트 플레이어들(204)에 대해 동시에 생성되는 최대 N개의 상이한 미디어 세션 ID들이 있을 수 있다.
단계 6에 도시된 바와 같이, 클라이언트(204)의 미디어 플레이어(210)는 TCP 접속을 통해 그 자신의 내부 TCP 소켓으로 전달되는 사용가능한 미디어를 검색한다. 애플리케이션은 검색된 미디어를 실시간으로 디코딩 및 렌더링하고/하거나, ABR 서버(202) 상의 LOD 피처에 의해 지원되는 일시 정지/탐색 기능을 구현할 수 있다.
단계 7a에서, xMovie.ts MPEG-2 전송 스트림이 ABR 서버(202) 상의 트랜스코더(221)에 의해 생성되어 TCP 접속을 통해 클라이언트(204)로 전달됨에 따라, BW 측정 모듈(217)은 (1) 특정 시간 인터벌들에서 소켓 버퍼에 남아있는 바이트들, (2) 데이터가 소켓 버퍼에 놓인 시간들 및 소켓 버퍼가 비어 있을 때, 또는 (3) 이하에서 더 설명되는 바와 같이 마지막 TCP ACK가 소켓에 의해 수신되었을 때와 같이, TCP 소켓 상태 쿼리로부터 보고되는 정보를 모니터링함으로써 네트워크를 통해 TCP 세그먼트들의 스루풋을 계산한다.
단계 7b에서, 트랜스코더 적응형 비트 레이트 및 해상도 제어 모듈(218)은, 자신이 BW 측정 모듈(217)로부터 수신하는 컨디셔닝된 또는 필터링된 대역폭 측정치들에 기초하여, 비디오 트랜스코더(221V) 비트 레이트 및/또는 해상도 커맨드들에 동적 변경들을 행한다.
일 실시예에서, 대역폭 측정의 필터링은 스퓨리어스 대역폭 측정값들을 거부하도록 수행된다. 통상적으로, 비트 레이트의 응답성 제어가 요구되는 경우, 그러한 필터링은 낮은 레이턴시로 수행되어야 한다. 예를 들어, 필터링된 BW 값들이 일시적으로 이전의 값들에서 갑자기 강하되는 경우(예를 들어, 채널 에러들로 인한 네트워크 혼잡 또는 PHY 계층 패킷 손실을 나타냄), 트랜스코더 비트 레이트가 감소될 것이다. 필터링된 대역폭 추정치들이 정의된 임계치 아래로 강하되면, ABR 서버(202)는 미디어 자산의 오디오 컴포넌트(오디오 트랜스코더(221A)에 의해 생성되며, 통상적으로 단지 64kbps의 최대 비트 레이트만을 필요로 함)만을 전달하도록 명령될 수 있다. 후속적으로 추정되는 BW 값들이 증가하여 충분한 시간 기간 또는 충분한 수의 청크들 동안 다른 임계치를 초과하여 남아있다면, 적응형 비트 레이트 및 해상도 제어기(218)는 트랜스코더 및 미디어 세그먼트 생성기(220)에게, 원하는 경우, 추정되는 BW 측정치들이 그것이 캡핑될 수 있는 상한 임계치에 접근하거나 이를 초과할 때까지, 시간적으로 후속하는 세그먼트들에서 점차적으로 추가로 증가될 수 있는 증가된 비트 레이트로 세그먼트들을 트랜스코딩하라고 명령할 수 있다.
단계들 6 및 7은 미디어 스트리밍 세션 및 클라이언트 재생 전체에 걸쳐 연속적으로 반복된다.
대역폭 측정
TCP/IP를 통해 전달되는 미디어 스트림의 스루풋, 굿풋 또는 대역폭(BW)(이 문헌에서 채널 용량을 설명하는 데 사용되는 모든 등가의 용어들)의 측정은 다수의 방법들로 수행될 수 있지만, 서버 애플리케이션의 미디어 생성 및 클라이언트 애플리케이션의 미디어 소비 구현에 크게 의존한다. ABR 서버(202)와 클라이언트(204) 사이의 TCP/IP 네트워크 채널 용량을 적시에 정확한 방식으로 측정하여, 클라이언트 애플리케이션 버퍼의 언더플로우 또는 오버플로우없이(전자의 경우에는 미디어 디코딩 및 프리젠테이션이 정지되게 되고, 후자의 경우에는 미디어 컨텐츠가 드롭되게 되어, 그에 따라 재생이 끊어지게 됨), 서버(202)의 미디어 생성 비트 레이트(트랜스코더(221) 비트 레이트)를 미디어 스트림의 전달을 허용하는 채널 용량에 적응시키는 것이 바람직하다.
본 명세서에서 고려되는 미디어 비트 스트림들은 비디오용의 MPEG-2, MPEG-4/AVC 또는 HEVC, 및 오디오용의 Dolby AC-3, AAC-LC 또는 HE-AACv1/v2와 같은 비디오 및 오디오 압축 알고리즘들을 사용하여 트랜스코딩되거나 인코딩된다. 그 결과, 기본 스트림들은 함께 멀티플렉싱되어, 클라이언트들(204)에게 전달하기 위해 MPEG-2 전송 스트림(transport stream)(TS)으로 캡슐화된다. 비디오 압축 알고리즘들은 레이트 제어 기능들을 사용하여 높은 비디오 품질의 가변 비트 레이트(variable bit rate)(VBR) 스트림들 또는 가변하는 비디오 품질의 고정 비트 레이트(constant bit rate)(CBR) 스트림들을 산출하도록 수행될 수 있다는 것이 널리 공지되어 있으며, 전자는 덜 제약된 네트워크들 또는 미디어 스토리지 시스템들(예를 들어, BLURAY 디스크)에 유용하고, 후자는 제약된 네트워크 전달(예를 들어, 고정된 레이트의 ADSL 전화 회선 인터넷 액세스)에 유용하다. 또한, 비디오 압축 알고리즘들은 비디오를 상이한 픽쳐 타입들, 즉, 인트라(I), 시간적으로 순방향 예측되는(P) 및 양방향으로(시간적으로 순방향 및 역방향으로) 예측되는(B) 픽쳐들로 코딩함으로써(일반적으로 코딩된 비트들이 I에서 P에서 B로 사이즈가 감소됨), 비트 레이트 감소에 대한 비디오 리던던시를 사용하기 위한 공간 및 시간 예측 방법들을 사용하는 것이 널리 공지되어 있다. 결과적으로, 트랜스코딩된 스트림의 전송 비트 레이트가 짧은 시간 스케일들(수십 내지 수백 밀리초)에 걸쳐 측정될 때 큰 변화들이 있을 수 있다.
도 3은 (예를 들어, 미디어 지속시간에서 각각 2초의 청크된 미디어 세그먼트들을 생성하는) HLS 프로토콜을 사용하여 전달되는 동일한 미디어 시퀀스의 비트 레이트 대 순간 미디어 또는 전송 비트 레이트의 차이를 도시한다. HLS 미디어 자산 파일들은 클라이언트(204)와 서버(202) 사이의 최대 스루풋을 10Mbps로 제한하도록 설정된 네트워크 경로 내의 레이트 성형 엘리먼트를 갖는 TPC/IP 네트워크를 통해 클라이언트에 의해 풀링되었다.
"2-sec 청크 전달 레이트"로 표시되어 있는 도 3의 플롯(302)은 10Mbps의 (최대) 네트워크 비트 레이트에서 2-sec 청크들이 클라이언트에 의해 풀링되었음을 도시한다. 이러한 청크들에 포함된 미디어는 VBR 레이트 제어를 사용하는 AVC 압축을 사용하여 640x360p30의 타겟 비디오 해상도와 1.7Mbps의 타겟 평균 비트 레이트에서 인코딩되었다. "전송 스트림 비트 레이트"로 표시되어 있는 플롯(304)은 실제 비트 레이트를 나타내며, (비디오 프레임 레이트와 매치되는) 1/30초마다 달성되는 MPEG-2 전송 비트 레이트를 도시한다. 도 3에 도시된 데이터는 I 픽쳐들 또는 장면-전환 P 픽쳐들과 같은 일부 픽쳐들이 10Mbps로 제한된 네트워크를 통해서는 순간적으로 전달될 수 없는 매우 높은 순간 비트 레이트들(최대 14Mbps)을 요구한다는 것을 예시한다. HLS 청크들 대신에 이러한 전송 스트림이 연속적인 방식으로 전달되었다면, 서버(202) 및 클라이언트(204)의 버퍼들이 순간 피크들을 흡수할 것이 요구되고, 클라이언트 애플리케이션(206)은 미디어 프리젠테이션 레이트에서 데이터를 풀링하였다. 전송 스트림 비트 레이트의 2초 슬라이딩 윈도우의 평균치 및 최대치 계산은 디스플레이된 2 내지 22초의 x-축 인터벌에 걸쳐 2.21Mbps의 평균치 및 4.570Mbps의 최대치를 산출한다. 링크는 일부 인터벌들(12-14sec, 20-22sec) 동안 더 높은 연속적인 전송 비트 레이트를 쉽게 지원할 수 있으며, 평균적으로 타겟 VBR 레이트를 쉽게 지원하는 것을 도 3으로부터 알 수 있다. 그러나, DLNA와 같이 연속적인 TCP/IP 스트리밍을 사용하고 "전송 스트림 비트 레이트" 곡선(304)에 의해 시뮬레이션되는 클라이언트-서버 시스템은, 몇몇 픽쳐 인터벌들의 시간 스케일 양자화에 대해 수행될 때, 미디어 비트 레이트만을 측정하고 채널 용량은 측정하지 않을 것이다. 따라서, 최대 사용가능한 대역폭을 초과하지 않으면서 사용가능한 대역폭을 활용하도록 트랜스코더 비트 레이트를 제어하는 방법을 결정하는 것이 어려울 수 있다.
다음 섹션들은 DLNA 애플리케이션에서 사용되는 연속적인 미디어 전송 스트림 전달을 위해 TCP/IP 채널 용량을 측정하기 위한 상이한 방법들을 제시한다.
DLNA
미디어 스트리밍을 위한 TCP 계층에서의 대역폭 측정
TCP 배경 및 종래 기술의 대역폭 추정
TCP 프로토콜은 다음을 사용하여 TCP 피어들 간에 신뢰성있고 에러가 없는 데이터 전달을 제공한다.
·전송되는 바이트들의 정렬된 시퀀스 번호들을 사용하여 전송 및 수신되는 데이터에 대한 확인응답(ACKnowledgment)
·손실된 데이터의 재송신(ACK가 수신되지 않음)
·수신기에서의 슬라이딩 수신 윈도우 버퍼를 사용하여, 전송기와 수신기 사이에서 인 플라이트(in flight) 중일 수 있는 바이트들의 수를 제한하는 흐름 제어
·혼잡 윈도우를 증가시키는 송신 왕복 시간(round-trip-time)(RTT) 및 ACK된 바이트들의 수/빈도의 측정을 사용하여 링크가 과부하되었을 때를 검출하는 전송기에서의 레이트 제한 혼잡 제어
2개의 기본 전송 모드, 즉, (1) 슬로우-스타트 및 (2) 혼잡 제어가 TCP 세션에서 발생한다.
슬로우-스타트 전송 모드에서, 전송기는 수신기에 의해 수신되는 각각의 ACK에 대해 데이터 세그먼트들(각각의 길이는 링크의 최대 세그먼트 사이즈(Maximum Segment Size)(MSS)까지임)의 수를 세그먼트들의 슬로우-스타트-임계치(slow-start-threshold)(SSThresh) 양까지 지수 함수적으로 증가시킨다. 전송이 허용되는 확인응답되지 않은 세그먼트들의 수를 혼잡 윈도우(congestion window)(CWND)라고 한다. 손실들이 감지되지 않으면, CWND가 SSThresh에 도달할 때, 프로토콜은 혼잡 회피(congestion-avoidance) 페이즈 또는 혼잡 제어 모드로 전환되며, 이 모드에서, 송신되는 세그먼트들의 수는 수신되는 각각의 ACK에 대한 RTT마다 단지 하나의 MSS만큼 증가한다. 세그먼트 손실이 검출될 때까지(어떠한 ACK도 수신되지 않으며, 이에 의해 ACK되지 않고 인 플라이트 중인 허용된 세그먼트들의 감소를 야기함) CWND의 증가가 발생한다. 혼잡 회피에 의하면 전송기에 의해 네트워크에 제공되는 로드가 느리게 증가하고, 결국 네트워크는 끊임없이 증가하는 로드를 수용할 수 없으며, 전송기로부터의 일부 패킷들을 드롭할 것이다. 이에 의해, 전송기 속도가 슬로우-스타트로의 리턴보다 덜 감소되는 TCP Tahoe 또는 Reno와 같은 TCP의 다른 수정 등에서 또는 풀 슬로우-스타트로 리턴하는 것을 통해, 감소된 전송기 레이트로 리턴한게 된다.
TCP 프로토콜 파라미터들 및 측정치들 중 일부는 tcp.h 헤더 파일에 선언된 tcp_info 데이터 구조 엘리먼트들을 다시 보고하는 시스템 호출들을 통해 통상적인 Linux 스택 구현들에서 사용가능하다.
예를 들어, CWND는 tcp_snd_cwnd로서 보고되고, RTT 추정치들은 tcpi_rtt로서 보고되고, tcpi_snd_mss는 전송기측 MSS를 제공한다. 파라미터들 tcpi_last_data_sent 및 tcpi_last_ack_recv는 또한 이하에 관련이 있다. tcpi_last_data_sent는 tcp_info를 판독하는 현재 호출로부터 마지막 TCP 세그먼트가 TCP 소켓 버퍼에서 수신기를 향해 전송된 시간까지의 시간 차를 제공하고, tcpi_last_ack_recv는 tcpinfo에 대한 현재 호출로부터 마지막 ACK가 수신기로부터 수신된 시간까지의 시간 차를 제공한다.
널리 공지된 TCP 스루풋 측정의 예는 Linux의 iproute2 ss 유틸리티에서 사용된다.
여기서의 가정은 TCP 전송기가 RTT 초마다 길이가 MSS 바이트인 CWND 세그먼트들을 릴리즈 중인 것이며, 즉, 혼잡 회피 시에, 전송기는 아직 확인응답되지는 않았지만 RTT 초 내에 ACK될 것으로 예상되는 인 플라이트 중인 CWND 세그먼트들을 가질 것이며, 이는 세그먼트들의 손실이 없는 것으로 가정된다. 예를 들어, 통상적인 이더넷 MSS = 1448byte인 경우, 현재 RTT 측정이 22msec인 동안에 CWND가 40개의 세그먼트들로 증가하였으면,
불행하게도, 실제 TCP 동작에서, 위의 식 (1)은 다음에 의해 유도되는 오버바운딩(overbounding)으로 인해 부정확한 것으로 알려졌다.
·고정된 MSS 사용(일부 또는 많은 송신 세그먼트들은 전체 MSS 바이트들을 포함할 수 없다).
·TCP가 CWND를 20 내지 50과 같은 큰 값들로 유도할 수는 있지만, 때로는 링크를 통해 CWND 확인응답되지 않은 세그먼트들을 전송하는 데 충분한 단위 시간당 전송기 데이터가 없을 것이라는 관찰
·RTT의 측정은 분산과 레이턴시를 갖는다.
이것이 도 4에 도시되며, 여기서 네트워크는 "스위치 캡" 곡선(402)에 도시된 최대치에서의 스루풋들만을 허용하기 위해 트래픽 레이트 성형 디바이스에 의해 제약된다. 전달되는 TCP 비트 레이트는 와이어샤크(Wireshark) 캡쳐 분석을 사용하여 측정된다. 플롯(404)("10msec 빈들에서의 와이어샤크 pcap 비트 레이트")은 스위치 캡 경계들에 근사하는 실제 트래픽을 보여준다. 플롯(406)("mss*cwnd* 8000/rtt")은 식 (1)에 따른 대역폭의 추정치가 플롯(402)에 도시된 네트워크 "스위치 캡" 한계를 상당히 초과하였음을 보여준다. 플롯(408)은 3-탭 중앙값 필터에 의해 필터링된 타이머 기반 대역폭을 도시한다.
이 문제를 개선하기 위해, 새로운 대역폭 추정 패러다임들이 탐구되었다. 이러한 새로운 대역폭 추정 기술들은 식 (1)의 것보다 더 정확한 결과들을 산출하며, 트랜스코더(221) 출력 비트 레이트를 적시에 업데이트하여 네트워크 용량에 매치시킬 수 있도록 시간적으로 짧은 인터벌들에 대해 행해질 수 있다.
다음 섹션들은 DLNA 미디어 스트리밍에 적용 가능하도록 설계 및 테스트된 스루풋(대역폭) 측정 알고리즘들에 대해 설명하며, 이 알고리즘은 이하에 기초한다.
·tcpi_snd_cwnd 및 tcpi_rtt와 같은 tcp_info 파라미터들 검사(이하, "TCPInfo 알고리즘"이라고 함).
·위에서 기술된 관련 미국 특허 출원 제14/750,097호 및 미국 가특허 출원 제62/017,380호에 기술된 청크된 미디어 파일들에 적용된 libpcap을 사용한 TCP ACK 기반 측정. 이하, 이 알고리즘은 "Libpcap 알고리즘"이라고 명명된다.
·도 3의 HLS 예와 유사한 TCP 소켓에 릴리즈하기 전에, 애플리케이션 계층에서 전송기 데이터를 더 큰 블록들로 그룹화함(이하, "번칭 알고리즘(Bunching Algorithm)"이라 함).
·주기적인 타이머 만료들을 사용하여, 전송된 소켓 바이트들의 수 및 남아있는 소켓 바이트들의 수의 검사를 트리거함(이하, "타이머 기반 알고리즘"이라고 함).
·tcpi_last_ack_recv를 사용하여, 전송된 소켓 바이트들 및 남아있는 소켓 바이트들(이하 "Last_ACK_Recv 알고리즘"이라고 함).
측정 알고리즘을 상세하게 설명하기 전에, 대역폭 측정들이 이루어진 제약조건들을을 이해하기 위해 게이트웨이 DLNA 스트리밍 구현의 간략한 설명이 제공된다.
게이트웨이 DLNA 트랜스코딩 및 TCP 스트리밍 구현
도 2의 블록도에 도시된 게이트웨이 ABR 서버(202)는 트랜스코더 및 미디어 스트림 생성기(220)에 직접 인터페이싱하는 튜너(222) 및 하드 디스크 드라이브(224)를 도시한다. 이것은 연속적인 MPEG-2 전송 스트림 플로우의 바이트들이 트랜스코더(221)로 흘러가고 TCP 소켓으로 되돌아가는 것을 제안할 수 있다. 실제 구현에서, 트랜스코더(221)는 트랜스코더로 들어가는 데이터 및 트랜스코더를 떠나는 트랜스코딩된 데이터 모두를 버퍼링하는 입력 및 출력 버퍼들을 모두 포함한다. 이들 버퍼들은 (예를 들어, 암호화를 위해) 스트림을 프로세싱하는 데 사용되는 서버(202)의 CPU에 대한 로드를 감소시킨다. 이러한 버퍼들은 입력 및 출력 미디어 스트림 비트 레이트들에서 채워지며, 오버플로우를 방지하기 위해 주기적으로 비워져야 한다.
이하 설명되는 실시예들에서는, 120msec 인터벌들에서 만료되는 "AFTimer"로 명명되는 타이머가 소프트웨어 엘리먼트들에게 "recpump"로 명명되는 트랜스코더 출력 버퍼가 데이터를 갖고 있고 서버(216)에 의한 프로세싱을 위해 비워질 수 있다고 통지하는 데 사용된다. ABR 측정 및 제어 알고리즘의 경우, AFTimer 인터벌은 또한 비디오 트랜스코더(221V)에 의해 수행되는 트랜스코딩의 레이트 및 해상도 변경에 관한 스루풋 측정들 및 결정들을 하기 위한 통지 인터벌로서의 역할을 한다.
이 I/O 버퍼링 방식은 Linux TCP 스택에게, 그리고 그에 따라 클라이언트(204)에게 전달되는 트랜스코딩된 DLNA 스트림에 짧은 인터벌(120msec) 버스티니스(burstiness)를 부여하는 결과를 갖는다. 이 버스티니스는 미디어 세그먼트들이 때로는 지속시간이 2 내지 10sec인 HLS 또는 DASH에서 사용되는 것과 호환가능하지 않다. 120msec는 30fps에서 데이터의 약 4개의 비디오 프레임들과 같기 때문에, 이 짧은 인터벌은 여전히 미디어 비트 레이트에 밀접하게 따르는 TCP 스트림을 생성하며, 도 3의 HLS 청크 전달과 유사하지 않다.
게이트웨이 ABR 서버(202)와 클라이언트(204) 사이에서의 낮은 비트 레이트 미디어 스트림들 및 고용량 네트워크들의 경우, 트랜스코더 출력 버퍼(recpump)의 데이터가 프로세싱되어, AFTimer 만료들 사이에 TCP 네트워크를 통해 전달될 수 있다는 것이 종종 관찰된다. 즉, 120msec 내에 트랜스코더에 의해 출력 버퍼(recpump)로 전달되는 데이터의 양을 전송하는 데 120msec 미만이 걸린다. 네트워크 또는 통신 채널이 혼잡하거나 손실되면, 출력 버퍼(recpump) 데이터를 클라이언트에게 전달하기 위해 하나의 AFTimer 인터벌보다 길게 취할 수 있고, 출력 버퍼(recpump)는 트랜스코더(221)로부터의 새로운 미디어 데이터로 추가로 채워진다. 이들 두 가지 관찰들은 이하에서 구현되고 설명되는 측정 알고리즘들에서 광범위하게 사용된다.
TCPInfo
알고리즘
게이트웨이 서버(202) 상의 Linux TCP 스택이 CWND(tcp_snd_cwnd) 및 RTT(tcpi_rtt)와 같은 TCP 프로토콜 파라미터들 중 일부를 노출하기 때문에, 이들 변수들을 분석 또는 모니터링함으로써, TCP 스루풋에 관한 정보가 추론될 수 있다고 추측되었다. 예를 들어, 링크의 스루풋이 높으면, 혼잡 윈도우(tcp_snd_cwnd에 의해 결정됨)가 클 것으로 예상될 수 있고, 이것이 낮았다면, 이는 혼잡으로 인한 것일 수 있고, 결과적으로 재송신에 의해 tcpi_rtt가 커지게 하고 tcp_snd_cwnd가 작아지게 한다. 따라서, 이들 파라미터들에서 리턴된 값들에 기초하여, 트랜스코더 비트 레이트가 위 또는 아래로 구동될 수 있다.
테스트는, 주어진 포트에서의 최대 데이터 스루풋(비트 레이트)을 동적으로 제한하기 위해 포트 레이트 성형을 가능하게 하는 이더넷 스위치를 통해 스트림을 통과시킴으로써, 게이트웨이 서버(202)와 iPad WiFi 클라이언트(204) 사이의 DLNA 미디어 스트리밍 링크에 스트레스를 주도록 행해졌다. 게이트웨이(202) DLNA 소켓 전송기 소프트웨어는 tcp_info 구조의 데이터를 리턴한 LINUX getsockopt 호출을 통해 소켓 정보를 획득하도록 수정되었다.
도 5는 동적으로 변하는 스위치 레이트 캡에 대해 플롯화된 TCP 정보 파라미터들을 포함하는 결과를 도시하는 도면으로서, 여기서는 TCP 링크가 레이트 제한되고 스트레스를 받았을 때 파라미터들이 어떻게 행동하였는지를 알기 위해, 링크 스루풋이 연속적인 단계들로 낮아진다. 플롯(512)("측정된 비디오 비트 레이트")은 연속적인 133msec 인터벌들(또는 30fps에서 4개의 비디오 프레임들)에 걸친 평균을 사용하여 측정된 오디오/비디오(A/V) DLNA 스트림의 미디어 전송 스트림 비트 레이트를 나타낸다. 비디오 해상도는 384x216p30이었고, 스트림의 전체적인 TS 비트 레이트는 900kbps를 타겟으로 하였다. 플롯(510)("측정된 TCP 비트 레이트")은 레이트 성형 스위치를 통해 클라이언트 디바이스로 전달되는 DLNA 비트 레이트의 3-탭 중앙값 필터링된 측정치를 도시한다.
필터링 전의 각각의 측정은 전술한 120msec AF timer 인터벌에서 이루어진다. 플롯(502)("스위치 캡")은 이더넷 스위치의 포트 성형 기능에 의해 링크를 통해 허용되는 최대 비트 레이트를 도시한다. 레이트 캡은 일련의 단계들에서 테스트 시작시의 5Mbps로부터 500kbps로 낮아졌다. 전송을 위해 제공되는 스트리밍 미디어(900kbps)의 로드가 레이트 캡을 초과할 때, "측정된 TCP 비트 레이트"(플롯(510))가 500kbps에서의 레이트 캡과 동일해지는 것을 알 수 있다. 그 포인트에서는, 미디어가 자신의 생성 레이트로 전달되고 있지 않았기 때문에, 클라이언트가 재생하는 동안, A/V 프리젠테이션이 정지되고 끊어졌다.
도 5의 플롯(506)은 TCP 세그먼트들에서의 슬로우-스타트 임계치를 도시하고, 플롯(508)은 세그먼트들에서의 CWND를 도시하고(둘 다 그래프에 맞추기 위해 100만큼 스케일링됨), 플롯(504)은 게이트웨이(202) Linux TCP 스택에 의한 tcp_info 구조에서 보고된 바와 같이 TCP RTT(수백μsec로 표현되도록 스케일링됨) 모두를 도시한다.
TCP 파라미터들 중 일부는 TCP 스루풋 또는 링크 스트레스의 지시들로서 유용할 수 있다. 예를 들어, 스위치 레이트 캡이 감소함에 따라 TCP RTT(플롯(504))가 명확히 증가하여, 오버로드된 네트워크를 통해 클라이언트(204)들에게 전달함에 있어서 세그먼트들이 지연되고 있음을 지시한다. 그러나, 네트워크 용량이 감소함에 따라, CWND(플롯(508))는 실제로 증가한다. 예를 들어, 스위치 캡(플롯(502))이 500kbps일 때, CWND는 20xMSS = 20x1448byte이고, RTT ~ 50msec이다. 이들 값들을 식 1에 적용하면, 또다시 실제 스루풋의 정확한 추정치가 아닌 4.63Mbps의 스루풋 추정치가 산출될 것이다. 마지막 관찰은 SSThd가 CWND와 양호하게 상관되는 것으로 보인다는 것이다.
Libpcap 알고리즘
"Libpcap" 스루풋 측정 알고리즘은 기본적으로 클라이언트에 의해 게이트웨이 ABR 서버(202)의 TCP 스택으로 리턴되는 TCP ACK 메시지들 사이의 시간 인터벌을 측정한다. 두 ACK 메시지들 사이의 시퀀스 번호들의 차이는 통상적으로 성공적으로 전송된 바이트들의 수이므로, "Libpcap"이 수신된 ACK 메시지들에 놓이는 로컬 시간 스탬프들(local timestamps)과 함께, 네트워크 스루풋이 추정될 수 있다.
이는, 일련의 미디어 파일들이 네트워크 용량에서 다운로드되고, 각각의 다운로드동안에 Libpcap이 이러한 용량을 측정할 수 있는 HLS "청크" 포맷으로 전달되는 미디어에 대해 양호하게 동작한다. 그러나, DLNA 스트리밍 실시예에서는, 앞서 도 3에서 설명한 바와 같이, ACK 기반 추정치들은 채널 용량 대신에 미디어 비트 레이트의 추정치를 유도할 수 있다. 이는 Libpcap 방법이 ACK 메시지들 사이의 시간 델타의 샘플링 인터벌(예를 들어, 100 또는 250msec)을 사용했기 때문에 발생한다. 이전에 언급한 바와 같이, 트랜스코더 출력 버퍼(recpump)로부터의 데이터가 높은 네트워크 용량들에 대한 AFTimer 인터벌 내에서 양호하게 전달되는 경우가 종종 있다. 따라서, ACK 메시지들 사이에서 libpcap 측정된 시간 델타들은 서버(202)로부터 클라이언트(204)로의 TCP 접속을 통해 어떠한 데이터도 전이되고 있지 않는 큰(최대 120msec) 데드 타임과 오버랩될 수 있다. 이것은 libpcap 측정치들을, 채널 용량 또는 스루풋이 아닌 미디어 스트림 비트 레이트에 근사하는 값으로 평균화하는 효과를 가져온다.
libpcap 알고리즘이 게이트웨이 서버(202)에서 DLNA 스트리밍 구현에 의해 동작하기 위해서는 수정이 필요하다. 일 실시예에서, 이것은 각각의 TCP 세그먼트가 게이트웨이 ABR 서버(202)의 TCP 스택을 떠날 때 각각의 TCP 세그먼트의 시퀀스 번호를 검출(필터링) 및 시간 스탬핑(timestamping)하고, 그 세그먼트에 대응하여 클라이언트(204)로부터 수신되는 ACK 메시지를 검출(필터링) 및 시간 스탬핑한 후, 스루풋 계산을 하기 전에 경과 시간들 및 전송된 바이트들의 수들을 누적(accumulating)함으로써 달성될 수 있다.
예를 들어, SN 0 는 측정의 시작시에 전송되는 바이트들의 초기 시퀀스 번호를 나타내고, SN f 는 측정의 최종 시퀀스 번호를 나타내고, ΔT SN(i) 는 i번째 세그먼트에 대한 ACK가 수신될 때와 SN i 가 전송기를 떠날 때의 시간으로부터의 시간 차를 나타내는 경우, 대역폭 BW는 아래의 식 (2)에 따라 추정될 수 있다
번칭
알고리즘
"번칭(bunching)" 알고리즘은 전술한 통상적인 DLNA 미디어 전송에서의 연속적인 스트리밍을 HLS 및 DASH와 유사한 버스티(bursty) 전달 메커니즘으로 변경한다. 주어진 시간의 지속시간 동안 또는 특정 사이즈의 미디어가 누적된 때까지 트랜스폰더 출력 버퍼(recpump) 데이터를 유지하고, 그 후 한 "번치(bunch)"의 이 데이터를 서버(202)의 TCP 소켓으로 릴리즈함으로써, 데이터가 도 3의 "2-sec 청크 전달 레이트" 곡선(302)과 유사한 방식으로 네트워크 채널 용량에서 흐를 수 있다.
번칭 알고리즘은 번치 데이터(bunched data)의 버스트가 게이트웨이 TCP(202)의 전송 소켓 버퍼(238b)로부터 비워진 후에 대역폭 또는 스루풋을 측정한다. 이 알고리즘은 다음과 같이 진행한다.
·120msec의 AFTimer recpump 통지 인터벌마다, 번칭 알고리즘은 시그널링된 트랜스폰더 출력 버퍼(232)(recpump) 데이터 블록 상당의 바이트들을 번칭 버퍼(234)에 누적한다. 이 값이 임계치, 예를 들어, 128Kbyte(131072byte)를 초과하면, 알고리즘은 데이터의 번칭 버퍼(234)를 TCP 전송 소켓(238)으로 릴리즈한다. 이것은 어떠한 새로운 데이터도 소켓(238)으로 릴리즈되지 않는 누적을 위한 다수의 120msec 타이머 인터벌들을 취할 수 있다는 것에 주목한다. 또한, 번칭 알고리즘은 데이터를 트랜스코더 출력 버퍼(232)로부터 번칭용 특수 버퍼(234)로 이동시킬 때 큰 CPU 로딩을 부여한다는 것에도 주목한다.
·번치 데이터가 소켓으로 릴리즈된 후, 소켓 버퍼(238)에 남아있는 바이트들(bytesRemaining)을 리턴하는 후속 AFTimer 인터벌마다 Linux ioctl 호출(SIOCOUTQ)이 행해진다. bytesRemaining = 0인 경우, TCP 소켓 버퍼(238)는 비어 있고, 모든 TCP 세그먼트들은 TCP 수신 클라이언트(204)로 송신되었다(그러나,수신 클라이언트(204)에 의해 송신되는 ACK 메시지에 의해 아직 확인응답되지 않았을 수 있다). 즉, 송신된 세그먼트들은 인 플라이트 중일 수도 있고, 손실되었을 수도 있으며, 안정적인 수신을 위해 재송신이 필요할 수도 있다.
·SIOCOUTQ 호출이 이루어져 bytesRemaining = 0이 되는 시간이 Linux 시스템 시간 호출에 의해 Tf로서 결정될 수 있다. 이 시간은 TAF = 120msec의 트랜스코더 출력 버퍼(232)(recpump) AFTimer 인터벌의 배수와 동일한데, 왜냐하면 알고리즘이 이들 인터벌들 상에서만 호출되기 때문이다. 128kByte 데이터 번치가 소켓으로 전달된 시간을 T0로 표시할 수 있다. 그리고, 128KByte 데이터 번치의 마지막 TCP 세그먼트가 소켓을 통해 클라이언트로 전송된 시점의 추정치는 다음과 같다.
ΔT는 TAF 값들로 양자화되므로, 대역폭 추정에 에러가 있을 것이라는 점에 주목한다. 예를 들어, 마지막 TCP 세그먼트가 AFTimer 통지를 하고 5msec 후에 전달된 경우, 알고리즘이 다시 호출될 때, 다음 AFTimer 통지 인터벌에서 115msec가 경과할 때까지, bytesRemaining = 0이 검출되지 않을 것이다. 이로 인해 DT에서 115msec의 에러가 발생한다.
·elapsedTime 측정을 향상시키기 위한 시도로 tcp_info 변수 tcpi_last_data_sent가 또한 여기서 시험 측정 알고리즘들 중 하나에서 사용되었다. 이 변수는 호출이 이루어진 시점부터 마지막 TCP 데이터 세그먼트가 TCP 전송 소켓 버퍼(238b)로부터 전송된 시점까지의 시간 델타를 리턴한다. Tf가 다시 TAF = 120msec의 recpump AFTimer 인터벌의 배수와 동일함에 따라, 호출이 이루어지는 시간은 Linux 시스템 시간 호출에 의해 결정될 수 있다. 그리고, 128kByte 데이터 번치의 마지막 TCP 세그먼트가 소켓을 통해 클라이언트로 전송된 시점의 추정치는 다음과 같다.
여기서, 마지막 TCP 세그먼트가 AFTimer 통지를 하고 5msec 후에 전달된 경우, 다음 AFTimer 통지는 bytesRemaining = 0 및 tcpi_last_data_sent = 115msec을 산출할 것이다. 결과적으로, DT 계산은 이제 128kByte의 데이터를 전송하는 시간을 보다 정확하게 반영할 것이다.
·대안적으로, bytesRemaining이 0이 된 시간은 SIOCOUTQ 함수의 알고리즘에 의한 빠른 폴링에 의해 결정될 수 있다는 것에 주목한다. 이것은 CPU 사용률을 증가시키긴 하지만, 이하에서 설명되는 바와 같이, 상이한 BW 측정 구현에서 연구된다.
·그 후, 이하의 식을 사용하여, AFTimer 통지 인터벌에서 bytesRemaining = 0일 때, 스루풋에 대한 계산이 행해진다.
표 I은 식 (3)의 시간 양자화로 인해 BW 계산에 미치는 영향을 보여주며, 여기서 elapsedTime은 120msec 퀀텀들로 측정되고 계산된다. 식 (5)의 계산을 N = 131072, 65536 및 32768byte의 상이한 번치 사이즈들, 및 가능한 bytesRemaining = 0에 의해 관심있는 BW 값들로 되는 AFTimer 인터벌들의 상이한 번호들에 대해 나타냈다.
보다 작은 번치 사이즈들의 경우에는, 하나의 AFTimer 인터벌에서 모든 번치 데이터 바이트들이 소켓을 떠나는 높은 네트워크 스루풋에 의해 N = 131072, 65536 및 32768byte에 대해 각각 8.738Mbps, 4.369Mbps 및 2.184Mbps의 최대 BW 값들을 야기한다는 것에 주목한다. 따라서, 참인 네트워크 BW가 이 값들을 초과하면, 알고리즘은 매우 낮은 측정치들을 리턴할 것이다. 반대로, 네트워크 대역폭이 매우 낮으면(예를 들어, 500kbps), 네트워크를 통해 N=131072byte를 전달하는 데 2sec를 초과하는 시간이 걸릴 것이다. 따라서, BW 측정은 완료하는 데 2sec를 초과하는 시간이 걸릴 것이고, 트랜스코더 비트 레이트 제어 알고리즘은 출력을 네트워크 BW에 적합한 레이트로 수정하기 전에 긴 지연을 가질 것이다. 따라서, 번치 데이터 사이즈 N의 고정된 값은 트랜스코더 비트레이트 피드백 제어에 문제가 될 수 있다.
표 II는 주어진 비트 레이트에서 MPEG-2 전송 스트림에 대해 N byte가 생성되는 데 걸리는 시간을 나타낸다. 이것은 실시간 번칭 인터벌들을 결정할 것이다. 예를 들어, 864kbps에서, 실시간 트랜스코더가 131072byte의 번치 데이터 블록을 생성하는 데 1.214sec가 걸린다. 이것은 생성 측에서 최소 알고리즘 업데이트 인터벌을 결정할 것이다.
식 (4)에 기초한 ΔT 측정치는 여전히 약간의 부정확한 점들이 있긴 하지만 더 양호한 BW 추정치들을 산출하였다. 테스트는 집계 평균 TS 비트 레이트가 약 900kbps인 384x216p30 VBR AVC 비디오 플러스 128kbps AAC-LC 오디오를 사용하여 수행되었다. DLNA 스트림은 제약없는 WiFi 네트워크를 통해 전송되었으며, 식들 (3), (4) 및 (5)를 사용한 측정치들이 클라이언트(204)로부터의 TCP ACK 메시지를 사용하여 TCP/IP 데이터 스트림의 와이어샤크 네트워크 캡처로부터 계산되는 실제 데이터 스루풋에 대해 플롯화되었다.
도 6은 스트리밍의 처음 30sec 동안의 상기 연구의 결과들을 4개의 비디오 프레임 인터벌들(120msec의 AFTimer 인터벌에 가까운 ~ 133msec)에 걸쳐 측정된 TS 비트 레이트와 함께 도시하는 도면이다. 표 II에 의해 명시된 바와 같이, 낮은 비디오 생성 레이트 및 높은 비디오 생성 레이트의 효과는 측정들 사이의 인터벌들에서 알 수 있다. 스트리밍의 처음 6sec 내의 낮은 TS 비트 레이트들(250-500kbps)에서는, 측정들 사이의 인터벌들이 길고, 대략 2-3sec이다. 상위 TS 비트 레이트들에서는, 측정들이 좀더 빈번하게 발생한다.
플롯(604)("tcp_last_data_sent를 무시하는 번치 비트 레이트 계산")은 120msec AFTimer 인터벌들에 대한 식 (3)의 ΔT 추정치의 적용으로부터 나온다. 플롯(608)("번치 비트 레이트 계산")은 tcpi_last_data_sent 시간을 고려한 식 (4)의 ΔT를 사용하여 이루어진다. 일반적으로, 플롯(608)에 의해 표현되는 "번치 비트 레이트 계산" 방법은 "128k 다운로드에 걸친 pcap 비트 레이트" 곡선(606)의 참인 대역폭 값을 약간 과대 추정하지만, "tcpi_last_data_sent를 무시하는 번치 비트 레이트" 곡선(604)보다는 더 가깝다. 후자의 곡선이 예상대로 표 I의 양자화된 값들을 취하는 것을 알 수 있다. "번치 비트 레이트 계산" 곡선(608)의 과대 추정은 tcpi_last_data_sent 파라미터가 판독될 때 전송되는 마지막 데이터 세그먼트들을 클라이언트(204)가 실제로 수신한 시점 및 실제로 수신했는지 여부에 대한 지식의 부족으로부터 기인할 수 있는데, 왜냐하면 와이어샤크 기반의 계산들이 클라이언트(204)로부터의 실제 ACK 응답을 사용하여 DT를 계산하기 때문이다.
번칭 알고리즘의 효력은 측정 인터벌들의 가변성, 및 번치 데이터를 이동시키고 버퍼링하는 데 필요한 CPU 로딩으로 인해 제한된다.
타이머 기반 알고리즘
이전의 알고리즘 설계에서는, 120msec의 고정된 AFTimer 인터벌들 및/또는 tcp_info 파라미터 tcpi_last_data_sent를 사용하여, 게이트웨이의 TCP 전송 소켓 버퍼(238b)가 비워진 시간의 측정이 연구되었다. 이들 메커니즘들은 다른 트랜스코더 출력 버퍼(232)(recpump) 동작들이 더 빈번하지 않게 수행될 때에만 동작들을 수행함으로써 게이트웨이 서버(202) CPU 사용 영향을 최소화하려고 시도하였다. 아래에서 설명되는 타이머 기반 알고리즘은 예를 들어, TTB = 10msec 인터벌들에서 별도의 통지 타이머를 도입하며, 상기 인터벌들에서 측정 알고리즘은 bytesRemaining = 0에 대해 ioctl 호출 SCIOUTQ를 통해 전송 소켓(238)에 쿼리한다. 그러나, 여기서는, 데이터가 N=131072byte의 블록들로 번칭되지 않고, 오히려, 데이터가 트랜스코더(221)에 의해 생성됨에 따라, 데이터가 트랜스코더(221)로부터 트랜스코더 버퍼(232)(recpump)로 그리고 TCP 전송 소켓 버퍼(238b)로 흐르도록 허용된다. BW 추정을 위한 계산들은 여전히 AFTimer 통지들 사이에서 AFTimer의 TAF = 120msec 인터벌들에서 행해지지만, 반복 타이머가 TTB = 10msec마다 측정 알고리즘에게 전송 소켓 버퍼(238b)에 남아있는 바이트들의 수(bytesRemaining)를 판독하라고 통지한다. Nempty를 bytesRemaining=0인, 즉, 소켓 버퍼가 비어 있는 때의 AFTimer 인터벌들 사이에서 발생하는 10msec 타이머 통지들의 수라고 하자. 여기에서 발생할 수 있는 두 가지 조건들이 있다.
1) 전송 소켓 버퍼(238b)는 Nempty <12TTB sec 타이머 통지 인터벌들에서 비어있으며, 즉, 다음 AFTimer 인터벌 이전에 트랜스코더 출력 버퍼(232)(recpump) 데이터가 소켓 버퍼(238)로 완전히 전송되므로, 마지막 AFTimer를 지난 Nempty*TTB sec에서 bytesRemaining = 0이다.
2) 또는, TCP 프로토콜 상태 및 네트워크 스루풋은, 다음의 AFTimer 인터벌에서 bytesRemaining ≠ 0이 되도록, 마지막 트랜스코더 출력 버퍼(232)(recpump) 데이터 블록 모두가 전송되게는 하지 않도록 한다.
socketBytesSent는 AFTimer 통지에서 게이트웨이 서버(202)의 TCP 전송 소켓 버퍼(238b)로 전송되는 트랜스코더 출력 버퍼(232)(recpump) 데이터 블록의 데이터 바이트들의 수를 나타내는 것으로 한다. bytesRemaining은 현재의 AFTimer 만료시 또는 bytesRemaining = 0인 때로부터 NemptyTTB sec 후에, 전송 소켓 버퍼(238b)에 남아있는 것으로 보고되는 바이트들의 수라고 한다. prevBytesRemaining은 이전의 AFTimer 통지 인터벌에서 전송 소켓 버퍼(238b) 내의 바이트들의 수라고 하고, prevBytesRemaining은, 마지막 AFTimer 인터벌 이전에 모든 바이트들이 전송된 경우에는 0과 같을 것이고, 그렇지 않은 경우에는 0이 아닐 것이다. 그리고, 타이머 기반 알고리즘은 다음의 계산들을 사용하여 AFTimer 인터벌들에서 대역폭 측정들을 수행한다.
[수학식 5]
이 기술은 최대 TCP 스루풋을 동적으로 제한하기 위해 포트 레이트 성형을 가능하게 하는 이더넷 스위치를 통해 트랜스코더(221)로부터의 상이한 비디오 비트 레이트들 및 해상도들에서 테스트되었다.
도 7은 식 (1)의 종래의 기술의 CWND 기반 BW 계산의 플롯 없이 도 3의 결과들을 반복하며, 이는 875kbps의 평균 레이트에서 집계 MPEG-2 TS로 운반되는 VBR 384x216p30 비디오 스트림에 대해 동작 중인 타이머 기반 알고리즘을 도시한다. "스위치 캡" 플롯(702)에 의해 도시된 바와 같이, 네트워크 스루풋은 20sec 인터벌들로 30Mbps로부터 2Mbps, 5Mbps, 10Mbps, 30Mbps, 8Mbps, 6Mbps, 3.5Mbps 및 2Mbps로 변하는 이더넷 스위치 포트 레이트 성형 필터를 사용하여 동적으로 제약되었다. 타이머 기반 BW 계산은 변동들을 평탄화하기 위해 3-탭 슬라이딩 윈도우 중앙값 필터를 사용하여 필터링되었다. "타이머 기반 bw: 3-탭 중앙값 필터링됨" 곡선(704)은 레이트 성형 필터 캡들을 나타내는 "스위치 캡" 곡선(702)의 추세와 매치된다. 그러나, 예를 들어, 스위치 용량이 30Mbps인 때, 시간 t = 110sec에서, 높은 채널 용량 동안에 낮은 MPEG-2 TS 비트 레이트들이 발생하면, 트랜스코더(221)는 120msec의 AFTimer 인터벌마다 트랜스코더 출력(recpump) 버퍼(232)에 단지 5 내지 10kByte의 데이터만을 주기적으로 전달한다(예를 들어, 5kByte x 8/0.12sec = 333kbps의 레이트). 1514byte의 이더넷 MSS가 주어지면, TCP 전송 소켓(238)의 데이터는 120msec마다 몇 개의 TCP 세그먼트들을 통해서만 전달될 것이다. 이들 세그먼트들은 예를 들어, BW = 5kByte x 8/(0.01sec) = 4Mbps의 양자화 에러 측정을 산출하는 10msec TTB 타이머 인터벌 내에서 양호하게 전송될 것이다. 이는 TCP 스트림의 와이어샤크 네트워크 캡쳐의 분석에서 검증되며, 여기서 TCP 세그먼트 전달들은 도 7의 "10msec 빈들에 대한 와이어샤크 pcap 비트 레이트" 곡선(706)에 도시된 10msec 인터벌들에서 카운트된다. t=110sec에서, 와이어샤크 분석 곡선(706)은 타이머 기반 BW 곡선과 근접하게 매치된다. 플롯(708)은 4개의 프레임들에 걸쳐 평균화된 비디오 비트 레이트를 도시한다.
10msec의 TTB 인터벌들에 대해 BW 측정 에러를 산출하는 낮게 제공된 로드의 문제점에 대한 가능한 해결책들은 다음을 포함한다.
·TTB를 더 작은 값들, 예를 들어, 7, 5 또는 3msec으로 낮춘다. 이렇게 하면 더 많은 통지들을 서비스하기 위해 CPU 로드를 증가시킬 것이지만, 식 (6)의 분모에서 시간 부정확성을 줄일 것이다.
·특정 임계치가 초과될 때까지(예를 들어, 12.5kbyte), 데이터가 recpump 데이터 버퍼에서 유지되는 약간의 번칭 알고리즘을 수행한다. 12.5kbyte가 누적되어 TCP 전송 소켓 버퍼(238b)로 릴리즈되고, TTB = 10msec 타이머 통지 인터벌들이 사용되면, 12.5kByte의 최소 데이터 블록에 대해 측정될 최대 비트 레이트는 BW = (12.5kB)x8/0.01s = 10Mbps이다.
·3.5Mbps 미만의 비트 레이트들로 모바일 클라이언트 비디오를 재생하기 위해 비디오 트랜스코더를 제어할 목적으로, 최대 10Mbps의 네트워크 BW 측정이 적합하고 수용 가능하다.
상위 MPEG-2 TS 비트 레이트 서비스들에 대해서는, 이 시간 양자화 에러 효과가 빈번하지 않다.
도 8은 평균 3.2Mbps 비트 레이트에서 960x540p30 VBR MPEG-2 TS A/V 스트림에 대한 유사한 곡선들을 도시한다. 이 도면에서는, 최소 TS 비트 레이트가 통상적으로 1-2Mbps보다 크므로, "타이머 기반 bw: 3-탭 중앙값 필터링됨" 곡선(804)이 "스위치 캡" 곡선(802)의 추세를 더 가까이 따른다. 이 테스트에서는, 스위치 캡 또는 최대 네트워크 대역폭을 여러 번 초과하는 "4개의 프레임들에 걸친 비디오 비트 레이트" 곡선(808)에서 보이는 높은 비디오 비트 레이트와 관련된 상이한 문제점이 관찰되었다. 여기서는, 생성 레이트가 네트워크 용량을 초과하기 때문에, TCP 접속이 클라이언트(204)에게 데이터를 제 시간에 전달할 수 없는 기간들이 있다. "AFTimer 델타(msec x 10)" 곡선(806)에 도시된 바와 같이, TCP 전송 소켓 버퍼(238b)가 AFTimer 통지 인터벌들 사이에서 비어있지 않기 때문에, AFTimer 인터벌들이 눈에 띄게 길어진다. t = 170-180sec에서 이 테스트가 끝날 무렵에, 클라이언트(204)는 제약된 네트워크를 통해 미디어를 다운로드할 수 없었고, 재생에 실패했다. 그러나, 시간 t = 80-100sec에서 네트워크 용량이 30Mbps일 때, 측정값들은 대부분 10Mbps를 초과하였다.
Tcpi
_last_
ack
_
recv
알고리즘
tcpi_last_ack_recv 알고리즘은 Linux 스택에 대한 getsockopt 호출의 tcp_info 구조에서 리턴되는 tcpi_last_ack_recv 파라미터를 사용한다. 이 파라미터는 마지막 TCP ACK가 게이트웨이(202) TCP 프로토콜에 의해 수신된 시스템 시간을 제공한다. tcpi_last_data_sent와 유사하게, 이 파라미터는 TCP 전송 소켓(238)을 통해 클라이언트(204)로 트랜스코더 출력 버퍼(232)(recpump) 데이터 블록 상당의 미디어 데이터를 전달하기 위한 elapsedTime을 계산하는 데 사용된다. 다음의 예에 도시된 바와 같이, 이 값은 TCP 세그먼트 전달을 위한 elapsedTime을 계산하는 데 사용된다.
표 III은 포트 7878 상의 IP 어드레스 192.168.1.5에서의 ABR 서버(202)와 포트 52304 상의 IP 어드레스 192.168.1.8에서의 DLNA 클라이언트 사이의 DLNA 미디어 스트리밍 세션의 개시에 대해 와이어샤크 캡처로부터 취해진 TCP 흐름 그래프를 제시한다. 정상 텍스트와 이탤릭체의 볼드체 텍스트를 번갈아 쓰는 것에 의해 120msec의 지속 시간의 대략적인 순차적 AFTimer 인터벌들을 기술한다. 예를 들어, 미디어 전달의 개시시에는, ACK 시퀀스 분석 컬럼(Seq=264)에서 언급된 바와 같이, 시간 t=0.000000sec까지 264byte가 전달되었다. 시간 t=0.0에서 트랜스코더 출력 버퍼(232)(recpump) 데이터 블록 사이즈는 1856byte이며, 이는 TCP 소켓을 통해 2개의 세그먼트들, 즉 하나는 1448byte이고 다른 하나는 408byte인 2개의 세그먼트들로 전달된다. 이들은 시간 t=0.088535sec에서 클라이언트(204)에 의해 후속적으로 ACK된다. 다음의 AFTimer 인터벌은 120msec 후에 시작하고, 시간 t=0.120447sec에서 소켓(238)이 트랜스코더 출력 버퍼(232)(recpump)로부터 클라이언트(204)로 768byte(이는 시간 t=0.124229sec에서 ACK됨)를 전달하는 것이 보였다. 유사하게, 제5 AFTimer 인터벌에서의 시간 t=0.480360sec에서, recpump 블록 사이즈는 bytesSent = 33472byte이며, 이는 일련의 23개의 1448byte TCP 세그먼트들로 TCP 프로토콜에 의해 클라이언트에 전달되고, 하나의 168byte 세그먼트가 시간 t=0.498158sec에서 완료되었고, 시간 t=0.505405sec에서 전체적으로 ACK되었다. 데이터의 이 제5 트랜스코더 출력 버퍼(232)(recpump) 블록에 대한 대역폭 추정은 t=0.60sec에서 발생하는 다음 AFTimer 인터벌에서 이루어진다. 결과적인 tcpi_last_ack_recv 값은 TlastACKrecv = 0.60-0.505405 = 0.0946sec로서 보고될 것이며, 이는 현재 t=0.60sec AFTimer 통지 시간 스탬프(notification time stamp)로부터 클라이언트(204)로부터 마지막 ACK가 수신될 때까지의 시간 델타이다. elapsedTime은 다음과 같이 계산된다.
대응하는 TCP BW 계산은 다음과 같이 행해질 수 있으며,
이 예의 경우에는, 다음을 산출한다.
표 III
elapsedTime 계산을 약간 개선하면 측정이 약간 향상된다. AFTimer 통지의 구현에서, CPU 프로세스 로딩으로 인해 작은 지연들이 있을 수 있으므로, AFTimer 통지들 사이의 시간 델타는 원하는 120msec 값에서 최대 어느 정도의 수십 msec의 작은 변화량을 가질 수 있다. 이 에러는 AFTimer 통지 인터벌에서 시스템 시간 호출들을 행하여 currentTime 변수를 설정함으로써 수정된다. 대역폭 계산이 완료되면, 변수 lastSendTime이 currentTime 값으로 설정된다. 따라서, lastSendTime은 recpump 데이터가 전송 소켓 버퍼(238b)로 전달된 이전 순간을 나타내고, currentTime은 최근의 AFTimer가 만료되고 recpump 데이터가 소켓으로 전달된 시간을 나타낸다.
(제5 AFTimer 계산의 상기 예에서와 같이) TCP 소켓에서의 bytesRemaining이 0과 같을 때, 데이터가 소켓을 통해 전달되었고 수신기에 의해 ACK된 것으로 가정하면, 경과 시간은 다음과 같이 계산되며,
bytesRemaining이 0이 아니면, tcpi_last_ack_recv 값은 그것이 나타내는 전달된 세그먼트가 무엇인지에 대해 불확실하며, 경과 시간은 여기에서 수정된 AFTimer 지속 시간 TAF와 동일할 것이다.
소켓 전송 버퍼에 의해 취해진 바이트들의 실행 집계는 위의 식 (6)에서와 같이 변수 bytesTakenBySocket에서 유지된다.
따라서, 이 알고리즘의 경우, 완전한 BW 계산은 이제 다음과 같이 수행된다.
tcpi_last_ack_recv 알고리즘은 이하 설명되는 네트워크 대역폭 측정 방법으로서 현재 게이트웨이 서버측 ABR 제어 알고리즘에 통합되어 있다.
대역폭 측정 컨디셔닝
AFTimer 인터벌들 상에서 상기 알고리즘들에 의해 행해진 BW 측정들은 미디어 스트림 비트 레이트 및 네트워크 용량에 따라 약간의 변동들 및 부정확성들을 나타낸다. 첫째, 원시(raw) BW 값은 다음과 같이 최대 10Mbps로 캡핑된다.
[수학식 9]
이 캡은, 후술되는 트랜스코더 제어 알고리즘에서, 트랜스코더 MPEG-2 TS 출력 비트 레이트가 컨디셔닝된 대역폭 측정치의 40%로 설정되어, 네트워크 용량 오버 헤드가 클라이언트 버퍼 언더런 및 정지에 대해 최소한의 기회로 미디어 스트림의 전달을 보장하게 할 수 있기 때문에 선택된다. 본 출원에서 사용되는 최대 TS 비트 레이트들은 4Mbps보다 작기 때문에, BW 측정치들이 4Mbps/0.4 = 10Mbps보다 큰 값들로 시그널링될 필요가 없다.
둘째로, 이러한 구현을 위해, 원시 tcpi_last_ack_recv BW 측정치들은 N-탭의 슬라이딩 윈도우 중앙값 필터를 사용하여 필터링된다. 5-탭 중앙값 필터 하에서 양호한 결과들이 나오는 것을 알아냈다. 즉, 정상 동작에서는, 이 필터가 TAF = 120msec에 대해 600msec 필터 지원을 제공하는 5개의 AFTimer 인터벌 BW 측정들에 걸쳐 있다. AFTimer 인스턴스 k에서 클램핑된 대역폭 측정치가 clampedBWk로 표시되고(k는 정수 인덱스임), 함수 Median(Xn:Xn +N- 1)이 n에서 n+N-1까지의 N개의 실수들의 중앙값으로서 주어지면, 최종 컨디셔닝된 대역폭 값들인 conditionedBWk 값들은 다음에 의해 주어진다.
비트
레이트
및 해상도 제어
비디오, 오디오 및 HLS 제약조건들 및 고려사항들
일단 네트워크 BW 측정치들이 획득되고 나면, 선택되는 최적의 트랜스코딩 파라미터들을 결정하고, 트랜스코더 및 미디어 세그먼트 생성기(220)에게 이들 파라미터들에 따라 메자닌 레코딩들을 트랜스코딩하라고 명령하는 문제가 남아 있다. 이 기능은 트랜스코더 ABR 및 해상도 제어기(218)에 의해 수행된다.
트랜스코더 커맨드들을 결정할 때, 트랜스코딩되는 미디어 및 스트림 포맷들을 고려하는 것이 필수적이다. DLNA 스트리밍 및 기타 모바일 애플리케이션들의 경우, AVC/H.264 비디오 압축 알고리즘들이 사용될 수 있으며, MPEG-2 또는 AVC 압축 포맷들로 코딩되는 입력 메자닌 비디오는 대개 30프레임/초(fps)로 프로그레시브 모드에서 AVC로 트랜스코딩될 수 있다. HLS 스트림들에서, 오디오는 AAC 또는 AC-3 포맷들로 트랜스코더에 입력되고, 통상적으로 64kbps 비트 레이트보다 약간 낮게 스테레오 HE-AACv1 또는 v2로 트랜스코딩되는 것으로 가정될 수 있다. 다음의 고려사항들은 하나의 이러한 서버측 ABR 구현에 적용될 수 있다.
·트랜스코더(221) 해상도 설정들에 대한 변경들은 순간 디코더 리프레시(Instantaneous Decoder Refresh)(IDR) 슬라이스 경계들에서만 이루어진다. IDR들은 통상적으로 HLS 미디어 스트림에서 1 내지 2초 떨어져 있을 수 있다.
·총 미디어 전송 스트림 비트 레이트는 클라이언트(204)에서의 디코더 버퍼의 입력 버퍼가 재생 동안에 언더런되지 않는 충분한 시간 내에 MPEG-2 스트림이 다운로드될 가능성을 증가시키기 위해 측정된 네트워크 대역폭보다 약간의 마진만큼 작아야 한다. DLNA-대-HLS 프록시를 포함하는 APPLE 클라이언트들의 경우, 플레이어들이 2초 정도로 작은 양의 버퍼링된 미디어 데이터를 재생하기 시작했다는 점에서 주목받았으며, 이 비교적 작은 양의 버퍼링된 데이터는 서버측 비트 레이트 제어 알고리즘이 정보를 송신하는 데 사용되는 네트워크의 통신 채널의 대역폭의 변경들에 매우 빠르게 반응해야 할 필요가 있다는 것을 의미한다.
·동적 트랜스코더 변경들은 시간에 제약을 받아야 한다. 비디오 비트 레이트 커맨드들을 너무 빈번하게 변경하면 트랜스코더 레이트 제어 문제들이 발생할 수 있고, 게다가 결과적으로 최종 사용자가 경험하는 비디오 품질이 급속하게 변할 수 있다. 유사하게, 비디오 해상도 변경들을 빈번하게 및/또는 크게 행하는 것은 가능하다면 피해야 한다.
비트 레이트 및 해상도 제어 구현
도 9는 비트 레이트 해상도 및 제어를 수행하기 위한 예시적인 동작들을 도시하는 도면이다. 도 9는, 도 2에 도시된 컨텐츠 미디어 서버 및 대역폭 측정 모듈(216) 및 트랜스코더 적응형 비트 레이트 및 해상도 제어기(218)에 대한 보다 상세한 표현을 포함하여, 이러한 동작들을 수행하기 위한 장치의 실시예를 도시하는 도 10을 참조하여 논의될 것이다.
먼저, 블록(902)을 참조하면, 클라이언트는 서버(202)에 데이터 자산에 대한 요청을 송신한다. 블록들(904 및 906)에 도시된 바와 같이, 서버(202)는 데이터 자산에 대한 요청을 수신하고, 하나 이상의 초기 트랜스코딩 파라미터들에 따라 미디어 자산의 적어도 일부를 트랜스코딩하기 시작한다. 그 후, 블록들(908 및 910)에 도시된 바와 같이, 서버(202)는 데이터 자산의 트랜스코딩된 적어도 일부를 이것이 수신되는 통신 채널을 통해 클라이언트에게 송신한다.
이러한 송신이 일어나고 있는 동안, 블록(912)에 도시된 바와 같이, 서버(202)는 클라이언트에 의해 데이터 자산의 트랜스코딩된 적어도 일부의 수신을 확인응답하는 정보로부터 적어도 부분적으로 통신 채널의 대역폭의 추정치를 생성한다. 이는 예를 들어, 도 10에 도시된 대역폭 추정기(1002)에 의해 수행될 수 있다. 대역폭 측정 모듈(216)의 대역폭 추정기(1002)는 통신 채널 대역폭 추정 정보(이것은 예를 들어, 트랜스코딩된 데이터의 수신을 확인응답하는 정보, 얼마나 많은 데이터가 특정 인터벌에 걸쳐 전송되었는지를 기술하는 정보뿐만 아니라, 타이머 및 클록 정보를 포함할 수 있음)를 수용하고, 대역폭 추정 정보로부터 통신 채널의 대역폭의 추정치를 생성한다.
일 실시예에서, 대역폭 추정치는 데이터 자산의 송신되는 트랜스코딩된 적어도 일부의 왕복 시간(RTT) 및 데이터 자산의 송신되는 트랜스코딩된 적어도 일부의 사이즈에 따라 적어도 부분적으로 생성된다. RTT는 데이터 자산의 트랜스코딩된 적어도 일부의 송신의 개시와 데이터 자산의 트랜스코딩된 적어도 일부의 수신에 대한 확인응답의 수신(예를 들어, ACK 메시지의 수신) 사이의 경과 시간일 수 있다.
본 명세서에 설명된 바와 같이, 대역폭 추정치는 이전의 타이머 이벤트로부터 타이머 인터벌 TAF만큼 시간적으로 분리된 타이머 이벤트(전술한 AFTimer 이벤트 등)에서 계산될 수 있다. 이러한 경우에, 데이터 자산의 트랜스코딩된 적어도 일부의 송신의 개시와 수신기에 의한 데이터 자산의 해당 트랜스코딩된 적어도 일부에 대한 확인응답의 수신 사이의 경과 시간은 TAF-TlastACKrecv로서 계산될 수 있으며, 여기서 TlastACKrecv는 데이터 자산의 트랜스코딩된 적어도 일부의 수신에 대한 가장 최근의 확인응답의 클록 시간과 가장 최근의 타이머 이벤트의 클록 시간 사이의 시간이다.
다른 실시예에서, 데이터 자산의 트랜스코딩된 적어도 일부의 송신의 개시와 데이터 자산의 트랜스코딩된 적어도 일부의 수신에 대한 확인응답의 수신 사이의 경과 시간은 다음과 같이 계산될 수 있다.
DataRemaining이 0인 경우,
DataRemaining이 0이 아닌 경우,
(데이터 자산의 적어도 일부의) 트랜스코딩된 데이터의 양은 prevDataRemaining + socketDataSent - DataRemaining에 따라 결정될 수 있으며, 여기서 socketDataSent는 타이머 이벤트에서 서버의 TCP 전송 소켓 버퍼에 전달된 데이터 자산의 양(위에서 논의된 socketBytesSent 값과 유사)이고, DataRemaining은 타이머 이벤트 직후의 타이머 인터벌에서 TCP 전송 소켓에 남아있는 전송되지 않은 데이터 자산의 양(위에서 논의된 bytesRemaining 값과 유사)이며, prevDataRemaining은 이전의 타이머 인터벌 후에 TCP 전송 소켓 버퍼에 남아있는 데이터 자산의 양(위에서 논의된 prevBytesRemaining 값과 유사)이다.
생성된 대역폭 추정치는 트랜스코더(221)에 명령하기 위해 사용되기 전에 추가로 프로세싱될 수 있다. 우선, 대역폭 추정치는 리미터(limiter)(1003)에 의해 클램핑될 수 있다. 이는 추정된 대역폭을, 통신 채널 대역폭이 초과할 것으로 예상되지 않는 특정 값을 대역폭 추정치들이 초과하는 것을 방지하도록 선택될 수 있는 값으로 제한한다. 이에 의해 불합리한 대역폭 추정치들을 방지할 수 있다. 클램핑 값은 사전 선택되거나 추정될 수 있으며, 시간이 지남에 따라 고정되거나 변경될 수 있다. 후술되는 예시적인 실시예에서, 대역폭 추정치는 예를 들어, 10Mbps로 클램핑될 수 있다.
다음으로, 클램핑된 원시 통신 채널 대역폭은 필터 모듈(1004)에 의해 필터링될 수 있다. 필터 모듈(1004)은 대역폭 추정치들을 평탄화하여, 트랜스코더(221)에 제공되는 커맨드들이 다른 소스들보다 통신 채널 대역폭의 더 장기간의 변화들을 보다 정확하게 나타내게 한다. 예를 들어, 실제 통신 대역폭의 변화들이 특정 스펙트럼 컨텐츠를 갖는다면, 필터 모듈은 추정된 통신 채널 대역폭을 필터링하여 그 스펙트럼 컨텐츠와 일치하지 않는 값들을 제거하게 할 수 있다. 통상적으로, 필터(1004)는 디지털 저역 통과 필터이다. 예를 들어, 이하에 추가로 설명되는 실시예에서, 필터(1004)는 슬라이딩 윈도우 5-탭 중앙값 필터와 같은 유한 임펄스 응답 필터를 포함하지만, 네거티브 피드백을 사용하는 무한 임펄스 응답(infinite impulse response)(IIR) 필터들, 또는 상태 및 노이즈 추정치들을 적응적으로 제공하는 최적의 필터들(예를 들어, 칼만 필터들)과 같은 다른 필터 타입들도 사용될 수 있다. 필터(1004)의 출력은 클램핑된 대역폭 추정치의 필터링된 버전이다.
필터링되고 클램핑된 대역폭 추정치는 스케일러(1006)에 제공될 수 있으며, 스케일러(1006)는 필터링되고 클램핑된 대역폭 추정치를 스칼라 값만큼 스케일링한다. 이하의 실시예에서, 스칼라 값은 0.4가 되도록 선택되어, 필터링되고 클램핑된 추정된 대역폭 추정치의 40%의 트랜스코더(221) 비트 레이트 커맨드를 제공한다. 또한, 스칼라 값은 시스템 조건들에 기초하여 적응적으로 변경될 수도 있다.
도 9로 되돌아가면, 블록(914)에서, 적응형 트랜스코딩 파라미터들이 블록(912)에서 전술한 통신 채널의 대역폭의 추정치로부터 적어도 부분적으로 생성된다. 도 10에 도시된 바와 같이, 이는 트랜스코더 적응형 비트 레이트 및 해상도 제어 모듈(219)에 의해 달성될 수 있다. 먼저, 통신 링크 대역폭 추정치로부터 도출되는 트랜스코더 비트 레이트 커맨드는 저역 통과 필터링될 수 있다. 이는 도 10에 도시된 루프 필터(1007)에 의해 달성될 수 있다. 일 실시예에서, 루프 필터(1007)는 1차 피드백 제어 루프이며, 여기서, 필터링된 비트 레이트 커맨드는 루프 피드백 이득 모듈(1008)에 의해 루프 에러 이득 값만큼 곱해지고, 루프 에러 누산기(1009)에 의해 비트 레이트 커맨드로부터 감산되어 루프 에러 값을 생성한다. 루프 필터(1007)는 트랜스코더(221)에 대한 비트 레이트 커맨드들이 다른 경우보다 더 느리게 증가 및 감소하게 한다. 일 실시예에서는, 이하에서 추가로 기술되는 바와 같이, 루프 필터 이득 모듈이, 필터링된 비트 레이트 커맨드가 양인 경우에는 0.2 스칼라 이득을 구현하고, 필터링된 비트 레이트 커맨드가 음인 경우에는 0.04 스칼라 이득을 구현한다. 이 경우, 트랜스코더 비트 레이트 커맨드는 트랜스코더 비트 레이트 커맨드의 증가들보다 트랜스코더 비트 레이트 커맨드의 더 빠른 감소들을 허용하도록 비대칭적으로 필터링된다.
임의적인 감산기(1010)는 루프 필터의 출력(필터링된 비트 레이트 커맨드)으로부터 고정된 오디오 기본 스트림 비트 레이트를 제거한다. 그 후, 결과적인 비디오 스트림 비트 레이트 커맨드는 스퓨리어스 트랜스코더 커맨드들(220)을 방지하기 위해 양자화기 모듈(1012)에 의해 양자화된다. 특정 필터링된 비트 레이트 커맨드들에 대응하는 양자화 레벨들의 상세는 이하 제시되는 상세한 구현에서 추가로 논의된다.
그 후, 양자화된 비트 레이트 커맨드는 임계치 추세 필터(1014)에 의해 임의로 프로세싱될 수 있다. 임계치 추세 필터는 트랜스코더(220) 비트 레이트 커맨드들의 변화 빈도를 늦춤으로써 트랜스코더(220)가 "스래싱(thrashing)"하는 것을 방지한다. 일 실시예에서, 비트 레이트 커맨드의 적어도 N개의 연속적인 증가들이 추세 임계치 필터(1014)에 제공될 때까지, 추세 필터(1014)는 트랜스코더 비트 레이트 커맨드의 변화들을 유지한다. 이는 N개의 연속적인 출력 비트 레이트 커맨드들 각각이 이전의 출력 비트 레이트 커맨드보다 클 때까지 출력 비트 레이트 커맨드의 증가들을 지연시키기 때문에, 통신 채널 조건들이 낮은 대역폭 조건들로부터 상위 대역폭으로 리턴할 때, 트랜스코더 비트 레이트 커맨드의 상승을 느리게 한다.
마지막으로, 임계화되고 양자화된 비트 레이트 커맨드는 또한 비디오 해상도 선택기(1016)에 의해 임의로 프로세싱될 수 있다. 이하 추가로 설명되는 바와 같이, 비디오 해상도 선택기(1016)는 비트 레이트 커맨드들에 기초하여 비디오 해상도를 선택한다.
다시 도 9로 돌아가면, 블록(916)에 도시된 바와 같이, 트랜스코더에 의해 사용되는 트랜스코딩 파라미터들은 생성된 적응형 트랜스코딩 파라미터들(예를 들어, 위에서 생성된 비트 레이트 커맨드 및 비디오 해상도)에 의해 업데이트되고, 블록들(906-910)에 다시 도시된 바와 같이, 이들 업데이트된 트랜스코딩 파라미터들은 적어도 서버(202)에 의해 송신되고 클라이언트(204)에 의해 수신되는 데이터 자산의 추가 부분을 트랜스코딩하는 데 사용된다.
비트
레이트
및 해상도 제어의 의사 코드 구현
도 11은 서버측 ABR 비디오 비트 레이트 및 해상도 제어 알고리즘의 의사 코드(pseudocode) 구현을 나타내는 도면이다. 이 구현을 위해, 다음과 같은 메커니즘들이 사용되었다.
1. TAF = 120msec 또는 그 이상마다의 AFTimer 통지 인터벌들(1102)에서, 블록(1104)에 도시된 바와 같이, 전술한 tcpi_last_ack_recv BW 측정 알고리즘은 원시 TCP 네트워크 BW(스루풋 또는 굿풋)의 추정치를 생성하는 데 사용된다.
2. 블록(1106)에서, 원시 대역폭 값은 10Mbps로 클램핑되고 슬라이딩-윈도우 5-탭 중앙값 필터에 의해 필터링된다.
3. 블록(1108)에서, 1차 피드백 제어 루프는 대역폭 측정치들에 기초하여 트랜스코더 MPEG-2 TS 출력 비트 레이트를 도출하도록 구현된다. 도시된 실시예에서, 전체 MPEG-2 TS 비트 레이트는 상술한 바와 같이 사용가능한 네트워크 대역폭의 40%를 타겟으로 한다. 그러면, 루프가 평균 제로 값으로 구동하는 LoopError 변수에 의해 검출되는 바와 같이, LoopOutput이 필터링된 conditionedBW k 값들의 40%로 구동된다. 루프는 비선형 응답을 가지므로, 증가하는 BW에는 천천히, 감소하는 BW 측정치들에는 빠르게 반응한다. 이것은 루프 업데이트 주기마다 그것의 컨텐츠로부터 LoopError 값을 감산하는 LoopOutput 누산기에 의해 구현된다. 일 구현의 경우, 1차 루프 이득은 양의 LoopError 값들에 대해서는 0.2이고(LoopOutput, 따라서 트랜스코더 비트 레이트를 더 낮게 구동시킴), 음의 LoopError에 대해서는 0.04이다(트랜스코더 비트 레이트를 더 높게 구동시킴). 따라서, 루프는 채널 용량이 높을 때에는 명령된 트랜스코더(220) 비트 레이트를 천천히 증가시킬 것이지만, 채널 용량이 갑자기 강하되어 낮게 유지되는 경우에는 매우 빠르게 반응할 것이다.
4. 그 후, 블록(1110)에서, LoopOutput 비트 레이트는 BitRateQuantizer() 함수에 의해 양자화된다. 이 함수는 LoopOutput(총 MPEG-2 타겟 TS 비트 레이트를 나타냄)으로부터 고정된 오디오 기본 스트림 비트 레이트를 우선적으로 감산함으로써, LoopOutput으로부터 비디오 트랜스코더 타겟 기본 스트림(ES) 비트 레이트를 계산한다. 이러한 구현 예에서, 오디오 트랜스코더 비트 레이트는 제어 알고리즘의 일부로서 변경되지는 않지만, 다른 실시예들은 원하는 경우 오디오 비트 레이트 제어를 통합할 수 있다. 이 구현을 위해, 비디오 ES 비트 레이트는 비선형 방식으로 양자화되어, 600kbps 미만의 원하는 비디오 ES 비트 레이트들에 대해서는 스텝들이 100kbps이고, 600 내지 1200kbps의 비디오 ES 비트 레이트들에 대해서는 스텝들이 200kbps이고, 1200 내지 3500kbps의 비디오 ES 비트 레이트들에 대해서는 스텝들이 300kbps이 되게 한다. 이 양자화는 비디오 피크 신호 대 노이즈 비(PSNR) 및 품질 레이트-왜곡 곡선들이 낮은 비트 레이트들에서 높은 비트 레이트에서의 점근적인 플랫 값들로 빠르게 상승하여, 낮은 비트 레이트들에서의 양자화 스텝들이 상위 비트 레이트들에서보다 작아야 한다는 주관적 및 객관적인 관찰들을 사용한다. 또한, 이러한 양자화의 사용은 알고리즘이 AFTimer 인터벌마다 새로운 레이트 제어 값들로 비디오 트랜스코더를 "스래싱"하는 것을 방지한다. 도 12는 루프 출력을 양자화하기 위한 예시적인 의사 코드를 도시하는 도면이다.
5. 블록(1112)에서, 비디오 비트 레이트를 증가시키는 트랜스코더 업데이트 커맨드들의 빈도를 늦추는 상태 머신에서 추가 레이트 "스래싱"이 방지된다. 이 상태 머신에서는, 새로이 계산된 비트 레이트인 CurrentBitrate가 이전에 계산된 비트 레이트인 PreviousBitrate보다 작은 경우, bReturn 값이 TRUE로 설정되어, (네트워크 대역폭 및 채널 용량의 강하에 응답하여) 즉각적인 트랜스코더 커맨드가 트랜스코더 비트 레이트를 낮추도록 행해져야 한다고 시그널링한다. 그러나, PreviousBitrate가 증가하는 네트워크 대역폭의 CurrentBitrate 시그널링 검출보다 작은 경우, 트랜스코더 제어는 이러한 조건들이 적어도 6회 연속될 때까지 연기된다. 이렇게 하면, 네트워크 조건들이 저 용량에서 고 용량으로 리턴할 때, 트랜스코더 비트 레이트의 상승을 느리게 한다.
6. 명령된 비디오 기본 스트림 비트 레이트인 CurrentBitrate는 원하는 비디오 해상도를 결정하기 위해 추가로 컨디셔닝된다. 도 13은 30fps에서 다양한 16:9 종횡비 비디오 해상도들에 대한 픽셀 당 코딩된 비디오 비트들(coded video bits per pixel)(CVBPS) 대 비디오 코딩된 비트 레이트를 도시한다. H.264/AVC 인코딩의 경우, 720p60 압축 시퀀스들이 약 6Mbps 이상의 코딩된 비트 레이트에서 양호한 품질을 달성하는 것으로 널리 공지되어 있다. 30fps에 대해 선형 스케일링을 적용한다는 것은 양호한 720p30 품질이 3Mbps에서 달성될 수 있어야 한다는 것을 암시한다. 이는 CVBPS = (3Mbps)/(1280x720 픽셀/프레임)/30fps = 0.11 코딩된 비트/픽셀을 나타낸다. 따라서, 주어진 타겟 비디오 비트 레이트에 대해, 약 0.11의 CVBPS를 유지하는 비디오 해상도를 선택하는 것이 바람직할 수 있다. 도 11은 트랜스코더 엘리먼트에 주어진 비디오 비트 레이트 커맨드에 대해 선택되는 비디오 해상도 값들을 도시한다. 예를 들어, 위의 단계 5의 알고리즘이 필요한 비디오 비트 레이트인 CurrentBitrate가 1700kbps 내지 2700kbps에 있다고 결정하는 경우, 비디오 해상도는 1060x540 픽셀에서 qHD로 설정되지만, 원하는 비디오 비트 레이트가 500 내지 800kbps인 경우, 해상도는 512x288로 설정된다.
상기 구현에서, 모든 임계치들 및 이득 값들은 설정 가능하며, 원하는 트랜스코더 비디오 비트 레이트 제어 경험을 제공하도록 선택될 수 있다. 이러한 임계치들을 사용한 실험은 설명된 값들로 인해 합리적인 결과들을 가져 왔지만, 알고리즘을 튜닝하기 위해서는 좀더 광범위한 테스트가 필요하다.
도 14는 전술된 서버측 ABR 알고리즘에서 사용되는 2개의 상이한 세트의 루프 이득 파라미터들에 대한 성능의 예를 도시한다. tcpi_last_ack_recv 알고리즘에 기초한 BW 측정치들이 측정 컨디셔닝을 수행한 다음, 더 빠른 응답을 나타내는 (0.2, 0.04) 및 더 느린 응답을 나타내는 (0.1, 0.01)의 비선형 루프 이득 쌍들을 갖는 루프 인스턴스들에 적용되었다. 테스트가 진행됨에 따라, GW ABR 서버 이더넷 출력은 2에서 5, 10, 30, 8, 6, 4, 2, 5Mbps로 20초마다 변동하는 값들로 동적으로 스로틀되었다(throttled). "루프 출력 ka,up ka,dn"이라고 표시된 곡선들은 BitRateQuantizer() 함수가 적용되기 전의 루프 출력을 도시하는 반면, "양자화된 루프 출력 ka,up ka,dn"이라고 표시된 곡선들은 BitRateQuantizer()가 적용된 후의 출력을 도시한다. 채널 용량이 증가할 때에는, 낮은 루프 이득들 ka,up=0.01 및 ka,dn=0.1로 인해 트랜스코더 비트 레이트가 매우 느리게 증가하여, 높은 네트워크 용량에서 이 테스트 예에 사용된 4Mbps의 최대 캡핑 레이트를 달성하기 위해서는 30sec 이상이 소요된다는 것을 알 수 있다.
하드웨어 환경
도 15는 ABR 서버(202), 클라이언트(204) 및 그 엘리먼트들을 포함하여, 본 발명의 엘리먼트들을 구현하는 데 사용될 수 있는 예시적인 컴퓨터 시스템(1500)을 도시하는 도면이다. 컴퓨터(1502)는 범용 하드웨어 프로세서(1504A) 및/또는 특수 목적 하드웨어 프로세서(1504B)(이하, 대안적으로 프로세서(1504)라고 집합적으로 지칭됨) 및 랜덤 액세스 메모리(RAM)와 같은 메모리(1506)를 포함한다. 컴퓨터(1502)는 키보드(1514), 마우스 디바이스(1516) 및 프린터(1528)와 같은 입/출력(I/O) 디바이스들을 포함한 다른 디바이스들에 결합될 수 있다.
일 실시예에서, 컴퓨터(1502)는 범용 프로세서(1504A)가 운영 체제(1508)의 제어 하에서 컴퓨터 프로그램(1510)에 의해 정의되는 명령어들을 수행함으로써 동작한다. 컴퓨터 프로그램(1510) 및/또는 운영 체제(1508)는 메모리(1506)에 저장될 수 있고, 사용자 및/또는 다른 디바이스들과 인터페이스하여, 입력 및 커맨드들을, 이러한 입력 및 커맨드들, 및 출력 및 결과들을 제공하기 위해 컴퓨터 프로그램(1510) 및 운영 체제(1508)에 의해 정의되는 명령어들에 기초하여 수용할 수 있다.
출력/결과들은 디스플레이(1522) 상에 제시되거나, 또는 프리젠테이션 또는 추가 프로세싱 및 액션을 위해 다른 디바이스에게 제공될 수 있다. 일 실시예에서, 디스플레이(1522)는 액정들에 의해 형성되는 복수의 별도로 어드레스 가능한 픽셀들을 갖는 액정 디스플레이(LCD)를 포함한다. 디스플레이(1522)의 각각의 픽셀은 불투명 또는 반투명 상태로 변화하여, 입력 및 커맨드들에 대한 컴퓨터 프로그램(1510) 및/또는 운영 체제(1508)의 명령어들의 적용으로부터 프로세서(1504)에 의해 생성되는 데이터 또는 정보에 응답하여, 디스플레이 상에 이미지의 일부를 형성한다. 또한, 다른 디스플레이(1522) 타입들도 디스플레이(1522) 상에 제시되는 이미지를 생성하기 위해 상태를 변화시키는 픽쳐 엘리먼트들을 포함한다. 이미지는 그래픽 사용자 인터페이스(GUI) 모듈(1518A)을 통해 제공될 수 있다. GUI 모듈(1518A)이 별도의 모듈로서 도시되어 있지만, GUI 기능들을 수행하는 명령어들이 운영 체제(1508), 컴퓨터 프로그램(1510)에 상주하거나 분산될 수 있고, 또는 특수 목적 메모리 및 프로세서들에 의해 구현될 수 있다.
컴퓨터 프로그램(1510) 명령어들에 따라 컴퓨터(1502)에 의해 수행되는 동작들 중 일부 또는 전부는 특수 목적 프로세서(1504B)에서 구현될 수 있다. 이 실시예에서, 컴퓨터 프로그램(1510) 명령어들 중 일부 또는 전부는 특수 목적 프로세서(1504B) 또는 메모리(1506) 내의 판독 전용 메모리(ROM), 프로그래머블 판독 전용 메모리(PROM) 또는 플래시 메모리에 저장된 펌웨어 명령어들을 통해 구현될 수 있다. 특수 목적 프로세서(1504B)는 또한 본 발명을 구현하기 위한 동작들 중 일부 또는 전부를 수행하기 위해 회로 설계를 통해 하드와이어드(hardwired)될 수 있다. 또한, 특수 목적 프로세서(1504B)는 기능들의 서브 세트를 수행하기 위한 전용 회로 및 컴퓨터 프로그램 명령어들에 응답하는 것과 같은 보다 일반적인 기능들을 수행하기 위한 다른 회로들을 포함하는 하이브리드 프로세서일 수 있다. 일 실시예에서, 특수 목적 프로세서는 주문형 집적 회로(ASIC)이다.
또한, 컴퓨터(1502)는 COBOL, C++, FORTRAN 또는 다른 언어와 같은 프로그래밍 언어로 기입된 애플리케이션 프로그램(1510)이 프로세서(1504) 판독가능 코드로 번역되도록 할 수 있는 컴파일러(1512)를 구현할 수 있다. 완료 후에, 애플리케이션 또는 컴퓨터 프로그램(1510)은 데이터에 액세스하고 이를 조작하며, 이 데이터는 I/O 디바이스들로부터 수용되어, 컴파일러(1512)를 사용하여 생성된 로직 및 관계들을 사용하여 컴퓨터(1502)의 메모리(1506)에 저장된다.
또한, 컴퓨터(1502)는 임의로 모뎀, 위성 링크, 이더넷 카드, 또는 다른 컴퓨터들로부터의 입력을 수용하고 다른 컴퓨터들로 출력을 제공하기 위한 다른 디바이스와 같은 외부 통신 디바이스를 포함한다.
일 실시예에서, 운영 체제(1508), 컴퓨터 프로그램(1510), 및/또는 컴파일러(1512)를 구현하는 명령어들은 컴퓨터 판독가능 매체, 예를 들어, 집 드라이브(zip drive), 플로피 디스크 드라이브(1524), 하드 드라이브, CD-ROM 드라이브, 테이프 드라이브 또는 플래시 드라이브와 같은 하나 이상의 고정식 또는 이동식 데이터 스토리지 디바이스들을 포함할 수 있는 데이터 스토리지 디바이스(1520)에 유형적으로 구현된다. 또한, 운영 체제(1508) 및 컴퓨터 프로그램(1510)은, 액세스될 때, 컴퓨터(1502)에 의해 판독되고 실행되는 컴퓨터 프로그램 명령어들로 구성되어, 컴퓨터(1502)가 본 발명을 구현 및/또는 사용하는 데 필요한 단계들을 수행하게 하거나 또는 명령어들의 프로그램을 메모리에 로드하게 하여, 컴퓨터가 본 명세서에 설명된 방법 단계들을 실행하는 특수 프로그램된 컴퓨터로서 동작하게 하는 특수 목적의 데이터 구조를 생성하게 한다. 컴퓨터 프로그램(1510) 및/또는 동작 명령어들은 또한 메모리(1506) 및/또는 데이터 통신 디바이스들(1530)에 유형적으로 구현될 수 있어, 이에 따라 본 발명에 따른 컴퓨터 프로그램 제품 또는 제조물을 제조하게 한다. 이와 같이, 본 명세서에 사용된 용어들 "제조물", "프로그램 스토리지 디바이스" 및 "컴퓨터 프로그램 제품" 또는 "컴퓨터 판독가능 스토리지 디바이스"는 임의의 컴퓨터 판독가능 디바이스 또는 매체로부터 액세스 가능한 컴퓨터 프로그램을 포함하도록 의도된다.
물론, 본 기술분야의 통상의 기술자는 상기 컴포넌트들, 또는 임의의 수의 상이한 컴포넌트들, 주변 디바이스들 및 다른 디바이스들의 임의의 조합이 컴퓨터(1502)와 함께 사용될 수 있다는 것을 인식할 것이다.
본 명세서에서 "컴퓨터"라는 용어가 언급되었지만, 컴퓨터는 휴대폰들, 휴대용 MP3 플레이어들, 비디오 게임 콘솔들, 노트북 컴퓨터들, 포켓 컴퓨터들, 또는 적절한 프로세싱, 통신 및 입/출력 능력을 갖는 임의의 다른 디바이스와 같은 휴대용 디바이스들을 포함할 수 있다는 것이 이해될 것이다.
결론
게이트웨이 서버 적응형 비트 레이트 트랜스코더 제어 알고리즘이 DLNA 미디어 스트리밍 응용들에 대해 설명되었다. 다수의 서버측 네트워크 대역폭 측정 알고리즘들이 설명되었으며, 이러한 알고리즘들 중 하나를 사용하는 트랜스코더 비디오 비트 레이트 제어 구현이 설계되고 테스트되었다. 라이브 네트워크들에서 추가 테스트를 수행하면 결과적으로 제어 알고리즘에 구축되는 파라미터들 및 임계치들을 튜닝하게 될 것이다.
이상으로 본 발명의 바람직한 실시예들의 설명을 마친다. 본 발명의 바람직한 실시예의 전술한 설명은 예시 및 설명의 목적으로 제시되었다. 이는 본 발명을 개시된 정확한 형태로 제한하거나 포괄적인 것으로 의도하지 않는다. 상기 교시에 비추어 많은 수정들 및 변형들이 가능하다.
본 발명의 범위는 이 상세한 설명에 의해서가 아니라, 본 명세서에 첨부된 청구 범위에 의해 한정되는 것으로 의도된다. 상기 명세서, 예들 및 데이터는 본 발명의 장치 및 방법의 제조 및 사용에 대한 완전한 설명을 제공한다. 본 발명의 많은 실시예들이 본 발명의 범위를 벗어나지 않고도 이루어질 수 있기 때문에, 본 발명은 이하 첨부된 청구 범위에 속한다.
Claims (20)
- 스트리밍 비디오 데이터를 미디어 비디오 플레이어 클라이언트로 적응적으로 송신(adaptively transmitting)하는 방법으로서,
서버에서, 상기 미디어 비디오 플레이어 클라이언트로부터 비디오 데이터 자산(data asset)에 대한 요청을 수신하는 단계;
초기 트랜스코딩 파라미터들(initial transcoding parameters)에 따라 상기 비디오 데이터 자산의 일부를 상기 서버에서 트랜스코딩하는 단계;
통신 채널을 통해 상기 서버로부터 상기 미디어 비디오 플레이어 클라이언트로 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부를 송신하는 단계;
상기 미디어 비디오 플레이어 클라이언트에 의한 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신을 확인응답하는 정보로부터 상기 통신 채널의 대역폭의 추정치를 상기 서버에서 생성하는 단계 - 상기 대역폭의 추정치는, 상기 비디오 데이터 자산의 상기 송신되는 트랜스코딩된 일부의 왕복 시간(round trip time)(RTT) 및 상기 비디오 데이터 자산의 상기 송신되는 트랜스코딩된 일부의 사이즈에 따라 생성되고, 상기 RTT는, 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 송신의 개시와 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신의 확인응답의 수신 사이의 경과 시간임 -;
상기 통신 채널의 상기 대역폭의 추정치로부터 적응형 트랜스코딩 파라미터들(adaptive transcoding parameters)을 생성하는 단계 - 상기 추정치는 상기 서버에서 생성됨 -;
상기 적응형 트랜스코딩 파라미터들에 따라 상기 비디오 데이터 자산의 시간적으로 후속하는 추가 부분을 트랜스코딩하는 단계; 및
상기 서버로부터 상기 미디어 비디오 플레이어 클라이언트로 상기 비디오 데이터 자산의 상기 추가 부분을 송신하는 단계 - 상기 대역폭의 추정치는 이전의 타이머 이벤트로부터 타이머 인터벌 TAF만큼 시간적으로 분리된 타이머 이벤트에서 계산되고,
상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 송신의 개시와 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신의 확인응답의 수신 사이의 경과 시간은 TAF - TlastACKrecv로서 계산되고,
여기서, TlastACKrecv는, 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신의 가장 최근의 확인응답의 클록 시간과 가장 최근의 타이머 이벤트의 클록 시간 사이의 시간임 -
를 포함하는 방법. - 삭제
- 삭제
- 제1항에 있어서,
상기 비디오 데이터 자산의 송신되는 트랜스코딩된 일부의 양은 prevDataRemaining + socketDataSent - DataRemaining에 따라 결정되고,
여기서, socketDataSent는 상기 타이머 이벤트에서 상기 서버의 전송 제어 프로토콜(TCP) 전송 소켓 버퍼로 전달되는 상기 비디오 데이터 자산의 양이고,
DataRemaining은 상기 타이머 이벤트 직후의 타이머 인터벌에서 상기 TCP 전송 소켓 버퍼에 남아있는 전송되지 않은 비디오 데이터 자산의 양이고,
prevDataRemaining은 이전의 타이머 인터벌 이후에 상기 TCP 전송 소켓 버퍼에 남아있는 상기 비디오 데이터 자산의 양인 방법. - 제4항에 있어서,
상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 송신의 개시와 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신의 확인응답의 수신 사이의 경과 시간은,
DataRemaining이 0인 경우에는, currentTime - lastSendTime - TlastACKrecv 이고,
DataRemaining이 0이 아닌 경우에는, currentTime - lastSendTime이고,
여기서, currentTime은 상기 타이머 인터벌의 가장 최근의 만료 시의 클록 시간이고, lastSendTime은 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부가 상기 TCP 전송 소켓 버퍼로 전달된 클록 시간인 방법. - 제5항에 있어서,
상기 통신 채널의 상기 생성되는 추정된 대역폭을 클램핑 값으로 클램핑하는 단계를 추가로 포함하는 방법. - 제6항에 있어서,
상기 통신 채널의 상기 추정된 대역폭을 필터링하는 단계를 추가로 포함하는 방법. - 제7항에 있어서,
상기 통신 채널의 상기 추정된 대역폭을 스케일링하는 단계를 추가로 포함하는 방법. - 제8항에 있어서,
상기 통신 채널의 상기 대역폭의 추정치로부터 적어도 부분적으로 적응형 코딩 파라미터들을 생성하는 단계는,
상기 대역폭의 추정치에 따라 트랜스코더 비트 레이트 커맨드(transcoder bit rate command)를 생성하는 단계;
상기 트랜스코더 비트 레이트 커맨드를 저역 통과 필터링하는 단계 - 상기 트랜스코더 비트 레이트 커맨드는 상기 트랜스코더 비트 레이트 커맨드에서의 증가들보다 상기 트랜스코더 비트 레이트 커맨드에서의 더 빠른 감소들을 허용하도록 비대칭적으로 필터링됨 -; 및
상기 저역 통과 필터링된 트랜스코더 비트 레이트 커맨드를 양자화하는 단계
를 포함하는 방법. - 제9항에 있어서,
상기 트랜스코더 비트 레이트 커맨드에서의 증가들은, N개의 연속적인 출력 비트 레이트 커맨드들 각각이 이전의 출력 비트 레이트 커맨드보다 클 때까지 지연되는 방법. - 제1항에 있어서,
상기 대역폭의 추정치는 이전의 타이머 이벤트로부터 타이머 인터벌 TAF만큼 시간적으로 분리된 타이머 이벤트에서 계산되고,
상기 통신 채널을 통해 상기 서버로부터 상기 미디어 비디오 플레이어 클라이언트로 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부를 송신하는 단계는,
타이머 이벤트에서 상기 트랜스코딩된 세그먼트의 제1 프래그먼트를 트랜스코더 출력 버퍼로부터 TCP 전송 소켓 버퍼로 전송하는 단계; 및
상기 트랜스코딩된 세그먼트의 상기 제1 프래그먼트의 적어도 일부를 상기 통신 채널을 통해 상기 TCP 전송 소켓 버퍼로부터 상기 미디어 비디오 플레이어 클라이언트로 송신하는 단계
를 포함하고,
상기 미디어 비디오 플레이어 클라이언트에 의한 상기 비디오 데이터 자산의 상기 트랜스코딩된 세그먼트의 수신을 확인응답하는 정보로부터 적어도 부분적으로 상기 통신 채널의 대역폭의 추정치를 생성하는 단계는, dataRemaining=0인 경우에는에 따라 그리고 dataRemaining≠0인 경우에는
에 따라, 상기 타이머 인터벌 TAF에서 상기 대역폭의 추정치를 계산하는 단계를 포함하고,
여기서, socketDataSent는 상기 타이머 인터벌에서 상기 트랜스코더 출력 버퍼로부터 상기 TCP 전송 소켓 버퍼로 전송되는 상기 트랜스코딩된 세그먼트의 상기 제1 프래그먼트의 데이터의 양을 나타내고,
dataRemaining은 상기 타이머 인터벌에서 상기 TCP 전송 소켓 버퍼에 남아있는 상기 트랜스코딩된 세그먼트의 상기 제1 프래그먼트의 데이터의 양을 나타내고,
Nempty는 상기 TCP 전송 소켓 버퍼에 남아있는 바이트 수가 0일 때의 시간과 가장 최근의 타이머 인터벌 사이의 통지 시간 인터벌 TTB의 수를 나타내고,
previousDataRemaining은 시간적으로 인접하게 이전의 타이머 인터벌에서 상기 TCP 전송 소켓 버퍼에 있는 데이터의 양을 나타내는 방법. - 스트리밍 비디오 데이터를 비디오 미디어 플레이어 클라이언트로 송신하기 위한 서버를 형성하는 장치로서,
메모리에 통신가능하게 결합된 프로세서
를 포함하고,
상기 메모리는,
서버에서, 상기 비디오 미디어 플레이어 클라이언트로부터 비디오 데이터 자산에 대한 요청을 수신하고;
초기 트랜스코딩 파라미터들에 따라 상기 비디오 데이터 자산의 일부를 트랜스코딩하고;
통신 채널을 통해 상기 서버로부터 상기 비디오 미디어 플레이어 클라이언트로 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부를 송신하고;
상기 비디오 미디어 플레이어 클라이언트에 의한 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신을 확인응답하는 정보로부터 상기 통신 채널의 대역폭의 추정치를 생성하고 - 상기 대역폭의 추정치는, 상기 비디오 데이터 자산의 상기 송신되는 트랜스코딩된 일부의 왕복 시간(RTT) 및 상기 비디오 데이터 자산의 상기 송신되는 트랜스코딩된 일부의 사이즈에 따라 생성되고, 상기 RTT는, 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 송신의 개시와 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신의 확인응답의 수신 사이의 경과 시간임 -;
상기 통신 채널의 상기 대역폭의 추정치로부터 적응형 트랜스코딩 파라미터들을 생성하고 - 상기 추정치는 상기 서버에서 생성됨 -;
상기 적응형 트랜스코딩 파라미터들에 따라 상기 비디오 데이터 자산의 시간적으로 후속하는 추가 부분을 트랜스코딩하고;
상기 서버로부터 상기 비디오 미디어 플레이어 클라이언트로 상기 비디오 데이터 자산의 상기 추가 부분을 송신 - 상기 대역폭의 추정치는 이전의 타이머 이벤트로부터 타이머 인터벌 TAF만큼 시간적으로 분리된 타이머 이벤트에서 계산되고,
상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 송신의 개시와 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신의 확인응답의 수신 사이의 경과 시간은 TAF - TlastACKrecv로서 계산되고,
여기서, TlastACKrecv는, 상기 비디오 데이터 자산의 상기 트랜스코딩된 일부의 수신의 가장 최근의 확인응답의 클록 시간과 가장 최근의 타이머 이벤트의 클록 시간 사이의 시간임 - 하기 위한
프로세서 명령어들을 포함하는 프로세싱 명령어들을 저장하는, 장치. - 삭제
- 삭제
- 제12항에 있어서,
상기 비디오 데이터 자산의 상기 송신되는 트랜스코딩된 일부의 양은 prevDataRemaining + socketDataSent - DataRemaining에 따라 결정되고,
여기서, socketDataSent는 상기 타이머 이벤트에서 상기 서버의 전송 제어 프로토콜(TCP) 전송 소켓 버퍼로 전달되는 상기 비디오 데이터 자산의 양이고,
DataRemaining은 상기 타이머 이벤트 직후의 타이머 인터벌에서 상기 TCP 전송 소켓 버퍼에 남아있는 전송되지 않은 비디오 데이터 자산의 양이고,
prevDataRemaining은 이전의 타이머 인터벌 이후에 상기 TCP 전송 소켓 버퍼에 남아있는 상기 비디오 데이터 자산의 양인 장치. - 삭제
- 삭제
- 삭제
- 삭제
- 삭제
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201562100934P | 2015-01-08 | 2015-01-08 | |
| US62/100,934 | 2015-01-08 | ||
| PCT/US2016/012655 WO2016112294A1 (en) | 2015-01-08 | 2016-01-08 | Server-side adaptive bit rate control for dlna http streaming clients |
| US14/991,091 US10044466B2 (en) | 2015-01-08 | 2016-01-08 | Server-side adaptive bit rate control for DLNA HTTP streaming clients |
| US14/991,091 | 2016-01-08 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20170103869A KR20170103869A (ko) | 2017-09-13 |
| KR101942208B1 true KR101942208B1 (ko) | 2019-01-24 |
Family
ID=55487028
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020177021800A KR101942208B1 (ko) | 2015-01-08 | 2016-01-08 | Dlna http 스트리밍 클라이언트들을 위한 서버측 적응형 비트 레이트 제어 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US10044466B2 (ko) |
| KR (1) | KR101942208B1 (ko) |
| CA (1) | CA2973101A1 (ko) |
| MX (1) | MX362448B (ko) |
| WO (1) | WO2016112294A1 (ko) |
Families Citing this family (44)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015077983A1 (zh) * | 2013-11-29 | 2015-06-04 | 华为终端有限公司 | 在家庭网络中播放媒体的装置和方法 |
| EP3262523B1 (en) | 2015-02-27 | 2019-12-04 | DivX, LLC | System and method for frame duplication and frame extension in live video encoding and streaming |
| US10180947B2 (en) * | 2015-04-29 | 2019-01-15 | Box, Inc. | File-agnostic data downloading in a virtual file system for cloud-based shared content |
| US20160360206A1 (en) * | 2015-06-04 | 2016-12-08 | Microsoft Technology Licensing, Llc | Rate controller for real-time encoding and transmission |
| US10554713B2 (en) * | 2015-06-19 | 2020-02-04 | Microsoft Technology Licensing, Llc | Low latency application streaming using temporal frame transformation |
| US10164893B2 (en) * | 2015-08-19 | 2018-12-25 | Samsung Electronics Co., Ltd. | Data transfer apparatus, data transfer controlling method and data stream |
| JP2017079412A (ja) * | 2015-10-20 | 2017-04-27 | 富士通株式会社 | パケット解析プログラム、パケット解析装置およびパケット解析方法 |
| US20170171568A1 (en) * | 2015-12-14 | 2017-06-15 | Le Holdings (Beijing) Co., Ltd. | Method and device for processing live video |
| US10791162B2 (en) * | 2015-12-31 | 2020-09-29 | Hughes Network Systems, Llc | Maximizing quality of service for QoS adaptive video streaming via dynamic application-layer throughput rate shaping |
| US10390071B2 (en) * | 2016-04-16 | 2019-08-20 | Ittiam Systems (P) Ltd. | Content delivery edge storage optimized media delivery to adaptive bitrate (ABR) streaming clients |
| US10389775B2 (en) * | 2016-05-20 | 2019-08-20 | Hughes Network Systems, Llc | Multicast aggregation of multiple streaming connections |
| WO2017218522A1 (en) * | 2016-06-13 | 2017-12-21 | Arris Enterprises Llc | Reduction of startup time in remote hls clients |
| WO2018017839A1 (en) * | 2016-07-20 | 2018-01-25 | Arris Enterprises Llc | Video and data multiplexing in an adaptive bitrate server |
| US10277540B2 (en) * | 2016-08-11 | 2019-04-30 | Jurni Inc. | Systems and methods for digital video journaling |
| US10116989B1 (en) | 2016-09-12 | 2018-10-30 | Twitch Interactive, Inc. | Buffer reduction using frame dropping |
| US10015224B1 (en) * | 2016-09-12 | 2018-07-03 | Twitch Interactive, Inc. | Buffer reduction using frame dropping |
| US10511533B2 (en) | 2016-10-28 | 2019-12-17 | Level 3 Communications, Llc | Systems and methods for adjusting a congestion window value of a content delivery network |
| US10412110B2 (en) | 2016-10-31 | 2019-09-10 | Acentium, Inc. | Systems and methods for multi-tier cache visual system and visual modes |
| US10158654B2 (en) * | 2016-10-31 | 2018-12-18 | Acentium Inc. | Systems and methods for computer environment situational awareness |
| US10284589B2 (en) | 2016-10-31 | 2019-05-07 | Acentium Inc. | Methods and systems for ranking, filtering and patching detected vulnerabilities in a networked system |
| US10499411B2 (en) * | 2016-11-04 | 2019-12-03 | Mediatek Inc. | Method and apparatus for data transmission enhancements in mobile communications |
| US11444887B2 (en) | 2017-03-08 | 2022-09-13 | Arris Enterprises Llc | Excess bitrate distribution based on quality gain in sabr server |
| US10645437B2 (en) * | 2017-04-03 | 2020-05-05 | Sling Media Pvt Ltd | Systems and methods for achieving optimal network bitrate |
| US11659057B2 (en) * | 2017-04-19 | 2023-05-23 | Comcast Cable Communications, Llc | Methods and systems for content delivery using server push |
| KR102307447B1 (ko) * | 2017-05-02 | 2021-09-30 | 삼성전자주식회사 | 네트워크 환경 모니터링에 기반하는 http 적응적 스트리밍 서버, 방법, 및 클라이언트 단말 |
| CN109309934B (zh) * | 2017-07-27 | 2021-01-15 | 华为技术有限公司 | 一种拥塞控制方法及相关设备 |
| US10911813B1 (en) * | 2017-08-30 | 2021-02-02 | Amazon Technologies, Inc. | Providing metadata for live media streams |
| TW201924285A (zh) * | 2017-10-06 | 2019-06-16 | 日商日本電氣股份有限公司 | 資料通信裝置、通信系統、資料通信方法及程式 |
| TW201924309A (zh) * | 2017-10-06 | 2019-06-16 | 日商日本電氣股份有限公司 | 資料通信裝置、通信系統、資料通信方法及程式 |
| CN108021433B (zh) * | 2017-12-01 | 2021-03-19 | 中国人民解放军国防科技大学 | 一种多星星簇的目标观测方法 |
| US10924812B2 (en) * | 2018-02-15 | 2021-02-16 | Cisco Technology, Inc. | Constant quality video encoding with encoding parameter fine-tuning |
| CN112106369B (zh) * | 2018-04-06 | 2024-08-13 | 艾锐势有限责任公司 | 减少双向时间预测中的运动矢量信息传输 |
| US10182269B1 (en) * | 2018-04-24 | 2019-01-15 | Verizon Patent And Licensing Inc. | HTTP live streaming delivery over multicast |
| US10728305B2 (en) * | 2018-07-24 | 2020-07-28 | At&T Intellectual Property I, L.P. | Adaptive bitrate streaming techniques |
| US10728630B2 (en) * | 2018-07-24 | 2020-07-28 | At&T Intellectual Property I, L.P. | Adaptive bitrate streaming techniques |
| US10728588B2 (en) * | 2018-07-24 | 2020-07-28 | At&T Intellectual Property I, L.P. | Adaptive bitrate streaming techniques |
| WO2020040741A1 (en) * | 2018-08-21 | 2020-02-27 | Rovi Guides, Inc. | Systems and methods for real-time adaptive bitrate transcoding and transmission of transcoded media |
| EP3633999A1 (en) | 2018-10-05 | 2020-04-08 | InterDigital CE Patent Holdings | Method to be implemented at a device able to run one adaptive streaming session, and corresponding device |
| DE102018131617B4 (de) * | 2018-12-10 | 2023-03-30 | Bayerische Motoren Werke Aktiengesellschaft | Verfahren zum Streamen von Datenpaketen zwischen einem Sender und wenigstens einem Empfänger über ein Mobilfunknetzwerk |
| US11128739B2 (en) * | 2018-12-24 | 2021-09-21 | Verizon Patent And Licensing Inc. | Network-edge-deployed transcoding methods and systems for just-in-time transcoding of media data |
| US11695703B2 (en) * | 2019-05-14 | 2023-07-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Multi-timescale packet marker |
| US11190448B2 (en) * | 2019-11-26 | 2021-11-30 | Verizon Patent And Licensing Inc. | Transport congestion control optimization based on network context |
| ES2940452T3 (es) * | 2020-04-27 | 2023-05-08 | Broadpeak | Procedimiento y servidor para la distribución de contenido de audio y/o vídeo |
| EP4009650A1 (en) * | 2020-12-03 | 2022-06-08 | Anevia | Method for media stream processing and apparatus for implementing the same |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140089469A1 (en) * | 2012-09-24 | 2014-03-27 | Motorola Mobility Llc | Methods and devices for efficient adaptive bitrate streaming |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7444418B2 (en) | 2001-05-11 | 2008-10-28 | Bytemobile, Inc. | Transcoding multimedia information within a network communication system |
| US7299280B2 (en) * | 2001-10-17 | 2007-11-20 | The Regents Of University Of California | Method and apparatus for TCP with faster recovery |
| US8150995B2 (en) * | 2005-09-30 | 2012-04-03 | Microsoft Corporation | Receive window auto-tuning |
| US8788695B2 (en) | 2011-06-15 | 2014-07-22 | Allot Communications Ltd. | Method and apparatus for session bandwidth estimation and rate control |
| US9548936B2 (en) * | 2011-06-30 | 2017-01-17 | The Chinese University Of Hong Kong | Method and system for improved TCP performance over mobile data networks |
| US9137551B2 (en) * | 2011-08-16 | 2015-09-15 | Vantrix Corporation | Dynamic bit rate adaptation over bandwidth varying connection |
| US9124672B2 (en) | 2012-11-08 | 2015-09-01 | Morega Systems, Inc | Adaptive video server with data rate control and methods for use therewith |
| WO2015200613A1 (en) * | 2014-06-26 | 2015-12-30 | Arris Enterprises, Inc. | Server side adaptive bit rate control for http streaming clients |
-
2016
- 2016-01-08 CA CA2973101A patent/CA2973101A1/en not_active Abandoned
- 2016-01-08 WO PCT/US2016/012655 patent/WO2016112294A1/en active Application Filing
- 2016-01-08 US US14/991,091 patent/US10044466B2/en active Active
- 2016-01-08 MX MX2017008922A patent/MX362448B/es active IP Right Grant
- 2016-01-08 KR KR1020177021800A patent/KR101942208B1/ko active IP Right Grant
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140089469A1 (en) * | 2012-09-24 | 2014-03-27 | Motorola Mobility Llc | Methods and devices for efficient adaptive bitrate streaming |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2016112294A1 (en) | 2016-07-14 |
| MX2017008922A (es) | 2017-10-11 |
| US20160205164A1 (en) | 2016-07-14 |
| US10044466B2 (en) | 2018-08-07 |
| CA2973101A1 (en) | 2016-07-14 |
| MX362448B (es) | 2019-01-18 |
| KR20170103869A (ko) | 2017-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101942208B1 (ko) | Dlna http 스트리밍 클라이언트들을 위한 서버측 적응형 비트 레이트 제어 | |
| US11563788B2 (en) | Multipath data streaming over multiple networks | |
| US10129316B2 (en) | Server side adaptive bit rate control for HTTP streaming clients | |
| CN103828324B (zh) | 用于自适应比特率管理的方法、设备和系统 | |
| AU2020201920B2 (en) | Multipath data streaming over multiple wireless networks | |
| US20140282792A1 (en) | Video streaming with buffer occupancy prediction based quality adaptation | |
| AU2021200428B2 (en) | System and method for automatic encoder adjustment based on transport data | |
| WO2014110670A1 (en) | Media server | |
| EP3228035A1 (en) | Server-side adaptive bit rate control for dlna http streaming clients | |
| Luthra et al. | Server-Based Smart Adaptive Bit Rate (SABR) Streaming With Statistical Multiplexing |
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 |