KR20170018458A - 화상 전화에서의 지연 감소 - Google Patents

화상 전화에서의 지연 감소 Download PDF

Info

Publication number
KR20170018458A
KR20170018458A KR1020177002609A KR20177002609A KR20170018458A KR 20170018458 A KR20170018458 A KR 20170018458A KR 1020177002609 A KR1020177002609 A KR 1020177002609A KR 20177002609 A KR20177002609 A KR 20177002609A KR 20170018458 A KR20170018458 A KR 20170018458A
Authority
KR
South Korea
Prior art keywords
rate
data
network link
bit rate
recovery
Prior art date
Application number
KR1020177002609A
Other languages
English (en)
Other versions
KR101727450B1 (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 KR20170018458A publication Critical patent/KR20170018458A/ko
Application granted granted Critical
Publication of KR101727450B1 publication Critical patent/KR101727450B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/141Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894Packet rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416Real-time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • 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
    • 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
    • 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/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347Demultiplexing of several video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/141Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/148Interfacing a video terminal to a particular transmission medium, e.g. ISDN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • H04N7/152Multipoint control units therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/0864Round trip delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/16Threshold monitoring
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/50Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Environmental & Geological Engineering (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Telephonic Communication Services (AREA)

Abstract

일 예에서, 데이터를 처리하는 방법은 제 1 비트 레이트로 네트워크를 통해 데이터를 송신하는 단계, 제 1 네트워크 링크 레이트에서 제 2 네트워크 링크 레이트로 네트워크의 네트워크 링크 레이트의 감소를 식별하는 단계, 및 네트워크 링크 레이트의 감소에 응답하여, 네트워크를 통해 데이터를 송신할 복구 비트 레이트를 결정하는 단계를 포함하고, 복구 비트 레이트는 제 2 네트워크 링크 레이트보다 작다. 상기 방법은 또한 네트워크 링크 레이트의 감소를 식별하는 시간과 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하는 단계, 및 복구 비트 레이트 및 버퍼링 지속시간에 기초한 복구 비트 레이트로 데이터를 송신할 복구 레이트 지속시간을 결정하는 단계를 포함한다.

Description

화상 전화에서의 지연 감소{REDUCING DELAY IN VIDEO TELEPHONY}
본원은 2014년 7월 29일자로 출원된 미국 가출원 제62/030,513호의 혜택을 주장하며, 이의 전체 내용은 참조에 의해 본원에 원용된다.
기술 분야
본 개시는 비디오 데이터의 처리에 관한 것이다.
화상 전화 (VT) 는 오디오 및 비디오 데이터를 전하는 패킷의 실시간 통신을 수반한다. VT 디바이스는, 비디오 캡처 디바이스, 이를테면 비디오 카메라 또는 비디오 아카이브로부터 비디오를 획득하여 비디오 패킷을 생성하는 비디오 인코더를 포함한다. 마찬가지로, VT 디바이스에 있는 오디오 인코더는 오디오 캡처 디바이스, 이를테면 마이크로폰 또는 음성 합성기로부터 오디오를 획득하여 오디오 패킷을 생성한다. 비디오 패킷 및 오디오 패킷은 무선 링크 프로토콜 (RLP) 큐에 놓인다. 매체 액세스 제어 (MAC) 계층 유닛은 RLP 큐의 내용으로부터 매체 액세스 제어 (MAC) 계층 패킷을 생성한다. MAC 계층 패킷은 통신 채널을 통해 다른 VT 디바이스로 송신하기 위해 물리 (PHY) 계층 패킷으로 변환된다.
이동 VT 애플리케이션에서, VT 디바이스는 기지국으로부터 무선 단말기로서 VT 디바이스까지 무선 순방향 링크 (FL) (또는 "다운링크") 를 통해 물리 계층 패킷을 수신한다. VT 디바이스는 PHY 계층 패킷을 무선 역방향 링크 (RL) (또는 "업링크") 를 통해 기지국에 송신한다. 각 VT 디바이스는, 수신된 PHY 및 MAC 계층 패킷을 변환하고 패킷 페이로드를 오디오 패킷 및 비디오 패킷으로 리어셈블 (reassemble) 하기 위한 PHY 및 MAC 계층을 포함한다. VT 디바이스 내의 비디오 디코더는 디스플레이 디바이스를 통해 사용자에게 제시하기 위해 비디오 데이터를 디코딩한다. VT 디바이스 내의 오디오 디코더는 오디오 스피커를 통해 출력하기 위해 오디오 데이터를 디코딩한다.
개요
본 개시의 기술은 네트워크 상태 (network conditions) 에 기초하여 데이터를 인코딩하기 위한 비트 레이트를 결정하는 것에 관한 것이다. 예를 들어, 본 개시의 양태들은 네트워크 링크 레이트의 감소에 응답하여 제 1 레이트에서 제 2 레이트로 전송 비트 레이트 (레이트로도 간단히 언급됨) 를 감소시키는 것에 관한 것이다. 본 개시의 양태들에 따르면, 네트워크 링크 레이트의 감소를 식별할 때, 전송기 디바이스는 제 2 네트워크 링크 레이트보다 낮은, 예를 들어, 예를 들어 제 2 네트워크 링크 레이트에 언더슈트 (undershoot) 하는, 감소된 레이트로 전송 레이트를 감소시킬 수도 있다. 전송기 디바이스는, 감소된 레이트에 기초하고 네트워크 링크 레이트의 감소를 식별하는 것과 데이터가 전송기 디바이스에서 또는 네트워크와 연관된 다른 디바이스에서 버퍼링되는 네트워크 링크 레이트의 감소에 반응하는 것 사이의 지속시간에 기초한 기간 (time period) 동안 감소된 레이트로 전송 레이트를 유지할 수도 있다. 이러한 방식으로, 전송기 디바이스는 사용자 경험에 지나치게 영향을 미치지 않으면서 상대적으로 신속하게 네트워크 링크 레이트의 하락 동안 버퍼링된 데이터 량을 감소시킬 수도 있다.
본 개시의 양태들은 또한 네트워크 링크 레이트가 완전히 이용되지 않는 경우에 전송 레이트를 증가시키는 것에 관한 것이다. 예를 들어, 본 개시의 양태들에 따르면, 수신기 디바이스는 데이터가 플레이아웃되도록 스케줄링되는 시간 전에 수신기 디바이스에서 수신되는 데이터에 기초하여 네트워크 링크 레이트가 충분히 활용되지 않았다고 결정할 수도 있다. 수신기 디바이스는 데이터가 수신되는 시간과 데이터가 플레이아웃되도록 스케줄링되는 시간 사이의 시간의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정할 수도 있다. 수신기 디바이스는 허용 가능한 초과 지연 파라미터에 따라 전송 레이트 증가를 결정할 수도 있다. 수신기 디바이스는, 일부 경우에, 전송기 디바이스에 전송 레이트 증가의 표시를 송신하여, 전송기 디바이스는 네트워크 링크 레이트를 초과하지 않으면서 네트워크 링크 레이트를 더 잘 이용할 수도 있다.
일 예에서, 데이터를 처리하는 방법은 제 1 비트 레이트로 네트워크를 통해 데이터를 송신하는 단계, 제 1 네트워크 링크 레이트에서 제 2 네트워크 링크 레이트로 네트워크의 네트워크 링크 레이트의 감소를 식별하는 단계, 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트 (recovery bit rate) 를 결정하는 단계로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하는 단계, 네트워크 링크 레이트의 감소를 식별하는 시간과 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하는 단계, 및 복구 비트 레이트 및 버퍼링 지속시간에 기초하여 데이터를 상기 복구 비트 레이트로 송신할 복구 레이트 지속시간을 결정하는 단계를 포함한다.
다른 예에서, 데이터를 처리하기 위한 디바이스는 데이터를 저장하도록 구성된 메모리 및 하나 이상의 프로세서들을 포함하고, 상기 하나 이상의 프로세서들은 제 1 비트 레이트로 네트워크를 통해 데이터를 송신하고, 제 1 네트워크 링크 레이트에서 제 2 네트워크 링크 레이트로 네트워크의 네트워크 링크 레이트의 감소를 식별하고, 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트를 결정하는 것으로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하고, 네트워크 링크 레이트의 감소를 식별하는 시간과 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하고, 그리고 복구 비트 레이트 및 버퍼링 지속시간에 기초하여 데이터를 상기 복구 비트 레이트로 송신할 복구 레이트 지속시간을 결정하도록 구성된다.
다른 예에서, 데이터를 처리하기 위한 장치는, 제 1 비트 레이트로 네트워크를 통해 데이터를 송신하는 수단, 제 1 네트워크 링크 레이트에서 제 2 네트워크 링크 레이트로 네트워크의 네트워크 링크 레이트의 감소를 식별하는 수단, 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트를 결정하는 수단로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하는 수단, 네트워크 링크 레이트의 감소를 식별하는 시간과 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하는 수단, 및 복구 비트 레이트 및 버퍼링 지속시간에 기초하여 데이터를 상기 복구 비트 레이트로 송신할 복구 레이트 지속시간을 결정하는 수단을 포함한다.
다른 예에서, 비일시적 컴퓨터 판독가능 매체는 저장된 명령들을 갖고, 그 명령들은 실행될 때, 하나 이상의 프로세서들로 하여금, 제 1 비트 레이트로 네트워크를 통해 데이터를 송신하게 하고, 제 1 네트워크 링크 레이트에서 제 2 네트워크 링크 레이트로 네트워크의 네트워크 링크 레이트의 감소를 식별하게 하고, 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트를 결정하게 하는 것으로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하게 하고, 네트워크 링크 레이트의 감소를 식별하는 시간과 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하게 하고, 그리고 복구 비트 레이트 및 버퍼링 지속시간에 기초하여 데이터를 상기 복구 비트 레이트로 송신할 복구 레이트 지속시간을 결정하게 하도록 구성된다.
다른 예에서, 데이터를 처리하는 방법은, 수신기 디바이스에 의해, 수신된 데이터가 수신기 디바이스에 의해 수신되는 시간과 수신된 데이터가 플레이아웃되도록 스케줄링된 시간 사이의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정하는 단계로서, 상기 허용 가능한 초과 지연 파라미터는 전송기 디바이스와 수신기 디바이스 사이의 채널에 의해 지원 가능한 지연 량을 나타내는, 상기 허용 가능한 초과 지연 파라미터를 결정하는 단계, 수신기 디바이스에 의해, 결정된 허용 가능한 초과 지연 파라미터에 기초하여 전송기 디바이스로부터 수신기 디바이스로 데이터가 전송될 비트 레이트를 증가시키기 위한 전송기 비트 레이트 증가를 결정하는 단계, 및 전송기 비트 레이트 증가의 표시를 전송기 디바이스에 송신하는 단계를 포함한다.
다른 예에서, 데이터를 처리하기 위한 수신기 디바이스는 데이터를 저장하도록 구성된 메모리, 및 하나 이상의 프로세서들을 포함하고, 상기 하나 이상의 프로세서들은, 데이터가 수신기 디바이스에 의해 수신되는 시간과 데이터가 플레이아웃되도록 스케줄링된 시간 사이의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정하는 것으로서, 상기 허용 가능한 초과 지연 파라미터는 전송기 디바이스와 수신기 디바이스 사이의 채널에 의해 지원 가능한 지연 량을 나타내는, 상기 허용 가능한 초과 지연 파라미터를 결정하고, 결정된 허용 가능한 초과 지연 파라미터에 기초하여 전송기 디바이스로부터 수신기 디바이스로 데이터가 전송될 비트 레이트를 증가시키기 위한 전송기 비트 레이트 증가를 결정하고, 및 전송기 비트 레이트 증가의 표시를 전송기 디바이스에 송신하도록 구성된다.
다른 예에서, 데이터를 처리하기 위한 장치는, 수신된 데이터가 수신기 디바이스에 의해 수신되는 시간과 수신된 데이터가 플레이아웃되도록 스케줄링된 시간 사이의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정하는 수단으로서, 상기 허용 가능한 초과 지연 파라미터는 전송기 디바이스와 수신기 디바이스 사이의 채널에 의해 지원 가능한 지연 량을 나타내는, 상기 허용 가능한 초과 지연 파라미터를 결정하는 수단, 결정된 허용 가능한 초과 지연 파라미터에 기초하여 전송기 디바이스로부터 수신기 디바이스로 데이터가 전송될 비트 레이트를 증가시키기 위한 전송기 비트 레이트 증가를 결정하는 수단, 및 전송기 비트 레이트 증가의 표시를 전송기 디바이스에 송신하는 수단을 포함한다.
다른 예에서, 비일시적 컴퓨터 판독가능 매체는 저장된 명령들을 갖고, 상기 명령들은 실행될 때, 하나 이상의 프로세서들로 하여금, 수신된 데이터가 수신기 디바이스에 의해 수신되는 시간과 수신된 데이터가 플레이아웃되도록 스케줄링된 시간 사이의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정하는 것으로서, 상기 허용 가능한 초과 지연 파라미터는 전송기 디바이스와 수신기 디바이스 사이의 채널에 의해 지원 가능한 지연 량을 나타내는, 상기 허용 가능한 초과 지연 파라미터를 결정하고, 결정된 허용 가능한 초과 지연 파라미터에 기초하여 전송기 디바이스로부터 수신기 디바이스로 데이터가 전송될 비트 레이트를 증가시키기 위한 전송기 비트 레이트 증가를 결정하고, 및 전송기 비트 레이트 증가의 표시를 전송기 디바이스에 송신하도록 구성된다.
본 개시의 하나 이상의 예들의 상세들은 첨부 도면 및 아래의 설명에 제시되어 있다. 다른 특징, 목적 및 이점들은 상세한 설명, 도면, 및 청구항들로부터 분명해질 것이다.
도 1은 화상 전화 (VT) 애플리케이션을 위한 오디오/비디오 인코딩 및 디코딩 시스템을 나타내는 블록도이다.
도 2는 본 개시의 기술들과 일치하는 비디오 소스 레이트 적응화를 구현할 수도 있는 비디오 인코딩 시스템을 나타내는 블록도이다.
도 3은 본 개시의 기술들과 일치하는 비디오 소스 레이트 적응화를 구현할 수도 있는 비디오 디코딩 시스템을 나타내는 블록도이다.
도 4a 및 도 4b는 본 개시의 기술과 일치하는 비디오 소스 레이트 적응화 기술을 나타내는 그래프이다.
도 5 는 본 개시의 기술과 일치하는 버퍼링 지속시간의 결정을 나타내는 개념도이다.
도 6a 및 도 6b 는 각각 네트워크 링크 레이트 하락 및 대응 지연 시간을 나타내는 그래프이다.
도 7a 및 도 7b 는 각각 네트워크 링크 레이트 하락 및 대응 지연 시간을 나타내는 그래프이다.
도 8 은 본 개시의 기술들과 일치하는, 데이터가 송신되는 레이트를 다운 스위칭 (down-switching) 하기 위한 예시적인 프로세스를 나타내는 흐름도이다.
도 9 은 본 개시의 기술들과 일치하는, 데이터가 송신되는 레이트를 업 스위칭 (up-switching) 하기 위한 예시적인 프로세스를 나타내는 흐름도이다.
상세한 설명
화상 전화 (VT) 디바이스는 유선 또는 무선 네트워크를 통해 VT 세션 (예를 들어, VT 디바이스 간의 오디오 및/또는 비디오 데이터의 송신) 을 수행하기 위해 접속될 수도 있다. 다른 VT 디바이스로 송신하기 위해 오디오 및/또는 비디오 데이터를 처리하고 있는 VT 디바이스는 전송기 디바이스로 지칭될 수도 있다. 마찬가지로, (VT 디바이스의 사용자에 제시하기 위해) 수신된 오디오 및/또는 비디오 데이터를 처리하고 있는 VT 디바이스는 수신기 디바이스로 지칭될 수도 있다.
전송기 디바이스는 오디오 및/또는 비디오 데이터를 특정 레이트 (본 명세서에서는 비트 레이트로 교환 가능하게 지칭될 수도 있음) 로 인코딩할 수도 있다. 전송기 디바이스는 네트워크 상태들에 기초하여 레이트를 선택할 수도 있다. 예를 들어, 전송기 디바이스는 VT 세션을 위해 사용되는 네트워크에 의해 지원되는 최대 (또는 거의 최대) 네트워크 링크 레이트에 기초하여 레이트를 선택할 수도 있다. 이러한 방식으로, 전송기 디바이스는 네트워크의 제한을 초과하지 않으면서 네트워크에 의해 지원되는 비교적 최고 품질을 사용하여 전송될 데이터를 준비할 수도 있다.
일부 경우에, VT 디바이스들을 접속시키는 네트워크 링크 레이트가, 특히 Wi-Fi 또는 셀룰러 네트워크와 같은 무선 네트워크를 통해 VT 를 사용할 때, 달라질 수도 있다. 일부 경우에, 네트워크 장비는 링크 레이트 변동을 다루거나 및/또는 큐 관리 (queue management) 를 수행하기 위해 버퍼를 사용할 수도 있다. 예를 들어, 전송기 디바이스는 데이터를 수신기 디바이스에 송신하기 전에 인코딩된 오디오 및/또는 비디오 데이터를 버퍼링하기 위한 버퍼를 포함할 수도 있다. 네트워크 링크 레이트가 갑자기 감소하면 VT 세션에 나쁜 영향을 미칠 수도 있는 병목 (bottleneck) 이 발생할 수도 있다. 예를 들어, 네트워크 링크 레이트가 감소될 때, 전송기 디바이스는 인코딩된 비디오 데이터를 버퍼에 누적시키며, 이는 수신기 디바이스에서 VT 세션의 중단 및/또는 저크니스 (jerkiness) 를 유발할 수도 있다.
전송기 디바이스는 네트워크 링크 레이트의 감소에 응답하여 비디오 데이터가 전송되는 레이트 (여기서, 전송 레이트로 지칭될 수도 있으며, 레이트는 본 개시 전체에 걸쳐서 비트 레이트를 지칭하기 위해 사용됨) 를 변경할 수도 있다. 일부 예에서, 전송기 디바이스는 오디오 및/또는 비디오 데이터가 인코딩되는 레이트를 변화시킴으로써 전송 레이트를 변경할 수도 있다. 그러나, 수신기 디바이스 혼잡 제어 피드백 지연들, 수신기 디바이스로부터 전송기 디바이스로의 리턴 경로에서의 지연들, 레이트 적응 반응 지연들 등으로 인해 레이트를 감소시키는데 있어 반응 지연이 있을 수도 있다. 따라서, 전송 레이트는 네트워크 링크 레이트의 감소 후에 일정 기간 동안 네트워크 링크 레이트보다 상당히 높게 유지될 수도 있다. 전송 레이트 및 네트워크 링크 레이트의 미스매치로 인해 병목 링크에서 버퍼 레벨이 증가하고 따라서 VT 세션의 품질 경험에 나쁜 영향을 미칠 수도 있는 종단간 지연 (또는 심지어 손실된 패킷) 이 증가할 수도 있다.
또한, 전송기 디바이스가 네트워크 링크 레이트의 감소에 응답하여 전송 레이트를 감소시킨 후에도, 구축된 지연은 얼마간 지속될 수도 있다. 예를 들어, 일반적으로, 지연은 네트워크 링크를 통한 송신에 이용가능한 데이터와 실제로 데이터가 네트워크에 송신되는 시간 사이의 시간을 나타낼 수도 있다. 따라서, 지연은 데이터의 버퍼링과 연관될 수도 있다. 예를 들어, 지연이 증가하면 버퍼 레벨이 증가하는데, 이는 데이터를 인코딩한 후 그리고 네트워크에 송신하기 전에 저장해야 하기 때문이다.
전송 레이트와 병목 네트워크 링크 레이트 사이의 차이에 따라, 전송기 디바이스는 버퍼링된 데이터의 양을 상대적으로 느리게 감소시킬 수도 있다. 즉, 감소된 전송 레이트와 네트워크 링크 레이트 간의 차이가 상대적으로 작은 경우, 전송기 디바이스는 구축된 지연을 비교적 느리게 감소시킬 수도 있고 VT 세션에 대한 영향은 지속될 수도 있다.
버퍼링된 데이터의 양을 감소시키는 한 가지 접근법은 전송 레이트를 추정 네트워크 링크 레이트보다 낮게 감소시키는 것이다. 예를 들어, 추정된 네트워크 링크 레이트보다 상당히 낮은 전송 레이트를 사용하는, 비교적 보수적인 접근법은 링크의 불충분한 사용 및 수신기 디바이스에서의 비디오 품질 경험의 전반적인 감소를 초래할 수도 있다. 그러나, 이러한 보수적인 접근법은 또한 병목 링크 버퍼를 상대적으로 신속하게 감소시킬 수도 있다. 반대로, 예를 들어, 네트워크 링크 레이트로 전송 레이트를 감소시키만 하는, 비교적 공격적인 접근법은 링크의 완전한 사용 및 더 고품질의 인코딩된 데이터를 초래할 수도 있다. 그러나, 전술한 바와 같이, 그러한 접근법은 데이터가 비교적 오랜 기간 동안 버퍼에 남아 있게 할 수도 있다.
본 개시의 양태들은 네트워크 상태에 기초하여 전송 레이트 (예를 들어, 전송기 디바이스에서 오디오 및/또는 비디오 데이터를 인코딩하기 위한 비트 레이트) 를 결정하는 것에 관한 것이다. 특히, 그 기술들은 네트워크 링크 레이트의 감소에 응답하여 전송 레이트를 감소시키는 것을 포함한다. 본 개시의 양태에 따르면, 감소된 네트워크 링크 레이트를 식별할 때, 전송기 디바이스는 네트워크 링크 레이트보다 낮은 레이트로 전송 레이트를 감소시킬 수도 있다. 일부 예에서, 수신기 디바이스는 감소된 전송 레이트를 요청할 수도 있고 이는 다음으로 전송기 디바이스에 의해 구현된다. 전송 레이트를 네트워크 링크 레이트보다 낮은 레이트로 감소시키는 것은 네트워크 링크 레이트에 언더슈트하는 것 (undershooting) 으로 지칭될 수도 있다.
또한 그 기술은 전송 레이트를 감소된 레이트로 유지할 시간 량을 결정하는 것을 포함한다. 일부 예에서, 본 개시의 양태들은, 보다 상세히 후술되는 바처럼, 버퍼링 지속시간, 네트워크 링크 레이트의 감소의 크기 (magnitude), 레이트 감소 팩터 및/또는 다른 팩터들에 기초하여 복구 레이트 지속시간 (언더슈트 기간으로도 지칭됨) 을 결정하는 것을 포함한다. 이런 식으로, 그 기술들은 최적 언더슈트 기간을 결정하는데 이용될 수도 있다. 예를 들어, 전송기 디바이스는 네트워크에 의해 지원되는 증가된 전송 레이트로 돌아가기 전에 버퍼링된 데이터의 양을 줄이기 위해 필요한 만큼만 감소된 전송 레이트를 유지할 수도 있다. 그 기술은, 버퍼링되는 데이터의 양이 사용자 경험에 지나치게 영향을 미치지 않으면서 상대적으로 빠르게 감소될 수 있도록, 위에서 설명한 보수적인 접근법과 공격적인 접근법 사이의 균형을 이룰 수도 있다.
본 개시의 양태들은 또한 인코딩된 오디오 및/또는 비디오 데이터를 처리하는 것과 연관된 지연 데이터를 시그널링하는 것을 포함한다. 본 개시의 기술들은 전송기 디바이스에서 버퍼링 지속시간을 결정하는데 사용하기 위한 데이터를 생성하는 것을 포함한다. 버퍼링 지속시간은 (예를 들어, 전송기 및/또는 수신기 디바이스가 즉시 네트워크 링크 레이트의 하락을 인식하고 반응하지 않는다고 하면) 실제 네트워크 링크 레이트의 하락과 네트워크 링크 레이트의 하락이 검출된 시간 사이의 지연과 연관될 수도 있다. 이 지체 시간 동안, 전송기 디바이스는, 일반적으로 원래 전송 레이트로 준비/인코딩되었지만, 감소된 네트워크 링크 레이트로 실시간 (또는 거의 실시간) 으로 전송될 수 없는 데이터를 버퍼링한다. 데이터의 버퍼링은 수신기 디바이스에서 지연을 생성하고 그 지연 동안 데이터가 수신되지 않는다. 상술한 바와 같이, 버퍼링 시간은 전송기 디바이스에서 버퍼링되는 데이터의 양 및/또는 복구 레이트 지속시간을 결정하는데 사용될 수도 있다.
본 개시의 다른 양태들은 네트워크 링크 레이트가 완전히 이용되지 않는 경우에 전송 레이트를 증가시키는 것에 관한 것일 수도 있다. 예를 들어, 전송기 디바이스는, 전송 레이트가 전송기 디바이스를 수신기 디바이스에 링크시키는 네트워크에 의해 지원 가능한 링크 레이트보다 작은 사용자 경험 경우들의 품질을 증가시키기 위해 데이터의 전송 레이트를 증가시킬 수도 있다. 데이터가 인코딩되는 비트 레이트를 증가시키는 것은 여기에서 업 스위칭 (up-switching) 으로 지칭될 수도 있다. 그러나 너무 큰 증분으로 전송 레이트를 업 스위칭하면 네트워크 링크 레이트의 오버슈트가 발생할 수도 있으며, 이것은 설명된 방식으로 사용자 경험을 떨어트릴 수도 있다. 반대로, 너무 작은 증분으로 전송 레이트를 업 스위칭하면 네트워크 링크 레이트의 언더슈트가 계속 발생하고, 이것은 네트워크 링크 레이트에 의해 지원 가능한 것보다 낮은 품질의 사용자 경험을 초래할 수도 있다.
본 개시의 양태들에 따르면, 수신기 디바이스는 데이터가 플레이아웃되도록 스케줄링되는 시간 전에 수신되는 데이터에 기초하여 네트워크 링크 레이트가 충분히 활용되지 않는다고 결정할 수도 있다. 수신기 디바이스는 데이터가 수신되는 시간과 데이터가 플레이아웃되도록 스케줄링된 시간 간의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정할 수도 있고, 수신기 디바이스는 허용 가능한 초과 지연 파라미터에 따라 전송 레이트 증가를 결정할 수도 있다. 수신 디바이스는, 일부 경우에, 전송기 디바이스는 네트워크 링크 레이트에 오버슈트하지 않으면서 네트워크 링크 레이트를 더 잘 이용할 수 있도록, 전송기 디바이스에 전송 레이트 증가의 표시를 송신할 수도 있다.
따라서, 본 개시의 양태들은 전송기 디바이스로부터 발신되고 시변하는 대역폭을 갖는 네트워크 채널 (네트워크 링크라고도 함) 을 통해 수신기 디바이스로 송신되는 비디오 흐름을 제어하기 위한 레이트 적응화 또는 혼잡 제어 기술을 포함한다. 특히, 그 기술은 비디오 흐름의 평균 비트 레이트를 제어된 방식으로 업 스위칭하여 네트워크에서 혼잡을 도입하지 않고서 사용자 경험을 향상시키는 것을 포함한다. 이러한 레이트 적응화 기술은 패킷 손실을 초래할 수 있는 종단간 지연을 현저히 증가시키는 것을 피할 수도 있다.
예를 들어, 본 개시의 양태들에 따르면, 수신기 디바이스는 수신된 비디오 패킷들을 조사하고, 데이터가 데이터의 스케줄링된 플레이아웃에 대해 일찍, 시간에 맞추어 또는 너무 늦게 도착하는지를 결정할 수도 있다. 데이터가 의도된 플레이아웃보다 늦게 도착하는 경우, 수신기 디바이스는 네트워크 링크 레이트가 전송 레이트 (예를 들어, 전송기 디바이스에서 구현된 인코딩 레이트) 보다 낮다는 것을 결정할 수도 있다. 따라서, 수신기 디바이스는 전송 레이트를 감소시키도록 전송기 디바이스에 요청을 전송할 수도 있다. 일부 예들에서, 수신기 디바이스는, 시스템이 네트워크 채널의 혼잡을 완화시키는 것을 허용하기 위해 네트워크 링크 레이트의 지속 가능한 레이트 (예를 들어, 이용 가능한 대역폭) 보다 낮은 초기 레이트를 요청할 수도 있다.
일부 경우들에서, 여기에 설명된 기술들은 IP 멀티미디어 서브시스템 (IMS) (MTSI) 디바이스에 대한 멀티미디어 전화 서비스에 의해 수행될 수도 있다. 예를 들어, MTSI 디바이스는 여기에 설명된 기술들을 사용하여 비트 레이트 적응화 및/또는 혼잡 제어를 수행할 수도 있다.
도 1은 인코딩 및 디코딩 시스템 (10) 을 도시하는 블록도이다. 도 1에 도시된 바처럼, 시스템 (10) 은 송신 채널 (16) 에 의해 접속되는 인코더 시스템 (12) 및 디코더 시스템 (14) 을 포함한다. 도 1의 예에서, 인코더 시스템 (12) 은 제 1 비디오 통신 디바이스와 연관되며, 오디오 소스 (17), 비디오 소스 (18), 비디오 인코더 (20), 오디오 인코더 (22), 실시간 전송 프로토콜 (RTP)/실시간 전송 프로토콜 (RTCP)/사용자 데이터그램 프로토콜 (UDP)/인터넷 프로토콜 (IP)/점대점 프로토콜 (PPP) 변환 유닛 (26), 무선 링크 프로토콜 (RLP) 큐 (28), MAC 계층 유닛 (30) 및 물리 (PHY) 계층 유닛 (32) 을 포함한다. 디코더 시스템 (14) 은 다른 비디오 통신 디바이스와 연관되며, PHY 계층 유닛 (34), MAC 계층 유닛 (36), RLP 큐 (38), RTP/RTCP/UDP/IP/PPP 변환 유닛 (40), 비디오 디코더 (42), 오디오 디코더 (44), 오디오 출력 디바이스 (46) 및 비디오 출력 디바이스 (48) 를 포함한다.
이하에서 보다 상세히 설명되는 바와 같이, 인코더 시스템 (12) 및/또는 디코더 시스템 (14) 은 네트워크 상태에 기초하여 인코딩 레이트를 수정하기 위해 본 개시의 기술들을 사용할 수도 있다. 예를 들어, 비디오 인코더 (20) 는 적어도 부분적으로 네트워크 대역폭의 함수로서 비디오 소스 인코딩 레이트를 제어할 수도 있다. 특히, 비디오 인코더 (20)는 네트워크 링크 레이트의 감소에 응답하여 비디오 및/또는 오디오 데이터의 인코딩 레이트를 감소시킬 수도 있다. 마찬가지로, 비디오 인코더 (20) 는 네트워크 링크 레이트의 불충분한 이용의 표시에 응답하여 비디오 및/또는 오디오 데이터의 인코딩 레이트를 증가시킬 수도 있다.
시스템 (10) 은, 예를 들어, 송신 채널 (16) 을 통해 화상 전화를 위한 양방향 비디오 및 오디오 송신을 제공할 수도 있다. 따라서, 일반적으로 상호간의 인코딩, 디코딩 및 변환 유닛들이 채널 (16) 의 반대쪽 종단 (end) 에 제공될 수도 있다. 일부 실시 형태들에서, 인코더 시스템 (12) 및 디코더 시스템 (14) 은 비디오 스트리밍, 화상 전화 또는 둘 모두를 위해 갖추어진 무선 이동 단말기와 같은 비디오 통신 디바이스 내에 구체화될 수도 있다. 이동 단말기는 RTP, RTCP, UDP, IP 또는 PPP와 같은 패킷교환 표준에 따라 VT를 지원할 수도 있다.
예를 들어, 인코더 시스템 (12) 에서, RTP/RTCP/UDP/IP/PPP 변환 유닛 (26) 은 비디오 인코더 (20) 및 오디오 인코더 (22) 로부터 수신된 오디오 및 비디오 데이터에 적절한 RTP/ RTCP/UDP/IP/PPP 헤더 데이터를 추가하고 그 데이터를 RLP 큐 (28) 에 둔다. 예시적인 비트스트림은 MAC 헤더, IP 헤더, UDP 헤더, RTCP 헤더 및 페이로드 데이터를 포함할 수도 있다. 일부 예에서는, RTP/RTCP 가 UDP 의 위에서 실행되는 한편, UDP는 IP 의 위에서 실행되고, IP는 PPP 의 위에서 실행된다. 일부 예에서, 본 명세서에 기술된 바와 같이, RTP/RTCP/UDP/IP/PPP 변환 유닛 (26) 은 특정 표준, 이를테면 H. Schulzrinne 등의, 2003 년 7 월자 "RFC 3550: RTP: A Transport Protocol for Real-Time Applications", S. Wenger 등의, 2008 년 2 월자 "RFC 5104: Codec Control Messages in the RTP Audio-Visual Provide with Feedback (AVPF)" (이하 RFC 5104) 및/또는 데이터의 실시간 또는 거의 실시간 전송을 위한 다른 적용 가능한 표준을 따른다. MAC 계층 유닛 (30) 은 RLP 큐 (28) 의 내용으로부터 MAC RLP 패킷을 생성한다. PHY 계층 유닛 (32) 은 MAC RLP 패킷을 채널 (16) 을 통한 송신을 위해 PHY 계층 패킷으로 변환한다.
디코더 시스템 (14) 의 PHY 계층 유닛 (34) 및 MAC 계층 유닛 (36) 은 상반되는 방식으로 동작한다. PHY 계층 유닛 (34) 은 채널 (16) 로부터 수신된 PHY 계층 패킷을 MAC RLP 패킷으로 변환한다. MAC 계층 유닛 (36) 은 MAC RLP 패킷을 RLP 큐 (38) 에 둔다. RTP/RTCP/UDP/IP/PPP 변환 유닛 (40) 은 RLP 큐 (38) 내의 데이터로부터 헤더 정보를 스트립 (strip) 하고 비디오 디코더 (42) 및 오디오 디코더 (44) 에 각각 전달하기 위해 비디오 및 오디오 데이터를 리어셈블한다.
시스템 (10) 은 코드 분할 다중 접속 (CDMA), 주파수 분할 다중 접속 (FDMA), 시분할 다중 접속 (TDMA), 또는 직교 주파수 분할 다중화 (OFDM) 또는 다른 적합한 무선 기술과 같은 하나 이상의 무선 통신 기술들을 지원하도록 설계될 수도 있다. 상기 무선 통신 기술들은 다양한 무선 접속 기술들 중 임의의 것에 따라 전달될 수도 있다. 예를 들어, CDMA 는 cdma2000 또는 광대역 CDMA (WCDMA) 표준에 따라 전달될 수도 있다. TDMA는 GSM (Global System for Mobile Communications) 표준에 따라 전달될 수도 있다. 범용 이동 통신 시스템 (UMTS) 표준은 GSM 또는 WCDMA 동작을 허용한다. 통상적으로, VT 애플리케이션의 경우, 시스템 (10) 은 HDR (high data rate) 기술을 지원하도록 설계될 수도 있다.
비디오 인코더 (20) 는 MPEG-4, HEVC (High Efficiency Video Coding) 또는 다른 비디오 코딩 표준과 같은 비디오 압축 방법에 따라 인코딩된 비디오 데이터를 생성한다. 다른 비디오 압축 방법은 ITU (International Telecommunication Union) H.263, ITU H.264 또는 MPEG-2 방법을 포함한다. 오디오 인코더 (22) 는 비디오 데이터에 수반할 오디오 데이터를 인코딩한다. 비디오 소스 (18) 는 하나 이상의 비디오 카메라, 하나 이상의 비디오 아카이브 또는 비디오 카메라와 비디오 아카이브의 조합과 같은 비디오 캡처 디바이스일 수도 있다.
오디오 데이터는 적응형 멀티 레이트 협 대역 (AMR-NB) 또는 다른 기술과 같은 오디오 압축 방법에 따라 인코딩될 수있다. 오디오 소스 (17) 는 마이크로폰과 같은 오디오 캡처 디바이스, 또는 음성 합성기 디바이스일 수도 있다. VT 응용 프로그램의 경우, 비디오는 VT 회의 당사자의 보기를 허용하며 오디오는 해당 당사자의 말하는 음성이 들릴 수 있게 한다.
동작시에, RTP/RTCP/UDP/IP/PPP 변환 유닛 (26) 은 비디오 인코더 (20) 및 오디오 인코더 (22) 로부터 비디오 및 오디오 데이터 패킷을 획득한다. 이전에 언급된 바와 같이, RTP/RTCP/UDP/IP/PPP 변환 유닛 (26) 은 오디오 패킷에 적절한 헤더 정보를 추가하고 그 결과로 생긴 데이터를 RLP 큐 (28) 내에 삽입한다. 마찬가지로, RTP/RTCP/UDP/IP/PPP 변환 유닛 (26) 은 비디오 패킷에 적절한 헤더 정보를 추가하고 그 결과로 생긴 데이터를 RLP 큐 (28) 내에 삽입한다. MAC 계층 유닛 (30) 은 RLP 큐 (28) 로부터 데이터를 취출하고 MAC 계층 패킷을 형성한다. 각 MAC 계층 패킷은 RLP 큐 (28) 내에 포함된 RTP/RTCP /UDP/IP/PPP 헤더 정보 및 오디오 또는 비디오 패킷 데이터를 전한다. 오디오 패킷은 비디오 패킷과 독립적으로 RLP 큐 (28) 에 삽입될 수도 있다.
일부 경우에, RLP 큐 (28) 의 내용로부터 생성된 MAC 계층 패킷은 헤더 정보 및 비디오 패킷 데이터만을 전할 것이다. 다른 경우에, MAC 계층 패킷은 헤더 정보 및 오디오 패킷 데이터만을 전할 것이다. 많은 경우, MAC 계층 패킷은 RLP 큐 (28) 의 내용에 따라, 헤더 정보, 오디오 패킷 데이터 및 비디오 패킷 데이터를 전할 것이다. MAC 계층 패킷은 무선 링크 프로토콜 (RLP) 에 따라 구성될 수 있으며, MAC RLP 패킷으로 지칭될 수도 있다. PHY 계층 유닛 (32) 은 MAC RLP 오디오비디오 패킷을 채널 (16) 을 통한 송신을 위해 PHY 계층 패킷으로 변환한다.
채널 (16) 은 PHY 계층 패킷을 디코더 시스템 (14) 에 전한다. 채널 (16) 은 인코더 시스템 (12) 과 디코더 시스템 (14) 사이의 임의의 물리 접속일 수도 있다. 예를 들어, 채널 (16) 은 로컬 또는 광역 유선 네트워크와 같은 유선 접속일 수도 있다. 대안적으로, 여기에 설명된 바와 같이, 채널 (16) 은 셀룰러, 위성 또는 광학 접속과 같은 무선 접속일 수도 있다. 채널 상태는 유선 및 무선 채널에 대한 관심사일 수도 있지만, 페이딩 또는 혼잡으로 인해 채널 상태가 악화될 수도 있는 무선 채널 (16) 을 통해 수행되는 이동 VT 애플리케이션에 특히 관련될 수도 있다. 채널 (16) 은 채널 상태에 따라 변동할 수도 있는 특정 네트워크 링크 레이트 (예를 들어, 특정 대역폭) 를 지원할 수도 있다. 예를 들어, 채널 (16) 은 채널 상태에 따라 변화하는 스루풋을 갖는 역방향 링크 (RL) 에 의해 특징지어 질 수도 있다.
일반적으로, 디코더 시스템 (14) 의 PHY 계층 유닛 (34) 은 PHY 계층 패킷들로부터 MAC 계층 패킷들을 식별하고 그 내용을 MAC RLP 패킷들로 리어셈블한다. 다음으로, MAC 계층 유닛 (36) 은 RLP 큐 (38) 내에 삽입을 위한 비디오 및 오디오 패킷을 제공하기 위해 MAC RLP 패킷의 내용을 리어셈블한다. RTP/RCTP/UDP/IP/PPP 유닛 (40) 은 수반하는 헤더 정보를 제거하고 비디오 패킷을 비디오 디코더 (42) 에 제공하고 오디오 패킷을 오디오 디코더 (44) 에 제공한다. 비디오 디코더 (42) 는 비디오 데이터 프레임을 디코딩하여 디스플레이 디바이스를 구동하는데 사용하기 위한 비디오 데이터의 스트림을 생성한다. 오디오 디코더 (44) 는 오디오 데이터를 디코딩하여, 예를 들어 오디오 스피커를 통해 사용자에게 제시하기 위한 오디오 정보를 생성한다.
위에서 언급된 바처럼, 시스템 (10) 은, 예를 들어, 전송 채널 (16) 을 통해 화상 전화를 위한 양방향 비디오 및 오디오 송신을 제공할 수도 있다. 일부 예들에서, Wi-Fi, 셀룰러 또는 다른 네트워크 링크에서 발생할 수도 있는 채널 (16) 의 네트워크 링크 레이트가 달라지는 경우 문제가 발생할 수도 있다. 아래에서 도 2와 관련하여 보다 상세히 설명된 바와 같이, 하나 이상의 버퍼가 레이트 변동을 처리하고 잠재적으로 큐 관리를 수행하기 위해 네트워크 장비에 포함될 수도 있다.
예를 들어, 소정 전송 레이트 (예를 들어, 비디오 인코더 (20) 에 의해 사용되는 인코딩 레이트) 를 갖는 VT 흐름은 링크 레이트의 갑작스러운 저하를 겪을 수도 있으며, 이로 인해 흐름에 병목이 발생할 수도 있다. (예를 들어, 수신기 혼잡 제어 피드백 지연, 수신기에서 전송기로의 복귀 경로 상의 지연, 레이트 적응화 반응 지연 등에 의해 야기될 수도 있는) 이러한 링크 레이트 저하에 대한 인코더 시스템 (12) 에서의 반응 지연에 기인하여, 전송 레이트는 일정 기간 동안 링크 레이트보다 상당히 높게 머무를 수도 있다. 이는 병목 링크에서 증가된 버퍼 레벨을 초래할 수도 있으며, 따라서 인코더 시스템 (12) 과 디코더 시스템 (14) 사이의 종단간 지연 (또는 심지어 손실 패킷) 을 증가시킬 수도 있고, 이것은 VT 세션의 품질 경험에 악영향을 미칠 수도 있다.
인코더 시스템 (12) 이 데이터가 채널 (16) 을 통해 송신되는 비트 레이트를 감소시킨 (예를 들어, 전송 레이트를 감소시킨) 후에, 구축 된 지연은 얼마간 지속될 수도 있다. 예를 들어, 일부 경우에서, 구축된 지연이 지속되는 시간의 길이는 전송 레이트와 감소된 링크 레이트 (예를 들어, 병목을 야기하는 링크 레이트) 간의 차이에 의존할 수도 있다. 전송 레이트의 감소가 너무 작으면, 구축된 지연은 상대적으로 느리게 감소할 것이고, 이는 디코더 시스템 (14) 에서의 사용자 경험에 영향을 줄 수도 있다. 보수적인 전송 레이트 접근법은 일관하여, 추정된 링크 레이트보다 훨씬 낮은 레이트로 전송하는 것이다. 그러나, 이러한 접근법은 채널 (16) 에서의 링크의 불충분한 이용 및 전체적으로 감소된 비디오 품질 경험을 초래할 수도 있다.
이 개시에서 설명된 기술에 따라, 비디오 인코더 (20) 는 채널 (16) 의 상태에 기초하여 비디오 소스 (18) 로부터 비디오를 인코딩할 수도 있다. 특히, 비디오 인코더 (20) 는 채널 (16) 에서 대역폭의 감소에 기초하여 인코딩 레이트 (본 명세서에서는 전송 레이트로도 지칭됨) 를 감소시킬 수도 있다. 인코딩 레이트를 감소시키는 것은 본 명세서에서 다운 스위칭 (down-switching) 으로 지칭될 수도 있다. 예를 들어, 디코더 시스템 (14) 에서 생성된 수신기 측 혼잡 제어 피드백 메시지가 인코더 시스템 (12) 에서 수신된 후에, 인코더 시스템 (12) 은 채널 (16) 에서 링크 레이트의 현저한 저하가 검출된 후 비디오 인코더 (20) 에서 인코딩된 데이터의 전송 레이트를 일시적으로 감소시킬 수도 있다.
일 예에서, 본 개시의 양태들에 따르면, 인코더 시스템 (12) 은 초기에 제 1 비트 레이트로 채널 (16) 을 통해 데이터를 송신할 수도 있다. 인코더 시스템 (12) 은 제 1 네트워크 링크 레이트에서 제 2 네트워크 링크 레이트로의 채널 (16) 에서의 네트워크 링크 레이트의 감소를 식별할 수도 있다. 일부 예에서, 인코더 시스템 (12) 은 디코더 시스템 (14) 으로부터 수신된 하나 이상의 리포트에 기초하여 네트워크 링크 레이트의 감소를 식별할 수도 있다.
본 개시의 양태에 따르면, 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 인코더 시스템 (12) 은 채널 (16) 을 통해 데이터를 송신할 복구 비트 레이트를 결정할 수도 있으며, 여기서 복구 비트 레이트는 제 2 네트워크 링크 레이트보다 작다. 인코더 시스템 (12) 은 또한 네트워크 링크 레이트의 감소를 식별하는 시간과 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이를 포함하는 버퍼링 지속시간을 결정할 수도 있다. 예를 들어, 위에서 언급된 바와 같이, 지연을 식별하고 비디오 인코더 (20) 가 데이터를 인코딩하는 레이트를 조정하는 것과 연관된 약간의 반응 시간이 있을 수도 있다. 인코더 시스템 (12) 은 비디오 인코더 (20) 가 인코딩 레이트를 식별하고 더 낮은 레이트로 조정할 시간을 가질 때까지 비디오 인코더 (20) 에 의해 인코딩된 데이터를 초기 (더 높은) 네트워크 링크 레이트 또는 그 부근에서 버퍼링할 수도 있다.
인코더 시스템 (12) 은 복구 비트 레이트 및 버퍼링 지속시간에 기초하여 복구 비트 레이트로 데이터를 송신할 복구 레이트 지속시간을 결정할 수도 있다. 그 후, 인코더 시스템은 결정된 복구 레이트 지속시간 동안 데이터를 복구 비트 레이트로 송신할 수도 있다. 이러한 방식으로, 기술은 (예를 들어 연장된 기간 동안 감소된 레이트로 전송 레이트를 유지하는 것보다) 구축된 종단간 지연을 상대적으로 신속하게 감소시킬 수도 있으며 종단간 지연이 감소된 후에 이용 가능한 링크 레이트를 사용하여 사용자 경험의 품질을 보존할 수도 있다. 예의 목적으로, 인코더 시스템 (12) 에 관해 설명하였지만, 앞서 언급된 기술 중 일부는 디코더 시스템 (14) 에 의해 추가적으로 또는 대안적으로 수행될 수도 있음이 이해되야 한다.
본 개시의 또 다른 기술은 네트워크 상태에 기초하여 데이터가 인코딩되는 레이트를 업 스위칭하는 (예를 들어, 증가시키는) 기술을 포함한다. 예를 들어, 2014 년 6 월 24 일 E2EMTSI-S4, S4-AHM215 ("AHM215") 의 종단 간 비디오 레이트 적응에 대한 SA4 MTSI SWG Conference Call No. 4 의 "Discussion on Upswitch Principals" 의 프리젠테이션 동안, 업 스위칭에 관한 많은 문제점들이 확인되었다. Tdoc S4 (14)0768 의 E2EMTSI-S4 의 종단간 비디오 레이트 적응화에 대한 "Report from SA4 MTSI SWG Conference Call No. 4 (2014 년 6 월 24 일)" 에 기록된 바처럼, 업 스위치에 대한 원칙에 동의하기 전에 컨퍼런스 콜로부터 새로운 아이디어를 조사하기 위해 추가의 논의가 필요하다고 느껴졌다.
일반적으로 AHM215에 제시된 모델은 램프 업 프로빙 모델 (ramp-up probing model) 에 의거하고, 이는 프로브가 채널 상태에 매칭되지 않을 때 프로빙이 시스템에 지연을 초래할 수 있다는 단점을 가질 수도 있다. 보다 견고한 모델은 디코더 시스템 (14) 과 같은 수신기가 채널 (16) 의 상태를 수동적으로 측정하여 시스템에 과잉 용량이 존재할 수 있는지 여부를 결정할 수 있게 하는 것이다. 이에 기초하여, 디코더 시스템 (14) 은 시스템의 지속 가능한 레이트의 보다 정확한 추정을 할 수도 있다.
AHM215에 제시된 모델은 또한 엔코더 시스템 (12) 이 채널을 먼저 프로빙하여 더 많은 용량이 있을 수도 있는지를 확인하는 2 단계 접근법을 제안한다. 프로빙 단계가 성공적이면, 비디오 인코더 (20)는 "램프 업 단계" 동안보다 보다 공격적으로 레이트를 증가시킬 수도 있다. 이러한 모델은 시스템에 비교적 많은 양의 혼잡을 초래할 수도 있는데, 데이터 레이트가 조금 증가한 성공적인 프로브는 시스템이 이후에 훨씬 더 큰 증가를 처리할 수 있다는 것을 암시하지 않을 수도 있기 때문이다. 실제로, 시스템 용량에 매칭시키기 위해 시스템 인코더 (20) 의 레이트를 증가시킬 때, 보다 견고한 접근법은 우선 비교적 큰 양만큼 레이트를 증가시키고, 그 다음에 레이트가 채널 (16) 에 의해 지원되는 지속 가능한 레이트로 수렴함에 따라 보다 작은 스텝들을 취하는 것이다.
위에서 설명한 방식으로 지속 가능한 레이트로 수렴한다는 잠재적으로 보다 견고한 접근법을 따르기 위해, 적응화를 구동하는 개체 (예를 들어, 전송기 (인코더 시스템 (12)) 또는 수신기 (디코더 시스템 (14)) 는, 시스템의 지속 가능한 레이트를 추정해야 한다. 전송기는 RTCP 리시버 리포트에 의존하여 종단간 채널 상태를 검출할 수도 있으며, RTCP 리포팅으로 인한 약간의 측정 지연에도 불구하고, 순 스루풋을 산출할 수 있다. 수신기는, 패킷이 스케줄링된 플레이아웃을 위해 디코더 시스템 (14) 에 너무 늦게 도착하기 전에 받아들여질 수도 있는 추가 지연의 양 및 순 스루풋 양자 모두를 산출할 수도 있다. 따라서, 수신기에서 계산된 관련 메트릭이 전송기에게 직접 전송되면, 수신기 구동 적응화 모델이 달성되고, 보다 견고할 수도 있으며, 최소 적응화 성능을 결정하는데 이용되어야 한다.
본 개시의 양태들에 따르면, 디코더 시스템 (14) 은 채널 (16) 에서의 대역폭이 충분히 이용되지 않는다고 결정할 때 수신기 구동 레이트 업 스위칭 기술을 구현할 수도 있다. 예를 들어, 본 개시의 양태들에 따르면, 디코더 시스템 (14) 은 인코딩 레이트를 증가시키도록 비디오 인코더 (20) 에 프롬프트하는 데이터를 인코더 시스템 (12) 에 제공할 수도 있다.
일부 예들에서, 본 개시의 양태에 따르면, 디코더 시스템 (14) 은 데이터가 디코더 시스템 (14) 에 의해 수신되는 시간과 수신된 데이터가 플레이아웃되도록 스케줄링된 시간 사이의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정할 수도 있다. 허용 가능한 초과 지연 파라미터는 사용자 경험이 영향을 받기 전에, 예를 들어 데이터가 너무 늦게 도착하여 적절한 시간에 디코딩 및 플레이아웃될 수 없기 전에 채널 (16) 에 의해 지원 가능한 지연의 양을 나타낼 수도 있다. 디코더 시스템 (14) 은 또한 결정된 허용 가능한 초과 지연 파라미터에 기초하여 데이터가 인코더 시스템 (12) 으로부터 디코더 시스템 (14) 으로 전송되는 비트 레이트를 증가시키기 위한 전송기 비트 레이트 증가를 결정할 수도 있다. 디코더 시스템 (14) 은 또한 전송기 비트 레이트 증가의 표시를 인코더 시스템 (12) 으로 송신할 수도 있다.
이런 식으로, 디코더 시스템 (14) 은 비디오 흐름의 평균 비트 레이트를 제어된 방식으로 제어하여 네트워크에서 혼잡을 도입하지 않고서 사용자 경험을 향상시킬 수도 있다. 이 기술은 패킷 손실을 초래할 수 있는 종단간 지연을 현저히 증가시키는 것을 피할 수도 있다.
도 2는 본 개시의 기술들에 따른 비디오 소스 레이트 적응화를 구현할 수도 있는 인코더 시스템 (12) 을 나타내는 블록도이다. 도 2에 도시된 바와 같이, 비디오 인코더 (20) 는 비디오 인코딩 엔진 (50), 비디오 버퍼 (52) 및 비디오 레이트 제어기 (54) 를 포함한다. 비디오 인코더 (20) 는 또한 디코더 시스템 (14) 에 의해 준비될 수도 있는 네트워크 링크 레이트 정보 (56) 를 수신한다 (이하에서 더 상세히 설명됨).
비디오 인코딩 엔진 (50) 은 비디오 소스 (18) 로부터 비디오 데이터를 획득하고 비디오 레이트 제어기 (54) 에 의해 제어되는 레이트로 비디오 데이터를 인코딩한다. 비디오 인코딩 엔진 (50) 은 인코딩된 비디오를 비디오 버퍼 (52) 에 둔다. 비디오 레이트 제어기 (54) 는 비디오 버퍼 (52) 의 충만도를 모니터링하고 적어도 부분적으로 충만도에 기초하여 비디오 인코딩 엔진 (50) 에 의해 적용된 비디오 인코딩 레이트를 제어할 수도 있다. 또한, 보다 상세히 후술하는 바와 같이, 비디오 레이트 제어기 (54) 는 네트워크 링크 레이트 정보 (56) 및/또는 채널 (16) (도 1) 의 상태와 연관된 다른 데이터에 기초하여 레이트를 제어 할 수도 있다.
일부 예에서, 비디오 인코더 (20) 는 일반적으로 CODEC독립적인 비디오 소스 레이트 제어 스킴을 제공할 수도 있다. 예를 들어, 비디오 인코더 (20) 는 HEVC, MPEG4, ITU H.263 또는 ITU H.264에 따른 비디오 인코딩을 위해 적응될 수도 있다. 또한, 비디오 인코더 (20) 는 DSP 또는 임베디드 로직 코어 내에서 구현하기 쉬울 수도 있다. 일부 실시 형태들에서, 비디오 인코더 (20) (예를 들어, 비디오 인코더 (20) 의 비디오 레이트 제어기 (54)) 는 모델 기반 레이트 제어를 적용, 예를 들어, 로 (rho) 도메인에서 비디오 블록 레이트 제어를 적용할 수도 있다. 예를 들어, 특정 비디오 프레임에 대해 프레임 비트 버짓이 확립되면, 프레임 비트 버짓이 로 도메인 레이트 제어를 사용하는 프레임 내의 비디오 블록들, 예를 들어, 코딩 유닛 (CU) 및/또는 매크로블록 (MB) 중에서 할당될 수도 있다. 다음으로, 개별 MB에 대한 로 도메인 값을 양자화 파라미터 (QP) 값으로 매핑할 수 있다.
본 개시의 양태에 따르면, 비디오 레이트 제어기 (54) 는 네트워크 상태들에 기초하여 레이트 다운 스위칭을 수행할 수도 있다. 예를 들어, 비디오 인코딩 엔진 (50) 은 초기에, 채널 (16) (도 1) 과 같은 전송 매체를 통한 송신을 위해 제 1 비트 레이트로 데이터를 인코딩할 수도 있다. 비디오 레이트 제어기 (54) 는 제 1 네트워크 링크 레이트에서 제 2 네트워크 링크 레이트로의 네트워크 링크 레이트의 감소를 식별할 수도 있다. 일부 예에서, 비디오 레이트 제어기 (54) 는 비디오 인코더 (20) 에서의 피드백으로부터 네트워크 링크 레이트의 감소를 식별할 수도 있다. 다른 예에서, 비디오 레이트 제어기 (54) 는 네트워크 링크 레이트 정보 (56) 에 기초하여 네트워크 링크 레이트의 감소를 식별할 수도 있다.
네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 비디오 레이트 제어기 (54) 는 제 2 (감소된) 네트워크 링크 레이트보다 작은 비디오 인코더 (20) 를 위한 복구 비트 레이트를 결정할 수도 있다. 복구 레이트는 네트워크 링크 레이트 감소의 실제 시간과 네트워크 링크 레이트 감소의 식별간에 버퍼링된 데이터의 양을 감소시키기 위해 사용될 수도 있다. 이러한 버퍼링된 데이터를 줄이면 사용자 경험이 수신기 디바이스에서 영향을 받지 않도록 보장하는데 도움이 될 수도 있다. 따라서, 비디오 레이트 제어기 (54) 는 비디오 인코더 (20) 에서 버퍼링된 데이터의 양을 줄이기 위해 감소된 네트워크 링크 레이트에 언더슈트하는 비디오 인코더 (20) 에서의 사용을 위한 복구 비트 레이트를 결정할 수도 있다.
본 개시의 양태들에 따르면, 비디오 레이트 제어기 (54) 는 언더슈트 팩터 (undershoot factor) 에 기초하여 복구 레이트를 결정할 수도 있다. 비디오 레이트 제어기 (54) 는 제 1 네트워크 링크 레이트와 감소된 네트워크 링크 레이트 사이의 차이에 기초하여 언더슈트 팩터를 결정할 수도 있다. 즉, 비디오 레이트 제어기 (54) 는 네트워크 링크 레이트의 감소의 크기에 기초하여 변화하는 크기를 갖는 언더슈트 팩터 (undershoot factor) 를 결정할 수도 있다. 따라서, 네트워크 링크 레이트의 감소가 비교적 높으면, 비디오 레이트 제어기 (54) 는 상대적으로 높은 언더슈트 팩터를 결정할 수도 있다. 마찬가지로, 네트워크 링크 레이트의 감소가 비교적 낮으면, 비디오 레이트 제어기 (54) 는 상대적으로 낮은 언더슈트 팩터를 결정할 수도 있다.
일부 예에서, 비디오 레이트 제어기 (54) 는 복구 레이트를 결정하기 위해 감소된 네트워크 링크 레이트에 적용될 수도 있는 언더슈트 팩터를 결정할 수도 있다. 예를 들어, 비디오 레이트 제어기 (54) 는 부분적 언더슈트 팩터 (fractional undershoot factor) 를 결정할 수도 있고, 복구 레이트를 결정하기 위해 감소된 네트워크 링크 레이트에 그 부분적 언더슈트 팩터를 적용할 수도 있다. 일 예에서, 비디오 레이트 제어기 (54) 는 제 1 네트워크 링크 레이트에 대한 네트워크 링크 레이트의 감소에서의 크기의 비에 기초하여 언더슈트 팩터를 결정할 수도 있다.
본 개시의 양태에 따르면, 비디오 레이트 제어기 (54) 는, 네트워크 링크 레이트의 감소의 식별 시간과 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이에 비디오 인코더 (20) 에서 얼마나 많은 데이터가 버퍼링되는지에 기초하여 (또는 보다 일반적으로, 비디오 인코더 (20) 를 포함하는 전송기 디바이스에서 얼마나 많은 데이터가 버퍼링되는지에 기초하여) 복구 레이트를 얼마나 오래 유지할지를 결정할 수도 있다. 전송기 디바이스에서 데이터를 버퍼링하는 것과 연관된 시간은 여기서 버퍼링 지속시간 (또는 버퍼링 기간) 이라고 지칭될 수도 있는 한편, 복구 레이트를 유지하는 지속시간은 본 명세서에서 복구 레이트 지속시간 (또는 감소된 레이트 기간) 으로 지칭될 수도 있다. 일부 경우에, 데이터가 복구 레이트 지속시간 동안 인코딩되는 레이트가 네트워크 링크 레이트보다 작기 때문에, 복구 레이트 지속시간은 또한, 언더슈트 지속시간 또는 기간으로 지칭될 수도 있다.
아래에서 도 5와 관련하여 보다 상세히 설명된 바와 같이, 비디오 레이트 제어기 (54) 는 다양한 방식으로 버퍼링 지속시간을 결정할 수도 있다. 예를 들어, 비디오 레이트 제어기 (54) 는 비디오 인코더 (20) 를 포함하는 전송기 디바이스와 수신기 디바이스 사이의 왕복 시간 (RTT), 다운링크 지연 (예컨대, 수신기에서 전송기로의 지연), 레이트 적응화 반응 지연, 혼잡 제어의 반응 지연 (예를 들어, 링크 레이트의 추정), 메시지 생성 지연 (RTCP 패킷) 등에 관한 데이터와 같은 네트워크 링크 레이트 정보 (56) 로부터의 버퍼링 지속시간을 추정함으로써 버퍼링 지속시간을 결정할 수도 있다. 네트워크 링크 레이트 정보 (56) 는 비디오 인코더 (20) 에서 이용 가능할 수도 있거나, 또는 수신기 디바이스에 의해 비디오 인코더 (20) 에 시그널링될 수도 있다.
본 개시의 양태들에 따르면, 비디오 레이트 제어기 (54) 는 복구 레이트의 크기에 기초하여 그리고 버퍼링 지속시간에 기초하여 복구 레이트 지속시간을 결정할 수도 있다. 일부 예들에서, 비디오 레이트 제어기 (54) 는 (예를 들어, 복구 레이트에 의해 표시된 바와 같이) 네트워크 링크 레이트의 감소의 크기 및 (예를 들어, 버퍼링 지속시간에 의해 표시된 바와 같이) 네트워크 링크 레이트의 감소에 반응하는 것과 연관된 시간의 양에 비례하는 버퍼링 지속시간을 결정할 수도 있다. 즉, 네트워크 링크 레이트의 감소가 비교적으로 크거나 및/또는 네트워크 링크 레이트의 감소에 반응하는데 필요한 시간이 비교적 긴 경우, 비디오 레이트 제어기 (54) 는, 비례하여 긴 복구 레이트 지속시간을 결정할 수도 있다. 마찬가지로, 네트워크 링크 레이트의 감소가 비교적으로 작거나 및/또는 네트워크 링크 레이트의 감소에 반응하는데 필요한 시간이 비교적 짧은 경우, 비디오 레이트 제어기 (54) 는, 비례하여 짧은 복구 레이트 지속시간을 결정할 수도 있다.
본 개시의 다른 양태들에 따르면, 비디오 레이트 제어기 (54) 는 추가적으로 또는 대안적으로, 네트워크 상태들에 기초하여 레이트 업 스위칭을 수행할 수도 있다. 예를 들어, 비디오 레이트 제어기 (54) 는 디코더 시스템 (14) (도 1) 을 포함하는 디바이스와 같은 수신기 디바이스로부터 네트워크 링크 레이트 정보 (56) 를 수신할 수도 있다. 비디오 레이트 제어기 (54) 는 데이터를 인코딩하기 위해 비디오 인코딩 엔진 (50) 에 의해 사용되는 전송 레이트 (예를 들어, 인코딩 레이트) 를 업 스위칭하기 위해 수신된 네트워크 링크 레이트 정보 (56) 를 사용할 수도 있다.
일부 예에서, 수신된 네트워크 링크 레이트 정보 (56) 는 비디오 인코딩 엔진 (50) 에 의해 구현되는 특정 요청된 전송 레이트 (예를 들어, 인코딩 레이트) 를 포함할 수도 있다. 다른 예들에서, 수신된 네트워크 링크 레이트 정보 (56) 는 현재 전송 레이트 (예를 들어, 전송 레이트 스텝) 에 추가될 레이트 스텝 증가를 포함할 수도 있다. 어느 경우든, 아래에서 도 3과 관련하여 보다 상세히 설명되는 바와 같이, 수신된 네트워크 링크 레이트 정보 (56) 는 패킷들이 플레이아웃되도록 스케줄링되기 전에 수신기 디바이스에서 패킷들이 수신되었음을 나타내는 초과 지연 파라미터에 기초할 수도 있다. 그러한 경우에, 비디오 레이트 제어기 (54) 는 패킷들의 도착 시간이 수신기 디바이스에서의 패킷들의 스케줄링된 플레이아웃 시간과 더 가깝게 일치할 때까지 비디오 인코딩 엔진 (50) 에 의해 사용되는 전송 레이트를 증가시킬 수도 있다.
도 2의 기술들은 (예를 들어, 비디오 레이트 제어기 (54) 와 같은) 도 2의 특정 컴포넌트에 의해 수행되는 것으로 설명되지만, 이러한 기술들은 추가적으로 또는 대안적으로 화상 전화 디바이스의 하나 이상의 다른 컴포넌트들에 의해 수행될 수있다는 것이 이해되야 한다. 일례로서, MTSI 디바이스는 레이트 적화응 및/또는 혼잡 제어를 수행하기 위해 상술된 특정 기술들을 수행할 수도 있다. 이 예에서, 다음으로 MTSI 디바이스는 비디오 인코더에서 적절한 레이트 제어를 구현하기 위해 비디오 레이트 제어기 (54) 에 데이터를 제공할 수도 있다.
도 3은 본 개시의 기술들에 따른 비디오 소스 레이트 적응화를 구현할 수도 있는 비디오 디코더 시스템 (14) 을 나타내는 블록도이다. 도 3에 도시된 바와 같이, 비디오 디코더 (42) 는 인코딩된 데이터 및 네트워크 링크 레이트 정보 (60) 를 수신하고, 비디오 디코딩 엔진 (62), 플레이아웃 결정 유닛 (64), 및 레이트 제어 데이터 (68) 를 생성하는 레이트 제어 유닛 (66) 을 포함한다.
비디오 디코딩 엔진 (62) 은 인코딩된 데이터 및 네트워크 링크 레이트 정보 (60) 를 수신하고 비디오 데이터를 디코딩한다. 일부 예에서, 비디오 디코딩 엔진 (62) 은 하나 이상의 비디오 코딩 표준을 따를 수도 있다. 상술 한 바와 같이, 예시적인 비디오 코딩 표준은 HEVC, MPEG4, ITU H.263 또는 ITU H.264 를 포함한다.
비디오 데이터가 수신되는 레이트는 비디오 인코더 (20) (도 2) 의 비디오 레이트 제어기 (54) 에 의해 제어될 수도 있다. 본 개시의 양태에 따르면, 레이트 제어 유닛 (66) 은 인코딩 레이트를 조정하는데 사용하기 위해 레이트 제어 데이터 (68) 를 준비하여 비디오 인코더 (20) 에 전송할 수도 있다. 일부 예에서, 레이트 제어 데이터 (68) 는 전송기 디바이스에서 다운 스위칭을 수행하기 위한 데이터를 포함할 수도 있다. 다른 예에서, 추가적으로 또는 대안적으로, 레이트 제어 데이터 (68) 는 전송기 디바이스에서 업 스위칭을 수행하기 위한 데이터를 포함할 수도 있다. 레이트 제어 유닛 (66) 은 전송기 디바이스가 적절한 비트 레이트를 결정할 수 있게 하는 데이터를 준비할 수도 있거나, 또는 전송기 디바이스로부터 특정 비트 레이트를 요청할 수도 있다.
본 개시의 양태에 따라, 다운 스위칭을 위한 데이터를 준비하는 것과 관련하여, 레이트 제어 유닛 (66) 은 도 2와 관련하여 상술한 것과 유사한 방식으로, 복구 레이트, 버퍼링 지속시간 및/또는 복구 레이트 지속시간을 결정할 수도 있다. 다른 예에서, 레이트 제어 유닛 (66) 은 복구 레이트, 버퍼링 지속시간, 및/또는 복구 레이트 지속시간을 결정하기 위해 전송기 디바이스 (이를테면, 인코더 시스템 (12)) 에 의해 사용될 수도 있는 데이터를 생성하거나 및/또는 메시지를 송신할 수도 있다.
일 예에서, 레이트 제어 유닛 (66) 은 네트워크 링크 레이트의 감소를 나타내기 위해 순방향 채널에 대한 추정된 최대 비트 레이트로 전송기 디바이스에 대한 RTCP 임시 최대 매체 스트림 비트 레이트 요청 (TMMBR) 메시지를 생성할 수도 있다. 일반적으로, 위에서 언급된 RFC 5104 에 설명된 바와 같이, 수신기, 번역기 (translator) 또는 믹서는 전송기에게 매체 스트림에 대한 최대 비트 레이트를 제공된 값으로 또는 그 아래로 제한하도록 요청하기 위하여 TMMBR ( "팀버" 로 지칭됨) 을 사용할 수도 있다. TMMBN (Temporary Maximum Media Stream Bit Rate Notification) 은, 매체 전송기를 더 제한하지 않는 TMMBR 을 참여자가 억제하는 것을 돕기 위해 수신한 TMMBR 정의 한계들의 가장 제한적인 서브세트에 대한 매체 전송기의 현재 보기를 포함한다.
본 개시의 양태에 따르면, 제 1 레이트에서 제 2 의 더 낮은 레이트로 포워드 채널에 대한 추정된 최대 비트 레이트의 변화는 네트워크 링크 레이트의 감소를 나타낸다. 일부 예에서, 레이트 제어 유닛 (66) 은 혼잡이 검출된 직후 또는 거의 직후 (예를 들어, TMMBR 메시지를 생성하는 것과 연관된 메시지 생성 지연이 있을 수도 있음) TMMBR 을 전송할 수도 있다. 설명을 위해 TMMBR 메시지가 설명되었지만, 지연/혼잡을 나타내는 다양한 다른 메시지가 사용될 수 있다는 것을 이해해야 한다.
본 명세서에 설명된 버퍼링 지속시간을 추정하는 것으로 전송기 디바이스를 가능하게 하기 위해, 레이트 제어 유닛 (66) 은 또한 RTCP 수신기 리포트 (RR) 메시지를 생성하고 송신할 수도 있다. 예를 들어, 위에서 언급한 RFC 3550 에 설명된 대로, 여러 RTCP 패킷 유형을 사용하여 다양한 제어 정보를 전할 수도 있다. 활성 전송기인 참가자로부터 송신 및 수신 통계에 전송기 리포트 (SR) 가 사용될 수도 있다. RR은 활성 전송기가 아닌 참여자로부터의 수신 통계에 그리고 31개를 넘는 소스에 대한 활성 전송기 리포팅에 SR과 조합하여 사용될 수도 있다.
본 개시의 양태들에 따르면, 레이트 제어 유닛 (66) 은 TMMBR 메시지 다음에, 예를 들어, TMMBR 메시지 직후 또는 거의 직후에 RR 메시지를 생성하고 송신할 수도 있다. 이 예에서, 전송기 디바이스는 TMMBR 메시지 및 RR 메시지를 수신 할 수도 있고, 버퍼링 지속시간에 대한 상한을, RR에 포함된 최종 SR 타임스탬프 (LSR 데이터) 에 의해 RR 에서 참조되는 SR 을 전송하는 시간과 RR 이 전송기 디바이스에 의해 수신된 시간 사이의 시간 차이로서 결정할 수도 있다. 즉, 레이트 제어 유닛 (66) 은 비트 레이트 제한에 대한 요청을 나타내는 제 1 데이터 (예를 들어, TMMBR 메시지) 및 메시지가 생성된 시간을 나타내는 제 2 데이터 (예를 들어, LSR 데이터) 를 전송할 수도 있다. LSR 데이터는 소스로부터 가장 최근의 RTCP SR 패킷의 일부로서 수신된 64 비트 네트워크 타임 프로토콜 (NTP) 타임스탬프 중 중간 32 비트를 포함할 수도 있다. SR이 아직 수신되지 않은 경우, LSR 타임스탬프 필드는 0 으로 설정될 수도 있다. 전송기 디바이스는 상술한 데이터를 수신할 수도 있고 그 데이터를 이용하여 버퍼링 지속시간을 결정할 수도 있고, 이것은 다운 스위칭 동안 사용될 수도 있다.
다른 예에서, 2 개의 별개의 연속적인 메시지들 (예를 들어, TMMBR 및 RTCP RR) 을 전송하기 보다는, 레이트 제어 유닛 (66) 은 TMMBR 데이터 및 RTCP RR 데이터를 단일 RTCP 메시지로 그룹화하고 단일 메시지를 전송기 디바이스로 전송할 수도 있다. 최소한으로, 레이트 제어 유닛 (66) 은 전송기 디바이스가 버퍼링 지속시간을 추정할 수 있게 하는 LSR 데이터를 전송할 수도 있다. 이 예에서, 메시지 사이즈는 2개의 별개의 메시지를 전송하는 것에 비해 감소될 수도 있다.
일부 예들에서, 레이트 제어 유닛 (66) 이 동일한 LSR 을 갖는 RTCP RR 을 이전에 전송하였더라도, 레이트 제어 유닛 (66) 은 최종 수신된 RTCP SR 의 LSR 을 사용하여 전송기 디바이스에 전송할 수도 있다. 레이트 제어 유닛 (66) 이 아직 RR을 전송하지 않았다면, 레이트 제어 유닛 (66) 은 TMRR 과 완전한 RR 을 조합할 수도 있다. 다른 예들에서, 메시지 사이즈를 줄이기 위해, 레이트 제어 유닛 (66) 은 전송기 디바이스가 수신하여 RTT 를 결정하기 위해 사용할 수도 있는 TMMBR과 함께 LSR 데이터만을 전송할 수도 있다. 또 다른 예에서, 레이트 제어 유닛 (66) 이 이미 RR 을 전송했다면, 전송기 디바이스는 최종 수신된 RR 을 수신한 시간과 새로운 RR (예를 들어, 혼잡이 검출된 후에 레이트 제어 유닛 (66) 에 의해 전송된 RR) 을 수신한 시간 사이의 시간 차이로서 보다 정확하게 버퍼링 지속시간을 계산할 수도 있다.
레이트 제어 유닛 (66) 은 또한 복구 레이트 지속시간을 결정하거나 및/또는 복구 레이트 지속시간을 결정하기 위해 전송기 디바이스에 데이터를 생성하여 전송할 수도 있다. 예를 들어, 전술한 기술 대신에 또는 이와 조합하여, 레이트 제어 유닛 (66) (또는 전송기 디바이스) 은 RTCP RR 도착간 지터 (inter-arrival jitter) 를 모니터링하여 복구 레이트 지속시간을 종료할 시기를 결정할 수도 있다. 일반적으로, 도착간 지터 데이터는 타임스탬프 단위로 측정되고 부호없는 정수로 표현되는, RTP 데이터 패킷 도착간 시간의 통계적 분산 (statistical variance) 의 추정치를 제공 할 수도 있다. 도착간 지터 J 는 한 쌍의 패킷에 대한 전송기와 비교하여 수신기에서의 패킷 간격의 차이 D의 평균 편차 (평활화된 절대 값) 로 정의될 수도 있다. 아래 등식 (1) 에 나타낸 바와 같이, 이것은 2 개의 패킷에 대한 "상대 이동 시간" (relative transit time) 의 차이와 동등하다; 상대 이동 시간은, 동일한 단위 (unit) 로 측정되는, 패킷의 RTP 타임스탬프와 도착시 수신기의 클럭 사이의 차이이다. Si 가 패킷 i 로부터의 RTP 타임스탬프이고, Ri 가 패킷 i 에 대한 RTP 타임스탬프 단위의 도착 시간인 경우, 2 개의 패킷 i 및 j 에 대해 D 는 다음과 같이 표현될 수도 있다:
Figure pct00001
본 개시의 양태들에 따르면, 전송기 디바이스는, 도착간 지터가 0 이 되거나 임계 값보다 작아지면 레이트 감소를 종결시킬 수도 있다 (예를 들어, 전송기 디바이스는 감소된 레이트로부터 대략 네트워크 링크 레이트로 전송 레이트를 증가시킬 수도 있다). 임계치는 일정하거나 또는 변화하는 네트워크 상태에 적응적일 수도 있다. 일부 예에서, 전송기 디바이스는 도착간 지터가 최소 기간 동안 임계 값보다 작게 또는 0 으로 유지될 때 레이트 감소를 종결시킬 수도 있다. 일부 경우에는, 레이트 제어 유닛 (66) 이 RTCP SR 및 RR을 시그널링하는 빈도가 높을수록, 전송기 디바이스는 더 정확하게 도착간 지터를 모니터링할 수도 있다.
또 다른 예에서, 전송기 디바이스 (이를테면, 인코더 시스템 (12)) 는 지연 (예를 들어, RTT) 을 모니터링할 수도 있고 전송기는 지연이 현저히 감소될 때까지 감소된 레이트로 전송 레이트를 유지할 수도 있다. 예를 들어, 전송기 디바이스는 버퍼에 저장된 데이터의 양이 임계 레벨 아래로 떨어질 때까지 감소된 레이트로 전송 레이트를 유지할 수도 있다.
본 개시의 다른 기술에서, 플레이아웃 결정 유닛 (64) 은 수신된 비디오 패킷을 조사하고, 수신된 데이터가 스케줄링된 플레이아웃을 위해 일찍, 시간에 맞게 또는 너무 늦게 도착하는지를 결정할 수도 있다. 스케줄링된 플레이아웃 타이밍은 인코딩된 데이터와 함께 표시될 수도 있다. 패킷이 늦게 도착하는 경우 (예를 들어, 패킷이 수신/조사되기 전에 플레이아웃 시간이 발생하는 경우), 레이트 제어 유닛 (66) 은 전송 비트 레이트를 감소시키도록 전송기 디바이스에 요청할 수도 있다. 일부 예에서, 레이트 제어 유닛 (66) 은 선택된 레이트로 TMMBR 메시지를 전송할 수도 있다.
일부 양태에 따르면, 레이트 제어 유닛 (66) 은, 제거될 필요가 있는 초과 지연의 양을 결정하고 이 초과 지연 파라미터에, 레이트 제어 유닛 (66) 에 의해 측정된 도착 비디오의 데이터 레이트를 곱함으로써 백로그된 (back-logged) 데이터 (예를 들어, 전송기 디바이스에서 버퍼링된 데이터) 의 양을 추정할 수도 있다. 즉, 레이트 제어 유닛 (66) 은 데이터가 수신/조사된 시간과 데이터와 함께 표시된 플레이아웃 시간 사이의 차이에 기초하여 지연을 결정할 수도 있다. 레이트 제어 유닛 (66) 은 전송기에 의해 버퍼링되는 데이터의 양을 결정하기 위해 이 지연 시간에 데이터가 수신되는 비트 레이트를 곱할 수도 있다.
일부 예에서, 레이트 제어 유닛 (66) 은, 시스템이 채널의 혼잡을 완화시키는 것을 허용하기 위해 비디오 디코더 (42) 와 전송기 디바이스 사이의 전송 경로의 지속 가능한 레이트 (예를 들어, 네트워크 링크의 이용 가능한 대역폭) 보다 낮은 초기 레이트를 (예를 들어, TMMBR 메시지에서) 요청할 수도 있다. 일 예에서, 레이트 제어 유닛 (66) 은 시스템이 고정된 시간 량 (변수 T_decongest 로 표시됨) 에서 채널을 혼잡 완화할 수 있게 하기에 충분히 낮은 초기 레이트를 선택할 수도 있다. 변수 R_sustain 이 채널의 지속 가능 레이트와 동일하고, 변수 ΔDelay가 제거될 필요가 있는 지연의 양과 동일한 경우, 레이트 제어 유닛 (66) 은 초기에 아래의 등식 (2) 에 따른 비트 레이트 R 에서 데이터를 인코딩하도록 전송기 디바이스에 요청할 수도 있다:
Figure pct00002
요청된 비트 레이트 (예를 들어, TMMBR 메시지) 를 포함하는 메시지를 전송한 후에, 레이트 제어 유닛 (66) 은 혼잡 완화 시간 (T_decongest) 이 경과하기를 기다릴 수도 있다. 다음으로, 레이트 제어 유닛 (66) 은 네트워크 링크 (R_sustain) 에 의해 지속 가능한 레이트로 다른 요청된 비트 레이트 (예를 들어, 추가 TMMBR 메시지) 를 전송하여, 혼잡 완화 기간을 종료할 수도 있다.
다른 예에서, 레이트 제어 유닛 (66) 은 레이트를 증가시키기 위해 다른 메시지 (예를 들어, 추가 TMMBR 메시지) 를 전송하지 않을 수도 있다. 이 예에서, 레이트 제어 유닛 (66) 은 단순히, 허용 가능한 지연 량 (예를 들어, 미리 결정된 임계치보다 작은 지연) 을 측정하기 시작할 수도 있다. 레이트 제어 유닛 (66) 은 지연 량이 요구되는 것보다 작은 것으로 결정하면 (예를 들어, 패킷이 적절하게 스케줄링된 플레이아웃을 위해 요구되는 것보다 일찍 도착하면), 레이트 제어 유닛 (66) 은 전송기 디바이스 인코딩 레이트를 증가/상승시키기 위한 다른 메시지 (예를 들어, 다른 TMMBR 메시지) 를 전송할 수도 있다.
업 스위칭과 관련하여, 전송기 디바이스와 수신기 디바이스 사이의 채널 (이를테면, 인코더 시스템 (12) 과 디코더 시스템 (14) (도 1) 사이의 채널 (16)) 이 전송기 디바이스에 의해 이용되고 있을 때, 비디오 패킷의 비디오 디코더 (42) 로의 전달은 그러한 비디오 패킷이 실제로 플레이아웃될 필요가 있기 전에 발생할 (예를 들어, 데이터와 함께 표시된 플레이아웃 시간 전에 수신될) 가능성이 있다. 그러한 경우, 전송기 레이트는 증가될 수도 있고 사용자 경험에 부정적인 영향을 주지 않으면서 시스템에 약간의 추가 지연이 도입될 수도 있다.
송신 경로에 도입될 수도 있는 초과 비트는 채널 대역폭이 레이트 제어 유닛 (66) 에서 측정된 평균 수신 레이트와 동일한 경우에 아래 등식 (3) 에 따라 계산될 수도 있다 (예를 들어, 최악의 경우 사용 가능한 스페어 채널 대역폭이 없음):
Figure pct00003
식중, excess_bits 는 시스템에 도입되는 추가 비트를 나타내고, rate_increase_step 은 인코딩 레이트의 증가를 나타내며, RTT 는 왕복 시간을 나타내며, receiver_detection_delay 는 수신기에 의한 시스템에서 지연을 검출하는 것과 연관된 지연을 나타낸다 (이것은 본 명세서에 기재된 기술들 중 임의의 것에 따라 결정될 수도 있다).
일부 예에서, 레이트 제어 유닛 (66) 은 아래의 등식 (4) 에 따라 초과 비트 (excess_bits) 가 도입됨에 기인하여 대응하는 최악의 경우의 초과 지연 (excess_delay) 을 결정할 수도 있다:
Figure pct00004
식중, excess_delay 는 전송기 디바이스에서 도입된 지연의 양을 나타내고, rate_increase_step 은 인코딩 레이트의 증가를 나타내고, RTT 는 전송기 디바이스와 비디오 디코더 (42) 간의 왕복 시간을 나타내며, receiver_detection_delay 는 레이트 제어 유닛 (66) 에 의해 시스템에서 지연을 검출하는 것과 연관된 지연을 나타내고, avg_receiving_rate 는 비디오 디코더 (42) 에서 데이터가 수신되고 있는 레이트를 나타낸다.
따라서, 일부 예에서, 본 개시의 양태에 따르면, 비디오 디코더 (42) 의 레이트 제어 유닛 (66) 은 특정 레이트 증가와 연관된 초과 비트 (예를 들어, excess_bits) 의 수 및 초과 비트의 도입과 연관된 지연 (예를 들어, excess_delay) 을 결정할 수도 있다.
레이트 제어 유닛 (66) 은 허용 가능한 초과 지연 파라미터에 기초하여 레이트 증가 량을 산출할 수도 있다. 예를 들어, 레이트 제어 유닛 (66) 은 아래의 등식 (5) 에 따라 시스템에 혼잡 및/또는 지연을 도입하지 않고서 전송기 디바이스에 의해 전송 레이트가 얼마나 많이 증가될 수도 있는지를 결정할 수도 있다:
Figure pct00005
식중, rate_increase_step 은 전송 레이트가 증가될 수도 있는 양 (전송기 비트 레이트 증가로 지칭될 수도 있음) 을 나타내며, allowable_excess_delay 는 허용 가능한 초과 지연 파라미터 (이하에서 더 상세히 설명됨) 를 나타내며, avg_receiving_rate 는 레이트 증가를 결정하기 전에 데이터가 수신된 평균 레이트를 나타내고, RTT 는 비디오 디코더 (42) 와 전송기 디바이스 (이를테면 비디오 인코더 (20)) 사이의 왕복 시간을 나타내고, receiver_detection_delay 는 비디오 디코더 (42) 에서의 지연을 식별하는 데 필요한 시간 량을 나타낸다. 일부 경우에, 수신기 검출 지연 파라미터는 구현에 의존할 수도 있고, 오프라인 테스팅에서 추정되거나 또는 측정될 수도 있다. 이러한 수신기 검출 지연이 이용 가능하지 않은 경우, 레이트 제어 유닛 (66) 은 레이트 제어 유닛 (66) 이 지연을 식별하는데 필요한 시간의 상대적으로 보수적인 추정일 수도 있는 추정된 반응 지연을 사용하도록 구성될 수도 있다.
전송기 디바이스로부터, 비디오 디코더 (42) 를 포함하는 수신기 디바이스로의 일방향 지연은 일반적으로 수신기 디바이스에 알려지지 않기 때문에, 수신기 디바이스는 일반적으로 허용 가능한 초과 지연 파라미터 (allowable_excess_delay) 를 산출하기 위해 이것을 사용하지 않을 수도 있다. 대신에, 본 개시의 양태에 따르면, 레이트 제어 유닛 (66) 은 수신된 비디오 패킷들로부터 허용 가능한 초과 지연의 양을 결정할 수도 있다. 예를 들어, 레이트 제어 유닛 (66) 은 비디오 패킷들이 비디오 디코더 (42) 에서 수신 및/또는 처리되는 시간을 결정할 수도 있다. 레이트 제어 유닛 (66) 은 또한 비디오 패킷과 연관된 비디오 데이터가 플레이아웃되도록 (예를 들어, 사용자에게 표시되도록) 지정되는 시간을 결정할 수도 있다. 레이트 제어 유닛 (66) 은 패킷들이 수신 및/또는 평가되는 시간과 플레이아웃 시간 사이의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정할 수도 있다.
허용 가능한 초과 지연 파라미터는 일반적으로 사용자 경험에 영향을 미치지 않고 비트 레이트를 증가시키기 위한 기초로서 전송기 디바이스에 의해 이용될 수도 있는 시간 량을 나타낼 수도 있다. 예를 들어, 허용 가능한 초과 지연 파라미터는, 사용자 경험에 영향을 미치지 않고서, 예를 들어 데이터가 비디오 디코더 (42) 에 너무 늦게 도착하여 적절한 시간에 디코딩 및 플레이아웃될 수 없도록 채널 (16) 에 의해 지원 가능하지 않는 레이트로 전송 레이트를 증가시키지 않으면서, 전송 레이트를 증가시키는데 사용될 수도 있는 시간 량을 나타낼 수도 있다. 허용 가능한 초과 지연 메트릭은, 수신된 패킷에 있는 비디오 정보가 열화 (예를 들어, 지터, 스터터링 (stuttering) 또는 손실 프레임) 없이 사용자에게 실제로 표시될 수도 있는지 여부를 직접적으로 나타내므로, 사용자 경험의 관점에서 보다 정확할 수도 있다.
본 개시의 양태들에 따르면, 상기 분석에 기초하여, 레이트 제어 유닛 (66) 은 업 스위칭을 수행하기 위한 수신기 디바이스 및 전송기 디바이스에서의 다음과 같은 요건들을 부과할 수도 있다:
● 수신기는 패킷의 도착을 조사하고 이것을 정기적으로 스케줄링된 플레이아웃 시간과 비교하여 송신 경로에 도입될 수 있는 허용 가능한 지연 량: allowable_excess_delay 이 있는지 여부를 결정해야 한다.
● 수신기는 패킷의 도착을 조사하여 평균 수신 레이트: avg_receiving_rate 를 산출해야 한다.
● 수신기는 왕복 시간 : RTT 을 산출해야 한다.
● 수신기는 다음과 같이 rate_increase_step 을 산출해야 한다:
rate_increase_step = allowable_excess_delay * avg_receiving_rate / (RTT + receiver_detection_delay)
● AVPF (Audio Visual Provide with Feedback) RTCP 송신 규칙에 의해 허용되면, 수신기는:
rate_increase_step> 5 % x avg_receiving_rate 를 검출하면, TMMBR (Temporary Maximum Media Stream Bit rate Request) 을 전송 해야 하고,
rate_increase_step> 15 % x avg_receiving_rate 를 감출하면 TMMBR 을 전송해야 한다
● TMMBR 메시지를 보낼 때 TMMBR에서 requested_rate :
는 다음과 동일해야 한다:
avg_receiving_rate + rate_increase_step
는 다음과 같야야 한다:
avg_receiving_rate + 0.80(rate_increase_step) <= requested_rate <= avg_receiving_rate + rate_increase_step
또한, 본 개시의 양태에 따르면, 업 스위칭을 수행하기 위해 전송기 디바이스에 다음 요건들이 부과될 수도 있다:
● TMMBR (Temporary Maximum Media Stream Bit Rate Request) 을 수신할 시에, 비디오 전송기는 그의 전송 레이트를 requested_rate 로 500ms 내에 상승시켜야 하고 그것을 1초 이내에 상승시켜야 한다.
위에서 언급한 "요건" 은 예시의 목적을 위해 제공되며, 본 개시의 기술은 또한 상술한 특정 값과 상이한 값을 사용하여 적용될 수도 있다는 것을 이해해야 한다. 또한, 설명의 목적으로 특정 기술들이 (예를 들어, 레이트 제어 유닛 (66) 과 같은) 도 3의 특정 유닛들에 기인하지만, 비디오 디코더 (42) 의 하나 이상의 다른 유닛들이 그러한 기술들을 수행하는 것을 담당할 수도 있다는 것이 이해되야 한다. 더욱이, VT는 종종 양방향 통신 흐름이기 때문에, 유사한 기술들이 순방향 및 역방향 네트워크 경로들 양쪽 모두에, 예를 들어 (도 2의 비디오 인코더 (20) 를 포함하는 디바이스와 같은) 전송기 디바이스로서 본 명세서에서 지정된 디바이스 및 (도 3의 비디오 디코더 (42) 를 포함하는 디바이스와 같은) 수신기 디바이스로서 본 명세서에서 지정된 디바이스 양자 모두에 의해, 적용될 수도 있다.
도 4a 및 도 4b는 본 개시와 일치하는 비디오 소스 레이트 적응화 기술을 나타내는 그래프이다. 예를 들어,도 4a는 일반적으로 네트워크 링크 레이트의 감소를 포함하는 시간 동안 (예를 들어, 인코더 시스템 (12) 과 같은) 전송기 디바이스에서 인코딩된 데이터의 비트 레이트를 도시한다. 도 4b는 일반적으로 네트워크 링크 레이트의 감소와 연관되는 결과로 생긴 지연을 도시한다. 도 4a 및 도 4b의 기술들은 인코더 시스템 (12) 과 관련하여 설명되지만, 기술들은 다양한 다른 컴포넌트들을 갖는 다양한 다른 전송기 디바이스들에 의해 수행될 수 있음을 이해해야 한다.
도 4a의 예에서, 시간 순간 t0 에서, 링크 레이트 (네트워크 링크 레이트 또는 대역폭으로도 지칭됨) 는 라인 80에 의해 나타낸 바와 같이 R0 에서 R1 로 감소하고, 여기서 전송 레이트 = 링크 레이트). 네트워크 링크 레이트의 하락에 응답하여, 인코더 시스템 (12) 은 전송 레이트를 감소시킬 수도 있다. 그러나,도 4a 의 예에 도시된 바와 같이, 점선 (82) 으로 나타낸 바와 같이, 전송 레이트를 감소시키는 것과 연관된 t0 에서 t1 까지의 응답 지연 (ΔT) 이 있다. 응답 지연은 또한 여기서 버퍼링 지속시간으로서 기술될 수도 있고, 그 시간 동안 전송 레이트는 네트워크 링크 레이트에 오버슈트하고 인코더 시스템 (12) 이 네트워크 링크에 의해 수용될 수 없는 데이터를 버퍼링하는 것을 담당한다.
도 4b의 예에서 라인 (84) 에 의해 나타낸 바와 같이, 지연 (예를 들어, 인코딩된 데이터가 송신에 이용 가능한 시간과 인코딩된 데이터가 실제로 송신되는 시간 사이의 시간) 은 응답 지연 (△T) 동안 D0 에서 D1 으로 비교적 빠르게 증가한다. 즉, 네트워크 링크 레이트 t0 의 하락 시간과 네트워크 링크 레이트 t1의 하락의 식별의 시간 사이에서 D0 에서 D1 으로 지연이 상대적으로 빠르게 증가한다. 지연은 인코더 시스템 (12) 에서 버퍼링되는 데이터의 양에 비례할 수도 있다.
시간 t1 에서,도 4a 및 도 4b의 예는 발산 전송 레이트 기술 (diverging sending rate technique) 을 도시한다. 예를 들어, 실선 80 은 인코더 시스템 (12) 이 네트워크 링크 레이트에서 전송 레이트를 유지하는 제 1 예를 나타낸다. 예를 들어, 네트워크 링크 레이트의 하락을 식별할 시에, 인코더 시스템 (12) 은 원래의 레이트 R0 에서 새로운, 감소된 네트워크 링크 레이트 R1 으로 전송 레이트를 감소시킨다. 이 예에서, 대응하는 지연은 실선 88 로 나타낸 바와 같이 비교적 높게 남아있다. 즉, 전송 레이트가 네트워크 링크 레이트 R1 으로 설정되기 때문에 버퍼링된 데이터의 양을 줄일 초과 대역폭이 없다.
점선 82 및 86 은 인코더 시스템 (12) 이 원래의 레이트 (R0) 로부터 네트워크 링크 레이트 (R1) 보다 작은 감소된 레이트 (RU) 로 전송을 감소시키는 제 2 예를 도시한다. 이것은 네트워크 링크 레이트에 "언더슈트하는 것" 으로 지칭될 수도 있다. 이 예에서, 인코더 시스템 (12) 은 결정된 복구 레이트 지속시간 (ΔTu) 동안 감소된 레이트 (Ru) 를 유지할 수도 있다. 이 시간 동안, 점선 (90) 에 의해 도시된 바와 같이, 인코더 시스템 (12) 은 시간 t2 에서 지연을 D1 으로부터 D2 로 감소시킨다.
본 명세서에 설명된 바와 같이, 인코더 시스템 (12) 은 다양한 기술을 사용하여 감소된 레이트 (RU), 버퍼링 지속시간 (ΔT), 및 복구 레이트 지속시간 (ΔTu) 을 결정할 수도 있다. 일 예에서, 인코더 시스템 (12) 은 수학 식 (1-fU) × R1 에 기초하여 감소된 레이트 (RU) 를 결정할 수도 있으며, 식중 fU 는 언더슈트 팩터이고 R1 은 감소된 링크 레이트이고, fU 는 레이트 언더슈트 팩터 (1-fU) 를 결정하고 0 <fU <1이며, 이는 전송 레이트를 링크 레이트 R1과 관련시킨다. 일부 예들에서, fU 는 네트워크 링크 레이트 저하의 크기에 의존할 수도 있으며, 이것은 등식 ΔR = (R0-R1) 으로 나타낼 수도 있다. 이 예에서,도 4a 에 도시 된 바와 같이, R0 은 감소되기 전의 제 1 네트워크 링크 레이트이다. 네트워크 링크 레이트 하락 ΔR의 크기가 클 경우, fU 는 비례하여 커질 수도 있다. 다른 예들에서, Δ R이 작으면, fU 는 이하의 등식 (6) 에 보여진 바와 같이 비례하여 작아질 수도 있다:
Figure pct00006
인코더 시스템 (12) 이 버퍼링 지속시간 (ΔT) 동안 모든 비트를 버퍼링하고 지연에 기여하는 경우, 인코더 시스템 (12) 은 아래의 등식 (7) 에 기초하여 복구 레이트 지속시간 (ΔTu) 을 결정할 수도 있다:
Figure pct00007
식중, ΔTu는 복구 레이트 지속시간이고, ΔT는 버퍼링 지속시간을 포함하고, R0 은 제 1 네트워크 링크 레이트를 포함하고, R1 은 제 2의 감소된 네트워크 링크 레이트를 포함하고, fU 는 레이트 감소 팩터를 포함한다.
일부 예에서, 인코더 시스템 (12) 은 최소 비트 레이트 요건을 적용 할 수도 있다. 최소 비트 레이트 요건은 비디오 인코더 (20) 의 능력, 사용자 경험을 위한 최소 시스템 요구사항 등에 기초할 수도 있다. 인코더 시스템 (12) 이 최소 비트 레이트 요건을 적용하는 예에서, 비디오 인코더 (20) 는 최소 비트 레이트 요건을 RU 에 적용할 수도 있고, 따라서 언더슈트 팩터 fU 에도 적용할 수도 있다. 예를 들어, 인코더 시스템 (12) 은 감소된 레이트 RU 및 언더슈트 팩터 fU 를 결정하기 위해 이하의 등식 (8) 및 등식 (9) 를 적용할 수도 있다:
RU >= Rmin (8)
fU <= 1-(Rmin/R1) 여기서 R1 > Rmin (9)
식중, RU 는 감소된 비트 레이트이고, Rmin은 최소 인코딩 레이트이고, R1 은 제 2, 감소된 네트워크 링크 레이트이고, fU 는 언더슈트 팩터이다.
복구 레이트 지속시간 (ΔTu) 동안, 새로운 레이트 값 (R2) 를 전하는 TMMBR 메시지가 인코더 시스템 (12) 에 의해 수신되고, R2 가 R1 보다 상당히 클 경우 (예를 들어, R2 가 R1 에 1.2를 곱한 것보다 크거나 같을 경우), 인코더 시스템 (12) 은 복구 레이트 지속시간을 단축시킬 수도 있다. 역으로, R2 가 R1 보다 작은 경우, 인코더 시스템 (12) 은 추가 또는 연장된 복구 레이트 지속시간을 결정할 수도 있다.
일반적으로,도 2 및 도 3과 관련하여 전술한 바와 같이, 인코더 시스템 (12) 은 RTT, (예를 들어, 수신기 대 전송기) 다운링크 지연, 레이트 제어 반응 지연에 관한 지식, 혼잡 제어의 반응 지연 (예를 들어, 링크 레이트의 추정), 메시지 생성 지연 (예를 들어, RTCP 패킷을 생성하는 것과 연관된 지연) 등과 같은 네트워크 정보로부터 버퍼링 지속시간 (ΔT) 을 추정할 수도 있다. 이러한 네트워크 정보는 전송기 측에서 이용 가능할 수 있거나 또는 비디오 디코더 (42) (도 3) 를 포함하는 디바이스와 같은 수신기 디바이스에 의해 인코더 시스템 (12) 으로 시그널링될 수도 있다.
도 4a 및 도 4b의 예는 설명을 위해 R0 와 RU 사이의 계단식 변화 (예를 들어, R0 와 RU 사이의 단일 레이트 변화) 를 예시하지만, 언더슈트 프로파일이 보다 점진적이도록 기술을 반복적으로 적용할 수도 있음을 이해해야 한다.
도 5 는 본 개시의 기술과 일치하는 버퍼링 지속시간을 결정하는 것을 나타내는 개념도이다. 도 5의 예에서, (예를 들어, 인코더 시스템 (12) 과 같은) 전송기 디바이스는 시간 120에서 (예를 들어, 디코더 시스템 (14) 과 같은) 수신기 디바이스에 RTCP 전송기 리포트 (SR) 를 전송할 수도 있다. 예를 들어, 위에서 언급한 RFC 3550 에 설명된 대로, 여러 RTCP 패킷 유형을 사용하여 다양한 제어 정보를 전할 수도 있다. 활성 전송기인 참가자로부터 송신 및 수신 통계에 전송기 리포트 (SR) 가 사용될 수도 있다. 마찬가지로, 수신기 리포트 (RR) 은 활성 전송기가 아닌 참여자로부터의 수신 통계에 그리고 31개가 넘는 소스에 대한 활성 전송기 리포팅에 SR과 조합하여 사용될 수도 있다. 수신기 디바이스는 시간 122 에서 RTCP SR 를 수신할 수도 있다.
수신기 디바이스는 시간 124에서 순방향 채널에 대한 추정된 최대 비트 레이트로 전송기 디바이스에 RTCP TMMBR 메시지를 전송할 수도 있다. 일부 예에서, 메시지를 생성하는 것과 연관된 지연이 있을 수도 있지만, 수신기 디바이스는 혼잡을 검출한 직후에 TMMBR 메시지를 전송할 수도 있다. 설명을 위해 TMMBR 메시지가 기술되었지만, 지연/혼잡을 나타낼 수도 있는 다양한 다른 메시지가 사용될 수 있다.
버퍼링 지속시간 (ΔT) 을 추정하는 것으로 전송기 디바이스를 가능하게 하기 위해, 수신기 디바이스는 또한 시간 124에서 RTCP RR 메시지를 전송할 수도 있다. 본 개시의 양태들에 따르면, 수신기 디바이스는 TMMBR 메시지 직후에 RR 메시지를 전송할 수도 있다. 이러한 방식으로, 전송기 디바이스는 시간 126 에서 TMMBR 메시지 및 RR 메시지를 수신할 수도 있고, 버퍼링 지속시간 (ΔT) (128) 에 대한 상한을, RR에 포함된 최종 SR 타임스탬프 (LSR 데이터) 에 의해 RR 에서 참조되는 SR 을 전송하는 것과 RR 이 수신된 시간 사이의 시간 차이로서 계산할 수도 있다. 즉, 수신기 디바이스는 비트 레이트 제한에 대한 요청을 나타내는 제 1 데이터 (예를 들어, TMMBR 메시지) 및 메시지가 생성된 시간을 나타내는 제 2 데이터 (예를 들어, LSR 데이터) 를 전송할 수도 있다. LSR 데이터는 소스로부터 가장 최근의 RTCP SR 패킷의 일부로서 수신된 64 비트 네트워크 타임 프로토콜 (NTP) 타임스탬프 중 중간 32 비트를 포함할 수도 있다. SR이 아직 수신되지 않은 경우, LSR 타임스탬프 필드는 0 으로 설정될 수도 있다.
다른 예에서, 상술한 데이터와 함께 2개의 별개의 연속적인 메시지들 (예컨대, TMMBR 및 RTCP RR) 을 전송하기 보다는, TMMBR 데이터 및 RTCP RR 데이터는 단일 RTCP 메시지로 그룹화될 수도 있다. 최소한으로, 수신기 디바이스는 전송기 디바이스가 버퍼링 지속시간 (ΔT) (128) 을 추정할 수 있게 하는 LSR 데이터를 전송할 수도 있다. 이 예에서, 메시지 사이즈는 감소될 수도 있다.
수신기 디바이스는 수신기 디바이스가 이전에 동일한 LSR을 갖는 RTCP RR 메시지를 전송했더라도, 최종 수신된 RTCP SR 메시지의 LSR을 사용할 수도 있다. 수신기 디바이스가 아직 RR을 전송하지 않았다면, 수신기 디바이스는 TMRR 메시지와 전체 RR 메시지를 조합할 수도 있다. 다른 예들에서, 메시지 사이즈를 줄이기 위해, 수신기 디바이스는 RTT 를 계산하기 위해 사용할 수도 있는 TMMBR 메시지와 함께 LSR 데이터만을 전송할 수도 있다.
다른 예에서, 수신기 디바이스가 이미 RR을 전송한 경우, 전송기 디바이스는 최종 수신된 RR 메시지를 수신하는 것과 (예를 들어, 혼잡이 검출된 후 수신기에 의해 전송된) 새로운 RR 메시지를 수신하는 것 사이의 시간 차이로서 보다 정확하게 버퍼링 지속시간 (ΔT) (128) 을 계산할 수도 있다.
또 다른 예에서, 전송기 디바이스는 지연 (예를 들어, RTT) 을 모니터링할 수도 있고, 전송기 디바이스는 지연이 충분히 감소될 때까지 감소된 레이트 Ru 로 데이터를 계속 전송할 수도 있다. 예를 들어, 전송기 디바이스는 전송기 디바이스의 버퍼에 저장된 데이터의 양이 임계 레벨 아래로 떨어질 때까지 감소된 레이트 Ru 로 전송 레이트를 유지할 수도 있다.
도 6a 및 도 6b 는 각각 네트워크 링크 레이트 하락 및 대응 지연 시간을 나타내는 그래프이다. 도 6a의 그래프는 도 4a의 라인 80 과 연관될 수도 있는 반면, 도 6b의 그래프는 도 4b의 라인 88 과 연관될 수도 있다. 예를 들어, 도 6a는 점선 (네트워크 링크 레이트로도 지칭됨) 으로 나타낸 네트워크 대역폭 (140) 및 실선 (또한 인코딩 비트 레이트로 지칭됨) 으로 나타낸 전송 레이트 (142) (예를 들어, 초당 킬로바이트 (KBPS) 로 측정됨) 를 보여준다. 도 6a에 도시된 바와 같이, (예를 들어, 인코더 시스템 (12) 과 같은) 전송기 디바이스는 대역폭 (140) 과 동일하거나 유사한 레이트에서의 전송 레이트 (142) 로 데이터를 인코딩할 수도 있다. 따라서, 시간 (144) 에서 대역폭 (140) 이 감소되면, 전송기 디바이스는 전송 레이트 (142) 를 대역폭 (140) 과 대략 동일한 값으로 감소시킬 수도 있다.
도 6b 의 대응하는 지연 그래프에 도시된 바와 같이, 대역폭 (140) 의 하락에 이어서, 인코더 시스템 (12) 에서의 지연은 제 1 레벨 (146) 에서 제 2 레벨 (148) (예를 들어, 밀리초 (MS) 로 측정됨) 로 증가될 수도 있다. 본 명세서에 설명된 바와 같이, 전송 레이트 (142) 를 대역폭 (140) 의 레벨로 감소시키는 것과 연관된 반응 시간이 있기 때문에, 대역폭의 하락에 따라 지연이 증가한다. 인코더 시스템 (12) 은 대역폭 (140) 을 매치시키기 위해 전송 레이트 (142) 를 감소시키기 전에 원래 (더 높은) 레이트로 인코딩된 버퍼 데이터를 버퍼링할 수도 있다. 도 6b에 도시된 바와 같이, 지연을 감소시키기 위한 기술이 적용되지 않으면 지연은 비교적 긴 지속시간 동안 지속될 수도 있다.
도 7a 및 도 7b 는 각각 네트워크 링크 레이트 하락 및 대응 지연 시간을 나타내는 그래프이다. 도 7a의 그래프는 도 4a의 라인 82 및 라인 86 과 연관될 수도 있는 반면, 도 7b의 그래프는 도 4b의 점선 90 과 연관될 수도 있다. 예를 들어, 도 7a는 점선 (네트워크 링크 레이트로도 지칭됨) 으로 도시된 네트워크 대역폭 (160) 및 실선 (또한 인코딩 비트 레이트로 지칭됨) 으로 도시된 전송 레이트 (162) (예를 들어, 초당 킬로바이트 (KBPS) 로 측정됨) 를 보여준다. 도 7a에 도시된 바와 같이, (예를 들어, 인코더 시스템 (12) 과 같은) 전송기 디바이스는 초기에, 대역폭 (160) 과 동일하거나 유사한 레이트에서의 전송 레이트 (162) 로 데이터를 인코딩할 수도 있다.
본 개시의 양태에 따르면, 시간 (164) 에서 대역폭 (160) 이 감소될 때, 전송기 디바이스는 전송 레이트를 대역폭 (160) 보다 작은 감소된 레이트로 감소시킬 수도 있다. 즉, 전송기 디바이스는 대역폭 (160) 의 하락과 연관된 지연을 감소시키기 위해 대역폭 (140) 에 언더슈트하는 전송 레이트 (162) 를 결정할 수도 있다. 본 명세서에서 설명된 바와 같이, 전송기 디바이스는 본 개시의 기술에 따라 버퍼링 지속시간, 감소된 레이트 및/또는 복구 레이트 지속시간을 결정할 수도 있다.
도 7b 의 대응하는 지연 그래프에 도시된 바와 같이, 대역폭 (160) 의 하락에 이어서, 인코더 시스템 (12) 에서의 지연은 제 1 레벨 (166) 에서 제 2 레벨 (168) (예를 들어, 밀리초 (MS) 로 측정됨) 로 증가될 수도 있다. 위에서 언급된 바와 같이, 대역폭 (160) 의 하락에 응답하여 전송 레이트 (162) 를 감소시키는 것과 연관된 반응 시간이 있기 때문에, 대역폭의 하락에 따라 지연이 증가한다. 그러나, 전송 레이트 (162) 를 (대역폭 (160) 에 언더슈트하는) 감소된 레이트로 감소시킴으로써, 인코더 시스템 (12) 은 도 6b에 도시된 예보다 더 신속하게 지연을 감소시킬 수도 있다.
도 8 은 데이터가 송신되는 레이트를 다운 스위칭하기 위한 예시적인 프로세스를 나타내는 흐름도이다. 도 8의 예는 설명의 목적으로 인코더 시스템 (12) 에 관하여 설명된다. 그러나, 도 8의 프로세스는 다양한 다른 디바이스들 및/또는 프로세서들에 의해 수행될 수도 있음을 이해해야 한다.
인코더 시스템 (12) 은 제 1 레이트로 네트워크를 통해 데이터를 인코딩하고 송신할 수도 있다 (180). 제 1 레이트로 데이터를 송신하는 동안, 인코더 시스템 (12) 은 제 1 레이트에서 제 2 레이트로의 네트워크 링크 레이트의 감소를 식별 할 수도 있다 (182). 예를 들어, 인코더 시스템 (12) 은 네트워크 상태를 모니터링하거나 및/또는 네트워크 링크 레이트의 감소를 나타내는 하나 이상의 메시지를 수신할 수도 있다.
인코더 시스템 (12) 은 제 2 (감소된) 네트워크 링크 레이트보다 작은 복구 비트 레이트를 결정할 수도 있다 (184). 예를 들어, 인코더 시스템 (12) 은 새로운 네트워크 링크 레이트에 언더슈트하는 데이터를 인코딩하기 위한 비트 레이트를 결정할 수도 있다. 본 개시의 양태에 따르면, 인코더 시스템 (12) 은 제 1 네트워크 링크 레이트와 감소된 네트워크 링크 레이트 사이의 차이에 기초하여 복구 비트 레이트를 결정할 수도 있다. 예를 들어, 네트워크 링크 레이트의 감소가 비교적 큰 경우, 인코더 시스템 (12) 은 비교적 공격적인 (예를 들어, 감소된 레이트에 상당한 마진만큼 언더슈트하는) 복구 비트 레이트를 결정할 수도 있다. 마찬가지로, 네트워크 링크 레이트의 감소가 비교적 낮은 경우, 인코더 시스템 (12) 은 비교적 보수적인 (예를 들어, 감소된 레이트에 비교적 작은 마진만큼 언더슈트하는) 복구 비트 레이트를 결정할 수도 있다.
인코더 시스템 (12) 은 또한, 반응 지연 (예를 들어, 네트워크 링크 레이트의 감소에 응답하여 전송 레이트를 감소시키는 것과 연관된 시간) 에 기초하여 버퍼링 지속시간을 결정할 수도 있다 (186). 인코더 시스템 (12) 은 다양한 방식으로 버퍼링 지속시간을 결정할 수도 있다. 예를 들어, 인코더 시스템 (12) 은 인코더 시스템 (12) 과 수신기 디바이스 사이의 왕복 시간 (RTT), 다운 링크 지연, 레이트 적응화 반응 지연, 혼잡 제어의 반응 지연, 메시지 생성 지연 등과 같은 네트워크 정보로부터 버퍼링 지속시간을 추정함으로써 버퍼링 지속시간을 결정할 수도 있다. 인코더 시스템 (12) 은 네트워크 정보를 독립적으로 결정할 수도 있거나 또는 수신기 디바이스로부터 네트워크 정보를 수신할 수도 있다.
그 후, 인코더 시스템 (12) 은 복구 비트 레이트를 유지하기 위해 복구 레이트 지속시간을 결정할 수도 있다 (188). 일부 예들에서, 인코더 시스템 (12) 은 복구 레이트의 크기에 기초하여 그리고 버퍼링 지속시간에 기초하여 복구 레이트 지속시간을 결정할 수도 있다. 일부 예들에서, 인코더 시스템 (12) 은 (예를 들어, 복구 레이트에 의해 나타낸 바와 같이) 네트워크 링크 레이트의 감소의 크기 및 (예를 들어, 버퍼링 지속시간에 의해 나타낸 바와 같이) 네트워크 링크 레이트의 감소에 반응하는 것과 연관된 시간의 양에 비례하는 버퍼링 지속시간을 결정할 수도 있다.
인코더 시스템 (12) 은 복구 레이트 지속시간 동안 데이터를 복구 비트 레이트로 송신할 수도 있다 (190). 일부 예에서, 복구 레이트 지속시간 동안 네트워크 링크 레이트가 증가하면, 인코더 시스템 (12) 은 복구 레이트 지속시간을 조기에 종료시킬 수도 있고 보다 높은 전송 레이트로 업 스위칭할 수도 있다. 예에 따라, 도 8 과 관련하여 설명된 기술들 중 어느 것의 특정 행위들 또는 이벤트들이 상이한 시퀀스에서 수행될 수도 있거나, 추가될 수도 있거나, 병합될 수도 있거나, 또는 전부 생략될 수도 있다 (예를 들어, 모든 설명된 행위들 또는 이벤트들이 그 기법들의 실시를 위해 필요한 것은 아니다) 는 것이 이해되야 한다.
도 9 은 데이터가 송신되는 레이트를 업 스위칭하기 위한 예시적인 프로세스를 나타내는 흐름도이다. 도 9의 예는 설명의 목적으로 디코더 시스템 (14) 에 관하여 설명된다. 그러나, 도 9의 프로세스는 다양한 다른 디바이스들 및/또는 프로세서들에 의해 수행될 수도 있음을 이해해야 한다.
디코더 시스템 (14) 은 데이터가 수신되는 시간을 결정할 수도 있다 (200). 예를 들어, 일부 경우에서, 디코더 시스템 (14) 은 데이터가 수신되고 디코더 시스템 (14) 에 저장되는 시간을 식별할 수도 있다. 다른 경우에, 디코더 시스템 (14) 은 데이터가 디코더 시스템 (14) 에 의해 처리 (예를 들어, 디코딩) 되는 시간을 식별할 수도 있다.
디코더 시스템 (14) 은 또한, 수신된 데이터의 플레이아웃 시간을 결정할 수도 있다 (202). 예를 들어, 수신된 데이터는 사용자에게 표시하기 위해 데이터가 출력되도록 의도된 시간의 표시를 포함할 수도 있다. 따라서, 플레이아웃 시간의 표시는 디코더 시스템 (14) 이 출력을 위해 데이터를 편성하는데 도움을 줄 수도 있다.
디코더 시스템 (14) 은 허용 가능한 초과 지연 파라미터를 결정할 수도 있다 (204). 예를 들어, 디코더 시스템 (14) 은 데이터가 수신되는 시간과 수신된 데이터가 플레이아웃되도록 스케줄링되는 시간 사이의 차이에 기초하여 허용 가능한 초과 지연 파라미터를 결정할 수도 있다. 본원에 기술된 바와 같이, 지연은 네트워크 링크를 통한 송신에 이용가능한 데이터와 실제로 데이터가 전송기 디바이스에서 네트워크에 송신되는 시간 사이의 시간을 나타낼 수도 있다. 따라서, 허용 가능한 초과 지연 파라미터는 사용자 경험이 영향을 받기 전에 시스템에 의해 지원 가능한 지연의 양을 나타낼 수도 있다. 즉, 허용 가능한 초과 지연 파라미터는 일반적으로 사용자 경험에 영향을 미치지 않고 비트 레이트를 증가시키기 위한 기초로서 전송기 디바이스에 의해 이용될 수도 있는 시간 량을 나타낼 수도 있다.
디코더 시스템 (14) 은 전송기 비트 레이트 증가를 결정할 수도 있다 (206). 예를 들어, 본 개시의 양태들에 따르면, 디코더 시스템 (14) 은 허용 가능한 초과 지연 파라미터에 기초하여 전송기 비트 레이트 증가를 결정할 수도 있다. 즉, 디코더 시스템 (14)은 시스템에 혼잡을 도입하지 않고서 전송기 디바이스가 전송 레이트를 얼마나 많이 증가시킬 수 있는지를 결정할 수도 있다.
일부 예에서, 디코더 시스템 (14) 은 전송 레이트에 부가될 계단식 레이트 증가를 결정할 수도 있다. 예를 들어, 디코더 시스템 (14) 은 허용 가능한 초과 지연 파라미터 및 전송 레이트 증가를 결정하기 전에 데이터가 수신된 현재의 평균 전송 레이트 (예를 들어, 현재 수신 레이트) 에 기초하여 전송기 비트 레이트 증가를 결정할 수도 있다. 이 예에서, 디코더 시스템 (14) 은 지속 가능한 링크 레이트 (예를 들어, 패킷의 스케줄링된 플레이아웃 시간 후에 패킷이 디코더 시스템 (14) 에 도착하는 레이트) 를 초과하여 레이트를 증가시키지 않고서 현재의 전송 레이트가 얼마나 많이 증가될 수 있는지를 결정할 수도 있다.
일부 경우에, 디코더 시스템 (14) 은 또한 디코더 시스템 (14) 과 전송기 디바이스 사이의 메시지를 송신하는 데 필요한 시간 량 (예를 들어, 왕복 시간) 및/또는 디코더 시스템 (14) 에서의 지연을 식별하는 것과 연관된 지연을 설명 (account for) 할 수도 있다. 예를 들어, 디코더 시스템 (14) 은 왕복 시간과 디코더 시스템 (14) 에서의 지연을 검출하는 시간의 합에 대한, 허용 가능한 초과 지연 파라미터에 수신 레이트를 곱한 것의 비에 기초하여 전송기 비트 레이트 증가를 결정할 수도 있다.
다음으로, 디코더 시스템 (14) 은 또한 전송 레이트 증가의 표시를 송신할 수도 있다 (208). 예를 들어, 디코더 시스템 (14) 은 전송기 디바이스가 전송 레이트에 부가할 계단식 전송 레이트 증가를 나타내는 데이터를 전송기 디바이스에 전송할 수도 있다. 다른 예에서, 디코더 시스템 (14) 은 전송기 디바이스에 전송 레이트 증가를 포함하는 요청된 전송 레이트를 나타내는 데이터를 전송할 수도 있다.
일부 예에서, 디코더 시스템 (14) 은 전송기 비트 레이트 증가가 임계량을 초과할 때 전송기 비트 레이트 증가의 표시만을 송신할 수도 있다. 예를 들어, 디코더 시스템 (14) 은 전송기 비트 레이트 증가를 미리 결정된 임계치와 비교할 수도 있다. 일 예에서, 디코더 시스템 (14) 은 전송기 비트 레이트 증가가 수신 레이트의 대략 5 퍼센트를 초과할 때 전송기 비트 레이트 증가의 표시만을 송신할 수도 있다. 다른 예에서, 디코더 시스템 (14) 은 전송기 비트 레이트 증가가 수신 레이트의 대략 15 퍼센트를 초과할 때 전송기 비트 레이트 증가의 표시만을 송신할 수도 있다. 다른 임계 값 또는 퍼센트도 가능하다.
예에 따라, 도 9 과 관련하여 설명된 기술들 중 어느 것의 특정 행위들 또는 이벤트들이 상이한 시퀀스에서 수행될 수도 있거나, 추가될 수도 있거나, 병합될 수도 있거나, 또는 전부 생략될 수도 있다 (예를 들어, 모든 설명된 행위들 또는 이벤트들이 그 기법들의 실시를 위해 필요한 것은 아니다) 는 것이 이해되야 한다.
여기에 설명된 특정 예들은 특정 관점 (예를 들어, "전송기 디바이스" 또는 "수신기 디바이스" 에 의해 수행됨) 에 관하여 기술되었지만, 본 개시의 기술들은 이러한 방식으로 제한되지 않는다는 것을 이해해야 한다. 예를 들어, 위에서 언급한 것처럼 VT는 종종 양방향 통신 흐름입니다. 따라서, 유사한 기술이 순방향 및 역방향 네트워크 경로들 양자 모두에, 예를 들어 "전송기 디바이스" 및 "수신기 디바이스" 양자 모두에 의해, 적용될 수도 있다. 또한, 예시를 위해 소정 관점과 관련하여 특정 디바이스가 도시되고 설명되었지만, 본 명세서에 기재된 디바이스는 도시된 것들보다 더 많거나 적은 컴포넌트를 가질 수도 있음을 이해해야 한다. 일 예로서, 전송기 디바이스는 비디오 인코더 (20) (도 2) 및 비디오 디코더 (42) (도 3) 양자 모두를 포함할 수도 있고, 거기에 설명된 각각의 기술을 수행할 수도 있다.
하나 이상의 예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수도 있다. 소프트웨어로 구현되면, 그 기능들은 컴퓨터 판독가능 매체 상에 하나 이상의 명령들 또는 코드로서 저장되거나 송신될 수도 있고 하드웨어 기반 처리 유닛에 의해 실행될 수도 있다. 컴퓨터 판독가능 매체는, 데이터 저장 매체와 같은 유형의 매체에 대응하는 컴퓨터 판독가능 저장 매체, 또는 예를 들면, 통신 프로토콜에 따라, 일 장소로부터 다른 장소로의 컴퓨터 프로그램의 전송을 가능하게 하는 임의의 매체를 포함하는 통신 매체를 포함할 수도 있다. 이런 방식으로, 컴퓨터 판독가능 매체는 일반적으로, (1) 비일시적인 유형의 컴퓨터 판독가능 저장 매체 또는 (2) 신호 또는 캐리어 파와 같은 통신 매체에 대응할 수도 있다. 데이터 저장 매체는, 본 개시에서 설명된 기법들의 구현을 위해 명령들, 코드 및/또는 데이터 구조들을 취출하기 위하여 하나 이상의 컴퓨터들 또는 하나 이상의 프로세서들에 의해 액세스될 수 있는 임의의 가용 매체일 수도 있다. 컴퓨터 프로그램 제품은 컴퓨터 판독가능 매체를 포함할 수도 있다.
비한정적 예로서, 그러한 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 저장, 자기 디스크 저장 또는 다른 자기 저장 디바이스들, 플래시 메모리, 또는 명령 또는 데이터 구조의 형태로 원하는 프로그램 코드를 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 접속이 컴퓨터 판독가능 매체로 적절히 칭해진다. 예를 들어, 명령들이 동축 케이블, 광섬유 케이블, 연선 (twisted pair), 디지털 가입자 라인 (DSL), 또는 적외선, 전파 (radio), 및 마이크로파와 같은 무선 기술을 사용하여 웹사이트, 서버, 또는 다른 원격 소스로부터 송신되면, 그 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 전파, 및 마이크로파와 같은 무선 기술은 매체의 정의 내에 포함된다. 하지만, 컴퓨터 판독가능 저장 매체 및 데이터 저장 매체는 접속, 캐리어 파, 신호 또는 다른 일시적 매체를 포함하는 것이 아니라, 대신에 비일시적, 유형의 저장 매체로 향하게 된다는 것이 이해되야 한다. 여기에 사용된, 디스크 (disk) 및 디스크 (disc) 는 CD (compact disc), 레이저 디스크 (laser disc), 광 디스크 (optical disc), DVD (digital versatile disc), 플로피 디스크 (floppy disk) 및 블루레이 디스크 (Blu-ray disc) 를 포함하며, 여기서, 디스크 (disk) 는 보통 데이터를 자기적으로 재생하지만, 디스크 (disc) 는 레이저를 이용하여 광학적으로 데이터를 재생한다. 또한, 상기의 조합은 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.
명령들은 하나 이상의 프로세서, 이를테면 하나 이상의 DSP (digital signal processor), 범용 마이크로프로세서, ASIC (application specific integrated circuit), FPGA (field programmable logic array), 또는 다른 등가 집적 또는 이산 로직 회로에 의해 실행될 수도 있다. 따라서, 본원에 사용된 용어 "프로세서" 는 전술한 구조 중 임의의 것 또는 본원에 설명된 기법들의 구현에 적합한 임의의 다른 구조를 지칭할 수도 있다. 추가로, 일부 양태들에서, 여기서 설명된 기능은 인코딩 및 디코딩을 위해 구성된 전용 하드웨어 및/또는 소프트웨어 유닛들 또는 모듈들 내에 제공되거나 또는 결합된 코덱에 포함될 수도 있다. 또한, 그 기법들은 하나 이상의 회로 또는 로직 엘리먼트들에서 완전히 구현될 수 있다.
본 개시의 기법들은 무선 핸드셋, 집적 회로 (IC) 또는 IC 들의 세트 (예를 들면, 칩 세트) 를 포함하여, 광범위하게 다양한 디바이스들 또는 장치들에서 구현될 수도 있다. 다양한 컴포넌트들, 모듈들 또는 유닛들이, 개시된 기술들을 수행하도록 구성된 디바이스들의 기능적인 양태들을 강조하기 위하여 본 개시에 설명되었지만, 상이한 하드웨어 유닛들에 의한 실현을 반드시 필요로 하는 것은 아니다. 오히려, 상술된 바처럼, 다양한 유닛들이 코덱 하드웨어 유닛에 결합될 수도 있거나, 또는 적합한 소프트웨어 및/또는 펌웨어와 함께, 상술된 하나 이상의 프로세서들을 포함하는 연동적인 (interoperative) 하드웨어 유닛들의 집합에 의해 제공될 수도 있다.
다양한 예들이 설명되었다. 이들 및 다른 예들은 다음의 청구항들의 범위 내에 있다.

Claims (29)

  1. 데이터를 처리하는 방법으로서,
    제 1 비트 레이트로 네트워크를 통해 데이터를 송신하는 단계;
    제 1 네트워크 링크 레이트로부터 제 2 네트워크 링크 레이트로 상기 네트워크의 네트워크 링크 레이트의 감소를 식별하는 단계;
    상기 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 상기 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트를 결정하는 단계로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하는 단계;
    상기 네트워크 링크 레이트의 감소를 식별하는 시간과 상기 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하는 단계; 및
    상기 복구 비트 레이트 및 상기 버퍼링 지속시간에 기초하여 상기 복구 비트 레이트로 상기 데이터를 송신할 복구 레이트 지속시간을 결정하는 단계
    를 포함하는, 데이터를 처리하는 방법.
  2. 제 1 항에 있어서,
    상기 복구 비트 레이트를 결정하는 단계는 상기 네트워크 링크 레이트의 감소의 크기에 기초한 언더슈트 팩터를 사용하여 상기 복구 비트 레이트를 결정하는 단계를 포함하는, 데이터를 처리하는 방법.
  3. 제 2 항에 있어서,
    상기 언더슈트 팩터를 상기 제 1 네트워크 링크 레이트와 상기 제 2 네트워크 링크 레이트 사이의 차이로 결정하고 상기 차이를 상기 제 1 네트워크 링크 레이트로 나누는 단계를 더 포함하는, 데이터를 처리하는 방법.
  4. 제 3 항에 있어서,
    상기 복구 비트 레이트를 결정하는 단계는, 상기 제 2 네트워크 링크 레이트에 1과 상기 언더슈트 팩터 사이의 차이를 곱한 것으로서 상기 복구 비트 레이트를 결정하는 단계를 포함하는, 데이터를 처리하는 방법.
  5. 제 2 항에 있어서,
    상기 언더슈트 레이트 및 상기 버퍼링 지속시간에 기초하여 상기 감소된 레이트 시간을 결정하는 단계는 다음 수식:
    ΔTu = ΔT (R0-R1) / (fU R1)
    에 기초하여 상기 복구 레이트 지속시간을 결정하는 단계를 포함하고,
    식중, ΔTu 는 복구 레이트 지속시간을 나타내고, ΔT는 버퍼링 지속시간을 나타내고, R0 은 제 1 네트워크 링크 레이트를 나타내고, R1 은 제 2 네트워크 링크 레이트를 나타내고, fU 는 네트워크 링크 레이트의 감소에 기초한 언더슈트 팩터를 나타내는, 데이터를 처리하는 방법.
  6. 제 1 항에 있어서,
    상기 복구 비트 레이트를 결정하는 단계는, 최소 비트 레이트보다 큰 복구 비트 레이트를 결정하는 단계를 포함하고, 상기 최소 비트 레이트는 상기 데이터를 인코딩하도록 구성된 인코더의 인코딩 비트 레이트에 기초하는, 데이터를 처리하는 방법.
  7. 제 1 항에 있어서,
    상기 복구 레이트 지속시간 동안 상기 데이터를 송신하면서 상기 제 2 네트워크 링크 레이트에서 제 3 네트워크 링크 레이트로 상기 네트워크 링크 레이트의 증가를 식별하는 단계; 및
    상기 네트워크 링크 레이트의 증가를 식별하는 것에 응답하여, 상기 복구 비트 레이트를, 상기 복구 비트 레이트보다 높은 비트 레이트로 증가시키는 단계를 더 포함하는, 데이터를 처리하는 방법.
  8. 제 1 항에 있어서,
    상기 버퍼링 지속시간을 결정하는 단계는 왕복 시간 (RTT) 데이터, 수신기 디바이스로부터 전송기 디바이스로의 다운링크 지연과 연관된 데이터, 레이트 제어 반응 지연과 연관된 데이터, 혼잡 제어의 반응 지연과 연관된 데이터, 또는 메시지 생성 지연과 연관된 데이터 중 적어도 하나에 기초하여 상기 버퍼링 지속시간을 결정하는 단계를 포함하는, 데이터를 처리하는 방법.
  9. 제 1 항에 있어서,
    상기 데이터가 송신되는 전송기 디바이스로부터 수신기 디바이스로의 순방향 채널에 대한 추정된 최대 비트 레이트를 나타내는 데이터를 수신하는 단계; 및
    수신 품질 피드백을 나타내는 데이터를 수신하는 단계를 더 포함하고;
    상기 버퍼링 지속시간을 결정하는 단계는 상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터에 기초하여 상기 버퍼링 지속시간을 결정하는 단계를 포함하는, 데이터를 처리하는 방법.
  10. 제 9 항에 있어서,
    상기 추정된 최대 비트 레이트를 나타내는 상기 데이터를 수신하는 단계는 TMMBR (Temporary Maximum Media Stream Bit Rate Request) 메시지를 수신하는 단계를 포함하고, 상기 수신 품질 피드백을 나타내는 상기 데이터를 수신하는 단계는 수신기 리포트 (Receiver Report) 메시지를 수신하는 단계를 포함하는, 데이터를 처리하는 방법.
  11. 제 9 항에 있어서,
    상기 추정된 최대 비트 레이트를 나타내는 상기 데이터를 수신하는 단계 및 상기 수신 품질 피드백을 나타내는 상기 데이터를 수신하는 단계는, 상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터를 포함하는 단일 메시지를 수신하는 단계를 포함하는, 데이터를 처리하는 방법.
  12. 제 9 항에 있어서,
    상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터에 기초하여 상기 버퍼링 지속시간을 결정하는 단계는, 제 1 메시지가 수신기 디바이스로 전송되는 시간과 상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터가 수신되는 시간 사이의 차이를 결정하는 단계를 포함하는, 데이터를 처리하는 방법.
  13. 제 1 항에 있어서,
    상기 데이터는 인코딩된 비디오 데이터를 포함하고,
    상기 방법은 상기 결정된 복구 레이트 지속시간 동안 상기 복구 비트 레이트로 상기 데이터를 송신하는 단계를 더 포함하며, 상기 결정된 복구 레이트 지속시간 동안 상기 복구 비트 레이트로 상기 데이터를 송신하는 단계는 상기 결정된 복구 레이트 지속시간 동안 상기 인코딩된 비디오 데이터의 상기 비트 레이트를 상기 복구 비트 레이트로 감소시키기 위한 레이트 제어를 수행하는 단계를 포함하는, 데이터를 처리하는 방법.
  14. 데이터를 처리하기 위한 디바이스로서,
    데이터를 저장하도록 구성된 메모리; 및
    하나 이상의 프로세서들을 포함하고,
    상기 하나 이상의 프로세서들은
    제 1 비트 레이트로 네트워크를 통해 상기 데이터를 송신하고;
    제 1 네트워크 링크 레이트로부터 제 2 네트워크 링크 레이트로 상기 네트워크의 네트워크 링크 레이트의 감소를 식별하고;
    상기 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 상기 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트를 결정하는 것으로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하고;
    상기 네트워크 링크 레이트의 감소를 식별하는 시간과 상기 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하고; 그리고
    상기 복구 비트 레이트 및 상기 버퍼링 지속시간에 기초하여 상기 복구 비트 레이트로 상기 데이터를 송신할 복구 레이트 지속시간을 결정하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  15. 제 14 항에 있어서,
    상기 복구 비트 레이트를 결정하기 위하여, 상기 하나 이상의 프로세서들은 상기 네트워크 링크 레이트의 감소의 크기에 기초한 언더슈트 팩터를 사용하여 상기 복구 비트 레이트를 결정하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  16. 제 15 항에 있어서,
    상기 하나 이상의 프로세서들은 또한, 상기 언더슈트 팩터를 상기 제 1 네트워크 링크 레이트와 상기 제 2 네트워크 링크 레이트 사이의 차이로 결정하고 상기 차이를 상기 제 1 네트워크 링크 레이트로 나누도록 구성되는, 데이터를 처리하기 위한 디바이스.
  17. 제 16 항에 있어서,
    상기 복구 비트 레이트를 결정하기 위하여, 상기 하나 이상의 프로세서들은, 상기 제 2 네트워크 링크 레이트에 1과 상기 언더슈트 팩터 사이의 차이를 곱한 것으로서 상기 복구 비트 레이트를 결정하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  18. 제 15 항에 있어서,
    상기 언더슈트 레이트 및 상기 버퍼링 지속시간에 기초하여 상기 감소된 레이트 시간을 결정하기 위하여, 상기 하나 이상의 프로세서들은 다음 수식:
    ΔTu = ΔT (R0-R1) / (fU R1)
    에 기초하여 상기 복구 레이트 지속시간을 결정하도록 구성되고,
    식중, ΔTu 는 복구 레이트 지속시간을 나타내고, ΔT는 버퍼링 지속시간을 나타내고, R0 은 제 1 네트워크 링크 레이트를 나타내고, R1 은 제 2 네트워크 링크 레이트를 나타내고, fU 는 네트워크 링크 레이트의 감소에 기초한 언더슈트 팩터를 나타내는, 데이터를 처리하기 위한 디바이스.
  19. 제 14 항에 있어서,
    상기 복구 비트 레이트를 결정하기 위하여, 상기 하나 이상의 프로세서들은 최소 비트 레이트보다 큰 복구 비트 레이트를 결정하도록 구성되고, 상기 최소 비트 레이트는 상기 데이터를 인코딩하도록 구성된 인코더의 인코딩 비트 레이트에 기초하는, 데이터를 처리하기 위한 디바이스.
  20. 제 14 항에 있어서,
    상기 하나 이상의 프로세서들은 또한
    상기 복구 레이트 지속시간 동안 상기 데이터를 송신하면서 상기 제 2 네트워크 링크 레이트에서 제 3 네트워크 링크 레이트로 상기 네트워크 링크 레이트의 증가를 식별하고; 그리고
    상기 네트워크 링크 레이트의 증가를 식별하는 것에 응답하여, 상기 복구 비트 레이트를, 상기 복구 비트 레이트보다 높은 비트 레이트로 증가시키도록 구성되는, 데이터를 처리하기 위한 디바이스.
  21. 제 14 항에 있어서,
    상기 버퍼링 지속시간을 결정하기 위하여, 상기 하나 이상의 프로세서들은, 왕복 시간 (RTT) 데이터, 수신기 디바이스로부터 전송기 디바이스로의 다운링크 지연과 연관된 데이터, 레이트 제어 반응 지연과 연관된 데이터, 혼잡 제어의 반응 지연과 연관된 데이터, 또는 메시지 생성 지연과 연관된 데이터 중 적어도 하나에 기초하여 상기 버퍼링 지속시간을 결정하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  22. 제 14 항에 있어서,
    상기 하나 이상의 프로세서들은 또한
    상기 데이터가 송신되는 전송기 디바이스로부터 수신기 디바이스로의 순방향 채널에 대한 추정된 최대 비트 레이트를 나타내는 데이터를 수신하고;
    수신 품질 피드백을 나타내는 데이터를 수신하도록 구성되고; 그리고
    상기 버퍼링 지속시간을 결정하기 위하여, 상기 하나 이상의 프로세서들은 상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터에 기초하여 상기 버퍼링 지속시간을 결정하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  23. 제 22 항에 있어서,
    상기 추정된 최대 비트 레이트를 나타내는 상기 데이터를 수신하기 위하여, 상기 하나 이상의 프로세서들은 TMMBR (Temporary Maximum Media Stream Bit Rate Request) 메시지를 수신하도록 구성되고, 상기 수신 품질 피드백을 나타내는 상기 데이터를 수신하기 위하여, 상기 하나 이상의 프로세서들은 수신기 리포트 (Receiver Report) 메시지를 수신하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  24. 제 22 항에 있어서,
    상기 추정된 최대 비트 레이트를 나타내는 상기 데이터를 수신하고 상기 수신 품질 피드백을 나타내는 상기 데이터를 수신하기 위하여, 상기 하나 이상의 프로세서들은 상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터를 포함하는 단일 메시지를 수신하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  25. 제 22 항에 있어서,
    상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터에 기초하여 상기 버퍼링 지속시간을 결정하기 위하여, 상기 하나 이상의 프로세서들은 제 1 메시지가 수신기 디바이스로 전송되는 시간과 상기 추정된 최대 비트 레이트를 나타내는 상기 데이터 및 상기 수신 품질 피드백을 나타내는 상기 데이터가 수신되는 시간 사이의 차이를 결정하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  26. 제 14 항에 있어서,
    상기 데이터는 인코딩된 비디오 데이터를 포함하고, 상기 하나 이상의 프로세서들은 또한 상기 결정된 복구 레이트 지속시간 동안 상기 복구 비트 레이트로 상기 데이터를 송신하도록 구성되며, 상기 결정된 복구 레이트 지속시간 동안 상기 복구 비트 레이트로 상기 데이터를 송신하기 위하여, 상기 하나 이상의 프로세서들은 상기 결정된 복구 레이트 지속시간 동안 상기 인코딩된 비디오 데이터의 상기 비트 레이트를 상기 복구 비트 레이트로 감소시키기 위한 레이트 제어를 수행하도록 구성되는, 데이터를 처리하기 위한 디바이스.
  27. 제 14 항에 있어서,
    상기 디바이스는
    집적 회로;
    마이크로프로세서; 또는
    무선 통신 디바이스
    중 적어도 하나를 포함하는, 데이터를 처리하기 위한 디바이스.
  28. 데이터를 처리하기 위한 장치로서,
    제 1 비트 레이트로 네트워크를 통해 데이터를 송신하는 수단;
    제 1 네트워크 링크 레이트로부터 제 2 네트워크 링크 레이트로 상기 네트워크의 네트워크 링크 레이트의 감소를 식별하는 수단;
    상기 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 상기 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트를 결정하는 수단으로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하는 수단;
    상기 네트워크 링크 레이트의 감소를 식별하는 시간과 상기 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하는 수단; 및
    상기 복구 비트 레이트 및 상기 버퍼링 지속시간에 기초하여 상기 복구 비트 레이트로 상기 데이터를 송신할 복구 레이트 지속시간을 결정하는 수단
    을 포함하는, 데이터를 처리하기 위한 장치.
  29. 저장된 명령들을 갖는 비일시적 컴퓨터 판독가능 매체로서,
    상기 명령들은, 실행될 때 하나 이상의 프로세서들로 하여금
    제 1 비트 레이트로 네트워크를 통해 데이터를 송신하게 하고;
    제 1 네트워크 링크 레이트로부터 제 2 네트워크 링크 레이트로 상기 네트워크의 네트워크 링크 레이트의 감소를 식별하게 하고;
    상기 네트워크 링크 레이트의 감소를 식별하는 것에 응답하여, 상기 네트워크를 통해 상기 데이터를 송신할 복구 비트 레이트를 결정하게 하는 것으로서, 상기 복구 비트 레이트는 상기 제 2 네트워크 링크 레이트보다 작은, 상기 복구 비트 레이트를 결정하게 하고;
    상기 네트워크 링크 레이트의 감소를 식별하는 시간과 상기 네트워크 링크 레이트의 감소의 추정된 실제 시간 사이의 차이에 기초하여 버퍼링 지속시간을 결정하게 하고; 그리고
    상기 복구 비트 레이트 및 상기 버퍼링 지속시간에 기초하여 상기 복구 비트 레이트로 상기 데이터를 송신할 복구 레이트 지속시간을 결정하게 하는, 비일시적 컴퓨터 판독가능 매체.
KR1020177002609A 2014-07-29 2015-07-29 화상 전화에서의 지연 감소 KR101727450B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462030513P 2014-07-29 2014-07-29
US62/030,513 2014-07-29
US14/811,491 US9426418B2 (en) 2014-07-29 2015-07-28 Reducing delay in video telephony
US14/811,491 2015-07-28
PCT/US2015/042654 WO2016019015A1 (en) 2014-07-29 2015-07-29 Reducing delay in video telephony

Publications (2)

Publication Number Publication Date
KR20170018458A true KR20170018458A (ko) 2017-02-17
KR101727450B1 KR101727450B1 (ko) 2017-04-14

Family

ID=55181425

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020177002611A KR102366630B1 (ko) 2014-07-29 2015-07-29 화상 전화에서의 수신기 구동 업 스위칭
KR1020177002609A KR101727450B1 (ko) 2014-07-29 2015-07-29 화상 전화에서의 지연 감소

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020177002611A KR102366630B1 (ko) 2014-07-29 2015-07-29 화상 전화에서의 수신기 구동 업 스위칭

Country Status (11)

Country Link
US (2) US9426418B2 (ko)
EP (2) EP3175583B1 (ko)
JP (3) JP6602842B2 (ko)
KR (2) KR102366630B1 (ko)
CN (2) CN106537855B (ko)
AU (1) AU2015296540B2 (ko)
BR (2) BR112017001510B1 (ko)
CA (1) CA2953711C (ko)
ES (2) ES2739527T3 (ko)
HU (2) HUE037155T2 (ko)
WO (2) WO2016019019A1 (ko)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
PT2942958T (pt) * 2013-01-07 2018-06-15 Nec Corp Sinalização de subdivisão de unidade de codificação para blocos codificados por pcm
US9426418B2 (en) 2014-07-29 2016-08-23 Qualcomm Incorporated Reducing delay in video telephony
US9510236B2 (en) 2015-02-02 2016-11-29 Accelerated Media Technologies, Inc. Systems and methods for electronic news gathering
CN106937073B (zh) * 2015-12-29 2019-10-15 展讯通信(上海)有限公司 基于VoLTE的视频通话码率调整方法、装置及移动终端
US10492085B2 (en) 2016-01-15 2019-11-26 Qualcomm Incorporated Real-time transport protocol congestion control techniques in video telephony
JP6724517B2 (ja) * 2016-04-14 2020-07-15 日本電気株式会社 ビットレート指示装置、ビットレート指示方法、及び、ビットレート指示プログラム
US10321849B2 (en) * 2016-10-13 2019-06-18 Etectrx, Inc. System for ingestion event monitoring and method for detecting ingestion events with high accuracy
CN112913273B (zh) * 2018-11-14 2023-03-31 中兴通讯股份有限公司 用于确定用于非陆地网络的通信参数的系统和方法
CN110351595B (zh) * 2019-07-17 2023-08-18 北京百度网讯科技有限公司 一种缓冲处理方法、装置、设备和计算机存储介质
CN110740284A (zh) * 2019-10-30 2020-01-31 中电福富信息科技有限公司 一种基于网络状况调节手机视频通话动态码率的方法
CN112565224B (zh) * 2020-11-26 2022-08-19 北京经纬恒润科技股份有限公司 一种视频处理方法及装置
US11936698B2 (en) * 2022-01-21 2024-03-19 Verizon Patent And Licensing Inc. Systems and methods for adaptive video conferencing
US20230396357A1 (en) * 2022-06-01 2023-12-07 Qualcomm Incorporated Indication of network condition at a remote ue

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090157865A1 (en) * 2007-12-13 2009-06-18 Dell Products, Lp System and method of managing network connections using a link policy

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5063562A (en) 1990-05-23 1991-11-05 International Business Machines Corporation Flow control for high speed networks
KR950005150B1 (ko) * 1992-03-23 1995-05-18 조명언 휴대용 tv 겸용 영상모니터장치
US6335922B1 (en) * 1997-02-11 2002-01-01 Qualcomm Incorporated Method and apparatus for forward link rate scheduling
US6450954B1 (en) 1999-11-01 2002-09-17 New England Medical Center Hospitals, Inc. Method of randomizing patients in a clinical trial
JP2004007361A (ja) * 2001-10-11 2004-01-08 Nippon Telegr & Teleph Corp <Ntt> データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置
US7379546B2 (en) * 2004-03-03 2008-05-27 King Fahd University Of Petroleum And Minerals Method for XZ-elliptic curve cryptography
EP1762052A1 (en) 2004-06-22 2007-03-14 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Network feedback method and device
CN101002192A (zh) * 2004-07-27 2007-07-18 索尼株式会社 具有传输差错恢复的家庭网络系统
US8977063B2 (en) 2005-03-09 2015-03-10 Qualcomm Incorporated Region-of-interest extraction for video telephony
US7701851B2 (en) 2005-07-20 2010-04-20 Vidyo, Inc. System and method for the control of the transmission rate in packet-based digital communications
GB2430124B (en) 2005-09-09 2008-01-09 Toshiba Res Europ Ltd Quantum communication system
US8111720B2 (en) 2007-01-09 2012-02-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus to indicate maximum scheduling delay for jitter buffer implementations
US7760642B2 (en) * 2007-03-12 2010-07-20 Citrix Systems, Inc. Systems and methods for providing quality of service precedence in TCP congestion control
US7957307B2 (en) * 2007-03-14 2011-06-07 Microsoft Corporation Reducing effects of packet loss in video transmissions
US20080239953A1 (en) * 2007-03-28 2008-10-02 Honeywell International, Inc. Method and apparatus for minimizing congestion in gateways
ES2478018T3 (es) 2007-12-20 2014-07-18 Ntt Docomo, Inc. Estación móvil, dispositivo de estación base, método de control de comunicación y sistema de comunicación móvil
US20090305715A1 (en) 2008-06-04 2009-12-10 Motorola, Inc. Channel quality reporting in a wireless communication system
US8325754B2 (en) 2008-10-16 2012-12-04 Soongsil University Research Consortium Techno-Park Method for transmitting network data
CN101582852B (zh) * 2009-06-10 2012-04-11 中兴通讯股份有限公司 一种网络拥塞管理的方法及系统
US8537699B2 (en) * 2009-06-16 2013-09-17 Qualcomm Incorporated Managing video adaptation algorithms
US8199665B2 (en) 2009-11-30 2012-06-12 Samsung Electronics Co., Ltd Apparatus and method for scheduling service based on network delay
US9276832B2 (en) * 2011-03-20 2016-03-01 King Abdullah University Of Science And Technology Buffer sizing for multi-hop networks
US9119111B2 (en) * 2011-08-12 2015-08-25 Alcatel Lucent Method and apparatus for controlling wireless uplink sessions
WO2013045878A1 (en) * 2011-09-30 2013-04-04 British Telecommunications Plc Attribution of congestion contributions
US10292066B2 (en) * 2011-11-04 2019-05-14 Cisco Technology, Inc. System and method of modifying congestion control based on mobile system information
US9197565B2 (en) * 2012-04-27 2015-11-24 Magor Communications Corp. Network congestion prediction
US20130332621A1 (en) * 2012-06-08 2013-12-12 Ecole Polytechnique Federale De Lausanne (Epfl) System and method for cooperative data streaming
EP2888842A4 (en) * 2012-08-21 2016-03-09 Hewlett Packard Development Co NOTIFICATION OF CONGESTION IN A NETWORK
US9247448B2 (en) * 2012-08-27 2016-01-26 Qualcomm Incorporated Device and method for adaptive rate multimedia communications on a wireless network
EP2903355B1 (en) * 2012-09-26 2020-01-22 LG Electronics Inc. Method and apparatus for controlling transmission power of uplink control channel
TWI474740B (zh) 2012-12-04 2015-02-21 Univ Nat Taiwan Science Tech 資料叢發排程方法
CN105075202B (zh) 2013-03-28 2019-07-12 英国电讯有限公司 用于在分组网络中处理分组的方法、节点和分组网络
KR101767913B1 (ko) * 2013-03-29 2017-08-14 브이아이디 스케일, 인크. 조기 패킷 손실 검출 및 피드백
US20140376376A1 (en) 2013-06-20 2014-12-25 Alcatel-Lucent Usa Inc. Method And Apparatus For Improved Multicast Rate Control
US9124520B2 (en) * 2013-08-27 2015-09-01 Cisco Technology, Inc. Reducing buffer bloat while probing for additional bandwidth in an adaptive bitrate network
US20150271225A1 (en) * 2014-03-18 2015-09-24 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US9426418B2 (en) 2014-07-29 2016-08-23 Qualcomm Incorporated Reducing delay in video telephony

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090157865A1 (en) * 2007-12-13 2009-06-18 Dell Products, Lp System and method of managing network connections using a link policy

Also Published As

Publication number Publication date
KR101727450B1 (ko) 2017-04-14
CN106576081B (zh) 2019-08-06
EP3175584B1 (en) 2018-03-14
WO2016019019A1 (en) 2016-02-04
KR102366630B1 (ko) 2022-02-22
ES2739527T3 (es) 2020-01-31
BR112017001510A2 (pt) 2017-11-21
US20160037125A1 (en) 2016-02-04
EP3175584A1 (en) 2017-06-07
AU2015296540B2 (en) 2019-09-12
CN106576081A (zh) 2017-04-19
US20160037128A1 (en) 2016-02-04
US9438853B2 (en) 2016-09-06
KR20170040216A (ko) 2017-04-12
CA2953711C (en) 2018-02-27
JP2017530584A (ja) 2017-10-12
BR112017001510B1 (pt) 2023-10-24
AU2015296540A1 (en) 2017-01-19
HUE037155T2 (hu) 2018-08-28
CN106537855A (zh) 2017-03-22
BR112017001040B1 (pt) 2023-11-14
EP3175583A1 (en) 2017-06-07
JP6602842B2 (ja) 2019-11-06
JP2018139407A (ja) 2018-09-06
US9426418B2 (en) 2016-08-23
CA2953711A1 (en) 2016-02-04
CN106537855B (zh) 2018-05-25
BR112017001040A2 (pt) 2017-11-14
EP3175583B1 (en) 2019-05-01
JP6420006B2 (ja) 2018-11-07
ES2673701T3 (es) 2018-06-25
WO2016019015A1 (en) 2016-02-04
HUE043634T2 (hu) 2019-08-28
JP2017531345A (ja) 2017-10-19

Similar Documents

Publication Publication Date Title
KR101727450B1 (ko) 화상 전화에서의 지연 감소
EP3335341B1 (en) Sender side video telephony downgrade method
US8489758B2 (en) Method of transmitting data in a communication system
WO2008094092A9 (en) Method and arrangement for video telephony quality assessment
JP2008517560A (ja) 端末間のボイスオーバインターネットプロトコルのメディアの待ち時間を管理する方法および装置
US10492085B2 (en) Real-time transport protocol congestion control techniques in video telephony
JP2005322995A (ja) リアルタイム映像転送におけるバッファ制御方法、送信端末、受信端末、映像配信システム、およびプログラム
KR101055169B1 (ko) 스트리밍 시스템의 트래픽 제어 방법 및 그 장치
KR101094694B1 (ko) 스트리밍 시스템에서 초기 버퍼링 시간을 최소화하는 방법 및 그 장치

Legal Events

Date Code Title Description
A201 Request for examination
A302 Request for accelerated examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant