BR112017001510B1 - Método e dispositivo receptor para processamento de dados de vídeo, e memória legível por computador - Google Patents

Método e dispositivo receptor para processamento de dados de vídeo, e memória legível por computador Download PDF

Info

Publication number
BR112017001510B1
BR112017001510B1 BR112017001510-2A BR112017001510A BR112017001510B1 BR 112017001510 B1 BR112017001510 B1 BR 112017001510B1 BR 112017001510 A BR112017001510 A BR 112017001510A BR 112017001510 B1 BR112017001510 B1 BR 112017001510B1
Authority
BR
Brazil
Prior art keywords
rate
data
time
video
receiving device
Prior art date
Application number
BR112017001510-2A
Other languages
English (en)
Other versions
BR112017001510A2 (pt
Inventor
Geert Van der Auwera
Muhammed Zeyd Coban
Marta Karczewicz
Nikolai Konrad Leung
Original Assignee
Qualcomm Incorporated
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 Qualcomm Incorporated filed Critical Qualcomm Incorporated
Publication of BR112017001510A2 publication Critical patent/BR112017001510A2/pt
Publication of BR112017001510B1 publication Critical patent/BR112017001510B1/pt

Links

Classifications

    • 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
    • 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/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

em um exemplo, um método de processamento de dados inclui a determinação, por um dispositivo receptor, de um parâmetro de excesso de atraso permitido com base na diferença entre um tempo no qual os dados recebidos são recebidos pelo dispositivo receptor e um tempo no qual os dados recebidos são programados para serem reproduzidos, onde o parâmetro de excesso de atraso permitido indica uma quantidade de atraso que é suportável por um canal entre um dispositivo remetente e o dispositivo receptor. o método também inclui a determinação, pelo dispositivo receptor, de um aumento de taxa de bits remetente para aumentar uma taxa de bits na qual os dados devem ser enviados a partir do dispositivo remetente para o dispositivo receptor com base no parâmetro de excesso de atraso permitido determinado, e transmitir uma indicação do aumento de taxa de bits remetente para o dispositivo remetente.

Description

[0001] Este pedido reivindica o benefício do Pedido Provisório U.S. No. 62/030.513, depositado em 29 de julho de 2014, todo o conteúdo do qual é aqui incorporado por referência.
CAMPO TÉCNICO
[0002] Esta divulgação refere-se ao processamento de dados de vídeo.
FUNDAMENTOS
[0003] Vídeo telefonia (VT) envolve a comunicação em tempo real de pacotes que portam dados de áudio e vídeo. Um dispositivo de VT inclui um codificador de vídeo que obtém vídeo a partir de um dispositivo de captura de vídeo, tal como uma câmara de vídeo ou arquivo de vídeo, e gera pacotes de vídeo. De modo semelhante, um codificador de áudio em um dispositivo de VT obtém áudio a partir de um dispositivo de captura de áudio, tal como um microfone ou sintetizador de discurso, e gera pacotes de áudio. Os pacotes de vídeo e pacotes de áudio são colocados em uma fila de protocolo de radio link (RLP). Uma unidade de camada de controle de acesso ao meio (MAC) gera pacotes de camada de controle de acesso ao meio (MAC) a partir do conteúdo da fila de RLP. Os pacotes da camada MAC são convertidos em pacotes de camada física (PHY) para transmissão através de um canal de comunicação para outro dispositivo de VT.
[0004] Nas aplicações de VT móveis, um dispositivo de VT recebe os pacotes da camada física através de um link direto sem fio (FL) (ou "downlink") a partir de uma estação base para o dispositivo de VT como um terminal sem fio. Um dispositivo de VT transmite os pacotes de camada PHY através de um link inverso sem fio (RL) (ou "uplink") para uma estação base. Cada dispositivo de VT inclui camadas PHY e MAC para converter pacotes da camada PHY e MAC recebidos e remontar as cargas úteis de pacotes em pacotes de áudio e pacotes de vídeo. Um decodificador de vídeo dentro do dispositivo de VT decodifica os dados de vídeo para apresentação a um usuário através de um dispositivo de exibição. Um decodificador de áudio dentro do dispositivo de VT decodifica os dados de áudio para emissão através de um altofalante.
SUMÁRIO
[0005] As técnicas desta divulgação referem-se à determinação de uma taxa de bits para codificação de dados com base nas condições de rede. Por exemplo, os aspectos desta divulgação referem-se à redução de uma taxa de bits de envio (também simplesmente referida como taxa) a partir de uma primeira taxa para uma segunda taxa, em resposta a uma redução em uma taxa de link de rede. De acordo com aspectos desta divulgação, mediante a identificação da redução da taxa de link de rede, um dispositivo remetente pode reduzir a taxa de envio a uma taxa reduzida que é inferior à segunda taxa de link de rede, por exemplo, abaixo da segunda taxa de link de rede. O dispositivo remetente pode manter a taxa de envio a uma taxa reduzida por um período de tempo que é baseado na taxa reduzida e com base em um tempo entre a identificação da redução da taxa de link de rede e reagindo à redução da taxa de link de rede durante a qual os dados são armazenados no dispositivo remetente ou em outro dispositivo relacionado com a rede. Desta forma, o dispositivo remetente pode reduzir a quantidade de dados que foi armazenada durante um declínio na taxa de link de rede de forma relativamente rápida, sem demais impactar na experiência do usuário.
[0006] Aspectos da desta divulgação também se referem ao aumento de taxa de envio nos casos em que a taxa de link de rede não está sendo totalmente utilizada. Por exemplo, de acordo com aspectos da presente divulgação, um dispositivo receptor pode determinar que uma taxa de link de rede é subutilizada com base em dados a serem recebidos no dispositivo receptor antes do tempo no qual os dados são programados para serem reproduzidos. O dispositivo receptor pode determinar um parâmetro de atraso em excesso permitido com base em uma diferença de tempo entre um tempo no qual os dados são recebidos e um tempo no qual os dados são programados para serem reproduzidos. O dispositivo receptor pode determinar um aumento de taxa de envio de acordo com o parâmetro de atraso em excesso permitido. O dispositivo receptor pode, em alguns casos, transmitir uma indicação do aumento de taxa de envio para um dispositivo remetente, de modo que o dispositivo remetente pode melhor utilizara taxa de link de rede sem exceder a taxa de link de rede.
[0007] Em um exemplo, um método de processamento de dados inclui a transmissão de dados através de uma rede a uma primeira taxa de bit, identificar uma redução da taxa de link de rede da rede a partir de uma primeira taxa de link de rede para uma segunda taxa de link de rede, em resposta à identificação da redução da taxa de link de rede, determinar uma taxa de bits de recuperação na qual transmitir os dados através da rede, em que a taxa de bits de recuperação é menor que a segunda taxa de link de rede, determinar uma duração de armazenamento com base em uma diferença entre um tempo de identificação da redução da taxa de link de rede e um tempo real estimado da redução da taxa de link de rede, e determinar uma duração da taxa de recuperação durante a qual transmitir os dados à taxa de bits de recuperação com base na taxa de bits de recuperação e na duração de armazenamento.
[0008] Em um outro exemplo, um dispositivo para processamento de dados inclui uma memória configurada para armazenar dados, e um ou mais processadores, os um ou mais processadores configurados para transmitir os dados através de uma rede a uma primeira taxa de bit, identificar uma redução em uma taxa de link de rede da rede a partir de uma primeira taxa de link de rede para uma segunda taxa de link de rede, em resposta à identificação da redução da taxa de link de rede, determinar uma taxa de bits de recuperação na qual transmitir os dados através da rede, em que a taxa de bit de recuperação é menor que a segunda taxa de link de rede, determinar um tempo de armazenamento com base em uma diferença entre um tempo de identificação da redução da taxa de link de rede e um tempo real estimado da redução da taxa de link de rede, e determinar um tempo durante o qual a taxa de recuperação para transmitir os dados à taxa de bits de recuperação com base na taxa de bits de recuperação e a duração de armazenamento.
[0009] Em um outro exemplo, um aparelho para processamento de dados inclui meios para transmitir dados através de uma rede a uma primeira taxa de bit, meios para identificar uma redução da taxa de link de rede da rede a partir de uma primeira taxa de link de rede para uma segunda taxa de link rede, meios para determinar, em resposta à identificação da redução da taxa de link de rede, uma taxa de bits de recuperação na qual transmitir os dados através da rede, em que a taxa de bits de recuperação é menor que a segunda taxa de link de rede, meios para determinar uma duração de armazenamento com base em uma diferença entre um tempo de identificação da redução da taxa de link de rede e um tempo real estimado da redução da taxa de link de rede, e meios para determinar uma taxa de recuperação de duração, durante a qual transmitir os dados à taxa de bits de recuperação com base na taxa de bits de recuperação e na duração de armazenamento.
[0010] Em um outro exemplo, um meio legível por computador não transitório tem instruções nele armazenadas para transmitir dados através de uma rede a uma primeira taxa de bit, identificar uma redução da taxa de link de rede da rede a partir de uma primeira taxa de link de rede para uma segunda taxa de link de rede, determinar, em resposta à identificação da redução da taxa de link de rede, uma taxa de bits de recuperação na qual transmitir os dados através da rede, em que a taxa de bits de recuperação é menor que a segunda taxa de link de rede, determinar uma duração de armazenamento com base em uma diferença entre um tempo de identificação da redução da taxa de link de rede e um tempo real estimado da redução da taxa de link de rede, e determinar uma duração da taxa de recuperação durante a qual transmitir os dados no taxa de bit de recuperação baseada na taxa de bits de recuperação e a duração de armazenamento.
[0011] Em um outro exemplo, um método de processamento de dados inclui determinar, por um dispositivo receptor, um parâmetro de excesso de atraso permitido com base na diferença entre um tempo no qual os dados recebidos são recebidos pelo dispositivo receptor e um tempo no qual os dados recebidos são programados para serem reproduzidos, em que o parâmetro de excesso de atraso permitido indica uma quantidade de atraso que é suportável por um canal entre um dispositivo remetente e o dispositivo receptor, determinar, pelo dispositivo receptor, um aumento de taxa de bits remetente para aumentar uma taxa de bits na qual os dados devem ser enviados a partir do dispositivo remetente para o dispositivo receptor com base no parâmetro de excesso de atraso permitido determinado, e transmitir uma indicação de aumento da taxa de bits remetente para o dispositivo remetente.
[0012] Em um outro exemplo, um dispositivo receptor para processamento de dados inclui uma memória configurada para armazenar dados, e um ou mais processadores configurados para determinar um parâmetro de excesso de atraso permitido com base na diferença entre um tempo no qual os dados são recebidos pelo dispositivo receptor e um tempo no qual os dados são programados para serem reproduzidos, em que o parâmetro de excesso de atraso permitido indica uma quantidade de atraso que é suportável por um canal entre um dispositivo remetente e o dispositivo receptor que determinar um aumento da taxa de bits remetente para aumentar uma taxa de bits a qual os dados devem ser enviados a partir do dispositivo remetente para o dispositivo receptor com base no parâmetro de excesso de atraso permitido determinado, e transmitir uma indicação de aumento da taxa de bits remetente para o dispositivo remetente.
[0013] Em um outro exemplo, um aparelho para processamento de dados inclui meios para determinar um parâmetro de excesso de atraso permitido com base na diferença entre um tempo no qual os dados recebidos são recebidos pelo dispositivo receptor e um tempo no qual os dados recebidos são programados para serem reproduzidos, em que o parâmetro de excesso de atraso permitido indica uma quantidade de atraso que é suportável por um canal entre um dispositivo remetente e o dispositivo receptor, meios para determinar um aumento da taxa de bits remetente para aumentar uma taxa de bits na qual os dados devem ser enviados a partir do dispositivo remetente para o dispositivo receptor com base no parâmetro de excesso de atraso permitido determinado, e meios para transmitir uma indicação de aumento da taxa de bits remetente para o dispositivo remetente.
[0014] Em um outro exemplo, um meio legível por computador não transitório tem instruções armazenadas no mesmo que, quando executadas, fazem um ou mais processadores determinar um parâmetro de excesso de atraso permitido com base na diferença entre um tempo no qual os dados recebidos são recebidos pelo dispositivo receptor e um tempo no qual os dados recebidos são programados para serem reproduzidos, em que o parâmetro de excesso de atraso permitido indica uma quantidade de atraso que é suportável por um canal entre um dispositivo remetente e o dispositivo receptor, determinar um aumento de taxa de bits remetente para aumentar a uma taxa de bits na qual os dados devem ser enviados a partir do dispositivo remetente para o dispositivo receptor com base no parâmetro de excesso de atraso permitido determinado, e transmitir uma indicação de aumento da taxa de bits remetente para o dispositivo remetente.
[0015] Os detalhes de uma ou mais exemplos da invenção são estabelecidos nos desenhos acompanhantes e na descrição abaixo. Outras características, objetos e vantagens serão evidentes a partir da descrição, desenhos e reivindicações.
BREVE DESCRIÇÃO DOS DESENHOS
[0016] A figura 1 é um diagrama de blocos que ilustra um sistema de codificação e decodificação de áudio / vídeo para aplicações de vídeo telefonia (VT).
[0017] A figura 2 é um diagrama de blocos que ilustra um sistema de codificação de vídeo que pode implementar adaptação de taxa de fonte de vídeo de acordo com as técnicas desta divulgação.
[0018] A figura 3 é um diagrama de blocos que ilustra um sistema de decodificação de vídeo que pode implementar adaptação de taxa de fonte de vídeo de acordo com as técnicas desta divulgação.
[0019] As figuras 4A e 4B são gráficos que ilustram as técnicas de adaptação da taxa de fonte de vídeo consistentes com as técnicas desta divulgação.
[0020] A figura 5 é um diagrama conceitual ilustrando a determinação de uma duração de armazenamento consistente com as técnicas desta divulgação.
[0021] As figuras 6A e 6B são gráficos que ilustram um declínio da taxa de link de rede e um tempo de atraso correspondente, respectivamente.
[0022] As figuras 7A e 7B são gráficos que ilustram um declínio da taxa de link de rede e um tempo de atraso correspondente, respectivamente.
[0023] A figura 8 é um diagrama de fluxo que ilustra um processo exemplar para comutação descendente de uma taxa à qual os dados são transmitidos de acordo com as técnicas desta divulgação.
[0024] A figura 9 é um diagrama de fluxo que ilustra um processo exemplar para comutação ascendente de uma taxa à qual os dados são transmitidos de acordo com as técnicas desta divulgação.
DESCRIÇÃO DETALHADA
[0025] Dispositivos de vídeo telefonia (VT) podem ser conectados através de uma rede com fio ou sem fio para a realização de uma sessão de VT (por exemplo, a transmissão de dados de vídeo e/ou áudio entre os dispositivos de VT). Um dispositivo de VT que é o processamento de dados de áudio e/ou vídeo para transmissão de um outro dispositivo de VT pode ser referido como um dispositivo remetente. Da mesma forma, um dispositivo de VT que está processando dados recebidos de áudio e/ou vídeo (por exemplo, para a apresentação a um usuário do dispositivo de VT) pode ser referido como um dispositivo receptor.
[0026] O dispositivo remetente pode codificar os dados de áudio e/ou vídeo a uma taxa determinada (que pode ser indiferentemente aqui referida como uma taxa de bits). O dispositivo remetente pode selecionar a taxa com base nas condições de rede. Por exemplo, o dispositivo remetente pode selecionar a taxa baseada na taxa de link de rede máxima (máxima ou próxima) suportada pela rede a ser usada para a sessão de VT. Desta forma, o dispositivo remetente pode preparar os dados para serem enviados com qualidade relativamente mais alta suportada pela rede sem exceder os limites da rede.
[0027] Em alguns casos, a taxa de link de rede que conecta os dispositivos de VT pode variar, especialmente quando se utiliza VT através de uma rede sem fio, tais como redes celulares ou Wi-Fi. Em alguns casos, equipamentos de rede podem usar armazenadores para lidar com flutuações de taxas de link e/ou para executar o gerenciamento de filas. Por exemplo, um dispositivo remetente pode incluir um armazenador para armazenar dados de áudio e/ou vídeo codificados, antes de transmitir os dados para o dispositivo receptor. A redução repentina da taxa de link de rede pode causar um gargalo que pode afetar negativamente a sessão de VT. Por exemplo, quando a taxa de link de rede é reduzida, o dispositivo remetente para acumular dados de vídeo codificados no armazenador, o que pode causar interrupções e/ou movimentos bruscos na sessão de VT no dispositivo receptor.
[0028] Um dispositivo remetente pode alterar uma taxa na qual os dados de vídeo são enviados (que pode ser referida aqui como uma taxa de envio, a taxa sendo utilizada ao longo da descrição para se referir a uma taxa de bit), em resposta a uma redução na taxa de link de rede. Em alguns exemplos, o dispositivo remetente pode alterar a taxa de envio, alterando a taxa a qual os dados de áudio e/ou vídeo são codificados. No entanto, pode haver um atraso de reação na redução da taxa devido a atrasos de retorno de controle de congestionamento de dispositivo receptor, atrasos em um percurso de retorno de a partir de dispositivo receptor, ou semelhantes. Por conseguinte, a taxa de envio pode permanecer significativamente superior à taxa de link de rede por um período de tempo após uma redução na taxa de link de rede. Uma incompatibilidade na taxa de envio e na taxa de link de rede pode resultar em aumento dos níveis de armazenamento no link de gargalo e, consequentemente, aumento no atraso ponta a ponta (ou mesmo pacotes perdidos), que pode afetar negativamente a experiência de qualidade uma de sessão de VT.
[0029] Além disso, mesmo depois do dispositivo remetente diminuir a taxa de envio, em resposta a uma redução da taxa de link de rede, um atraso construído pode persistir durante algum tempo. Por exemplo, em geral, o atraso pode referir-se ao tempo entre os dados que estão disponíveis para a transmissão através de um link de rede e o tempo que os dados são realmente transmitidos para a rede. Consequentemente, o atraso pode ser associado com o armazenamento temporário de dados. Por exemplo, um aumento no atraso resulta em níveis aumentados de armazenador, porque os dados devem ser armazenados após a codificação e antes da transmissão para a rede.
[0038] Dependendo da diferença entre a taxa de envio e a taxa de link de rede de gargalo, o dispositivo remetente pode reduzir a quantidade de dados armazenados temporariamente de forma relativamente lenta. Isto é, se a diferença entre a taxa de envio reduzida e a taxa de link de rede é relativamente pequena, o dispositivo remetente pode reduzir o atraso construído de forma relativamente lenta e o impacto para a sessão de VT pode persistir.
[0031] Uma abordagem para reduzir a quantidade de dados armazenados temporariamente deve reduzir a taxa de envio abaixo de uma taxa de link de rede estimada. Uma abordagem relativamente conservadora, por exemplo, utilizando uma taxa de envio que é significativamente abaixo da taxa de link de rede estimada, pode resultar em uma subutilização do link e uma redução global da experiência de qualidade de vídeo no dispositivo receptor. No entanto, uma tal abordagem conservadora pode também reduzir os armazenadores de link de gargalo de forma relativamente rápida. Por outro lado, uma abordagem relativamente agressiva, por exemplo, apenas a redução da taxa de envio para a taxa de link de rede, pode resultar em pleno uso do link e dos dados codificados de maior qualidade. No entanto, como mencionado acima, uma abordagem deste tipo pode fazer com que os dados permaneçam em um armazenador por período de tempo um relativamente longo.
[0032] Aspectos desta divulgação referem-se à determinação de uma taxa de envio (por exemplo, uma taxa de bits para codificar os dados de áudio e/ou vídeo para um dispositivo remetente), com base nas condições de rede. Em particular, as técnicas incluem a redução da taxa de envio, em resposta a uma redução de uma taxa de link de rede. De acordo com aspectos desta divulgação, mediante a identificação de uma taxa reduzida de link de rede, um dispositivo remetente pode reduzir a taxa de envio a uma taxa que é inferior à taxa de acesso de rede. Em alguns exemplos, um dispositivo receptor pode solicitar uma taxa de envio reduzida, que é, em seguida, aplicada pelo dispositivo remetente. A redução da taxa de envio a uma taxa que é inferior à taxa de link de rede pode ser referida como não alcançando a taxa de link de rede.
[0033] As técnicas também incluem a determinação de uma quantidade de tempo para manter a taxa de envio a uma taxa reduzida. Em alguns exemplos, os aspectos da presente invenção incluem a determinação de uma duração da taxa de recuperação (também referida como um período não alcançado) com base em um tempo de armazenamento, uma magnitude da redução da taxa de link de rede, um fator de redução de taxa, e/ou outros fatores, como descrito em maior detalhe abaixo. Deste modo, as técnicas podem ser usadas para determinar um período não alcançado ideal. Por exemplo, um dispositivo remetente pode manter a taxa de envio reduzida apenas enquanto for necessário para reduzir uma quantidade de dados armazenada temporariamente antes de regressar a um aumento de taxa de envio que é suportada pela rede. As técnicas podem alcançar um equilíbrio entre a abordagem conservadora e a abordagem agressiva descrita acima, de modo que a quantidade de dados que é armazenada pode ser reduzida de forma relativamente rápida, sem demais impactar a experiência de usuário.
[0034] As técnicas desta divulgação incluem sinalizar dados de atraso associados com dados de áudio e/ou vídeo codificados. As técnicas desta divulgação incluem gerar dados para uso na determinação de uma duração de armazenamento em um dispositivo remetente. A duração de armazenamento pode ser associada com um atraso entre o declínio na taxa de link de rede real e o tempo no qual o declínio na taxa de link de rede é detectado (por, exemplo, assumindo qu o dispositivo remetente e/ou receptor não reconhece e reage a um declínio na taxa de link de rede imediatamente). Durante este lapso de tempo, um dispositivo remetente tipicamente armazena dados que são preparados/ codificados na taxa de envio original, mas que não podem ser enviados em tempo ral (ou quase em tempo real) na taxa de link de rede reduzida. O armazenamento de dados cria um atraso no dispositivo receptor durante o qual os dados não são recebidos. Como observado acima, o tempo de armazenamento temporário pode ser utilizado para determinar uma quantidade de dados que é armazenada no dispositivo remetente e/ou a duração da taxa de recuperação.
[0035] Outros aspectos da presente divulgação podem dizer respeito ao aumento de taxa de envio em casos em que a taxa de link de rede não está sendo totalmente utilizada. Por exemplo, um dispositivo remetente pode aumentar uma taxa de envio de dados para aumentar a qualidade dos casos de experiência de usuário em que a taxa de envio é menor do que a taxa de link que é suportável por uma rede que liga o dispositivo remetente a um dispositivo receptor. O aumento da taxa de bits na qual os dados são codificados pode ser aqui referido como acima de comutação. No entanto, comutação ascendente da taxa de envio em um incremento que é muito grande pode resultar em um não alcance da taxa de link de rede, o que pode degradar a experiência de usuário na forma descrita. Por outro lado, comutação ascendente da taxa de envio a um incremento que é muito pequeno pode resultar em um não alcance continuado da taxa de link de rede, que pode resultar em uma baixa qualidade de experiência de usuário do que é suportável peça taxa de link de rede.
[0036] De acordo com aspectos da presente divulgação, um dispositivo receptor pode determinar que uma taxa de link de rede é subutilizada com base em dados sendo recebidos antes do tempo no qual os dados são programados para serem reproduzidos. O dispositivo receptor pode determinar um parâmetro de excesso de atraso permitido com base na diferença entre um tempo no qual os dados são recebidos e o tempo no qual os dados são programados para serem reproduzidos, e o dispositivo receptor pode determinar um aumento de taxa de envio de acordo com o parâmetro de excesso de atraso permitido. O dispositivo receptor pode, em alguns casos, transmitir uma indicação do aumento de taxa de envio para um dispositivo remetente, de modo que o dispositivo remetente pode utilizar melhor a taxa de link de rede sem não alcançar a taxa de link de rede.
[0037] Em consequência, os aspectos desta divulgação incluem técnicas de adaptação de taxa ou controle de congestionamento para controlar um fluxo de vídeo proveniente de um dispositivo remetente e transmitido através de um canal de rede (também referido como um link de rede) com largura de banda variável em tempo para um dispositivo receptor. Em particular, as técnicas incluem comutação ascendente da taxa de bits média de um fluxo de vídeo de uma maneira controlada para melhorar a experiência de usuário sem introduzir congestionamento na rede. Tais técnicas de adaptação da taxa podem evitar aumentar significativamente o atraso ponta a ponta que pode resultar em perdas de pacotes.
[0038] Por exemplo, de acordo com aspectos da presente divulgação, um dispositivo receptor pode examinar os pacotes de vídeo recebidos e determinar se os dados estão chegando antes, em tempo, ou muito tarde para a reprodução programada dos dados. Se os dados estão chegando mais tarde do que a reprodução pretendida, o dispositivo receptor pode determinar que a taxa de link de rede é menor do que a taxa de envio (por exemplo, a taxa de codificação implementada no dispositivo remetente). Deste modo, o dispositivo receptor pode enviar uma solicitação ao dispositivo remetente para diminuir a taxa de envio. Em alguns exemplos, o dispositivo receptor pode requerer uma taxa inicial que é menor do que um taxa viável (por exemplo, uma largura de banda disponível) de uma taxa de link de rede para permitir que o sistema descongestione o canal de rede.
[0039] Em alguns casos, as técnicas aqui descritas podem ser realizadas por um dispositivo de Serviço de Telefonia Multimídia para Subsistema Multimídia IP (IMS) (MTSI). Por exemplo, o dispositivo MTSI pode realizar a adaptação de taxa de bits e/ou controle de congestionamento utilizando as técnicas descritas aqui.
[0040] A figura 1 é um diagrama de blocos que ilustra um sistema de codificação e decodificação 10. Como mostrado na figura 1, o sistema 10 inclui um sistema codificador 12 e um sistema decodificador 14 conectado por um canal de transmissão 16. No exemplo da figura 1, sistema codificador 12 está associado com um primeiro dispositivo de comunicação de vídeo e inclui uma fonte de áudio 17, fonte de vídeo 18, codificador de vídeo 20, codificador de áudio 22, protocolo de transporte em tempo real (RTP) / protocolo de transporte em tempo real (RTCP) / protocolo de datagrama de usuário (UDP) / protocolo Internet (IP) / unidade de conversão de protocolo ponto-a-ponto (PPP) 26, fila de protocolo de rádio link (RLP) 28, unidade de camada MAC 30 e unidade de camada física (PHY) 32. O sistema decodificador 14 está associado a outro dispositivo de comunicação de vídeo e inclui uma unidade de camada PHY 34, unidade de camada MAC 36, fila RLP 38, unidade de conversão RTP / RTCP / UDP / IP / PPP 40, decodificador de vídeo 42, decodificador de áudio 44, dispositivo de saída de áudio 46, e dispositivo de saída de vídeo 48.
[0041] Tal como descrito em mais detalhe abaixo, o sistema codificador 12 e/ou sistema decodificador 14 pode utilizar as técnicas desta divulgação para modificar uma taxa de codificação com base nas condições de rede. Por exemplo, o codificador de vídeo 20 pode controlar a taxa de codificação de fonte de vídeo, pelo menos em parte, como uma função da largura de banda de rede. Em particular, o codificador de vídeo 20 pode reduzir uma taxa de codificação e/ou dados de vídeo de áudio, em resposta a uma redução de uma taxa de link de rede. Do mesmo modo, o codificador de vídeo 20 pode aumentar a uma taxa de codificação de vídeo e/ou dados de áudio em resposta a uma indicação de subutilização de uma taxa de link de rede.
[0042] O sistema 10 pode prover transmissão de áudio e vídeo bidirecional, por exemplo, para vídeo telefonia através do canal de transmissão 16. Por conseguinte, codificação, decodificação e unidades de conversão em geral recíprocas podem ser providas em lados opostos do canal 16. Em algumas modalidades, sistema codificador 12 e sistema decodificador 14 pode ser incorporado dentro de dispositivos de comunicação de vídeo, como terminais móveis sem fio equipados para streaming de vídeo, telefonia com vídeo, ou ambos. Os terminais móveis podem suportar VT de acordo com os padrões de comutação de pacotes, tais como RTF, RTCP, UDP, IP, ou PPP.
[0043] Por exemplo, no sistema codificador 12, unidade de conversão RTP / RTCP / UDP / IP / PPP 26 acrescenta dados do cabeçalho RTP / RTCP / UDP / IP / PPP adequados para dados de áudio e vídeo recebidos do codificador de vídeo 20 e codificador de áudio 22 e coloca os dados em fila de RLP 28. Um exemplo de fluxo de bits pode incluir um cabeçalho MAC, um cabeçalho IP, um cabeçalho UDP, um cabeçalho RTCP, e dados de carga útil. Em alguns exemplos, RTP / RTCP executa sobre UDP, enquanto que o UDP é executado sobre IP e IP executa sobre PPP. Em alguns exemplos, como descrito aqui, unidade de conversão RTP / RTCP / UDP / IP / PPP de acordo com um padrão particular, tal como "RFC 3550: RTP: A transport Protocol for real-Time Applications", H. Schulzrinne et al., July 2003, "RFC 5104: Codec Control Messages in the RTP AudioVisual Provide with Retorno (AVPF)", S. Wenger et al., February 2008 (doravante RFC 5104), e/ou outros padrões aplicáveis para transporte em tempo real ou quase real de dados. Unidade de camada MAC 30 gera pacotes MAC RLP a partir dos conteúdos de fila RLP 28. Unidade de camada PHY 32 converte a pacotes MAC RLP em pacotes de camada PHY para transmissão através do canal 16.
[0044] Unidade de camada PHY 34 e unidade de camada MAC 36 de sistema decodificador 14 operam de forma recíproca. A unidade da camada PHY 34 converte os pacotes da camada PHY recebidos do canal 16 em pacotes MAC RLP. A unidade de camada MAC 36 coloca os pacotes MAC RLP na fila RLP 38. A unidade de conversão RTP / RTCP / UDP / IP / PPP 40 tira as informações de cabeçalho a partir dos dados na fila RLP 38, e remonta os dados de vídeo e áudio para entrega no decodificador de vídeo 42 e decodificador de áudio 44, respectivamente.
[0045] O sistema 10 pode ser projeto para suportar uma ou mais tecnologias de comunicação sem fio, tais como Acesso Múltiplo por Divisão de Código (CDMA), Acesso Múltiplo por Divisão de Frequência (FDMA), Acesso Múltiplo por Divisão de tempo (TDMA), ou Multiplexação por por Divisão de Frequência Ortogonal (OFDM), ou outra técnica sem fio adequada. As tecnologias de comunicação sem fio listadas acima podem ser entregues de acordo com qualquer um de uma variedade de tecnologias de acesso rádio. Por exemplo, CDMA pode ser entregue de acordo com os padrões ou CDMA2000 (WCDMA) de banda larga CDMA. TDMA pode ser entregue de acordo com o padrão de Sistema Global para Comunicações Móveis (GSM). O padrão do Sistema Universal para Telecomunicações Móveis (UMTS) permite operação GSM ou WCDMA. Tipicamente, para aplicações de VT, o sistema 10 pode ser projetado para suportar tecnologias de alta taxa de dados (HDR).
[0046] O codificador de vídeo 20 gera dados de vídeo codificados de acordo com um método de compressão de vídeo, como MPEG-4, Codificação de Vídeo de Alta Eficiência (HEVC), ou outro padrão de codificação de vídeo. Outros métodos de compressão de vídeo incluem a União Internacional das Telecomunicações (UIT), métodos H.263, H.264 ITU, ou MPEG-2. O codificador de áudio 22 codifica os dados de áudio para acompanhar os dados de vídeo. A fonte de vídeo 18 pode ser um dispositivo de captura de vídeo, tal como uma ou mais câmeras de vídeo, um ou mais arquivos de vídeo, ou uma combinação de câmeras de vídeo e arquivos de vídeo.
[0047] Os dados de áudio podem ser codificados de acordo com um método de compressão de áudio, tais como banda estreita multitaxa adaptativa (AMR-NB), ou outras técnicas. A fonte de áudio 17 pode ser um dispositivo de captura de áudio, tais como um microfone, ou um sintetizador de voz. Para aplicações de VT, o vídeo irá permitir a visualização de um terceiro a uma conferência de VT e o áudio irá permitir que a voz falando desse partido seja ouvida.
[0048] Em operação, unidade de conversão RTP / RTCP / UDP / IP / PPP 26 obtém pacotes de dados vídeo e de áudio do codificador de vídeo 20 e codificador de áudio 22. Como mencionado anteriormente, unidade de conversão RTP / RTCP / UDP / IP / PPP 26 adiciona informações de cabeçalho adequadas aos pacotes de áudio e insere os dados resultantes dentro da fila RLP 28. Da mesma forma, unidade de conversão RTP / RTCP / UDP / IP / PPP 26 adiciona informações de cabeçalho apropriadas aos pacotes de vídeo e insere os dados resultantes dentro da fila RLP 28. A unidade da camada MAC 30 recupera dados de fila RLP 28 e faz pacotes da camada MAC. Cada pacote de camada MAC transporta informações de cabeçalho de RTP / RTCP / UDP / IP / PPP e dados de pacote de áudio ou de vídeo que estão contidos dentro das filas 28. Pacotes de áudio RLP podem ser inseridos na fila RLP 28 independentemente dos pacotes de vídeo.
[0049] Em alguns casos, um pacote de camada MAC gerado a partir do conteúdo de fila RLP 28 irá transportar apenas informações de cabeçalho e de dados em pacotes de vídeo. Em outros casos, o pacote da camada MAC irá transportar apenas informações de cabeçalho e dados em pacotes de áudio. Em muitos casos, o pacote da camada MAC vai transportar informações de cabeçalho, dados de pacotes de áudio e dados de pacotes de vídeo, dependendo do conteúdo da fila de RLP 28. Pacotes da camada MAC podem ser configurados de acordo com um protocolo de rádio link (RLP), e podem ser referidos como pacotes MAC RLP. A unidade da camada PHY 32 converte os pacotes de áudio e vídeo MAC RLP em pacotes da camada PHY para a transmissão através do canal 16.
[0050] Canal 16 transporta os pacotes da camada PHY para o sistema 14. O decodificador de canal 16 pode ser qualquer conexão física entre o sistema codificador 12 e sistema decodificador 14. Por exemplo, o canal 16 pode ser uma conexão com fio, como uma rede com fio de área ampla ou local. Alternativamente, tal como aqui descrito, o canal 16 pode ser uma conexão sem fio tal como um celular, satélite ou ligação óptica. Condições de canal podem ser uma preocupação para os canais com e sem fio, mas podem ser particularmente pertinentes para aplicações de VT móveis realizadas através de um canal sem fio 16, em que as condições de canal podem sofrer devido a desvanecimento ou congestionamento. O canal 16 pode suportar uma taxa de link de rede particular (por exemplo, uma determinada largura de banda), que pode flutuar de acordo com as condições do canal. Por exemplo, o canal 16, pode ser caracterizado por um link reverso (RL) tendo uma capacidade de vazão que varia de acordo com as condições de canal.
[0051] Em geral, unidade de camada PHY 34 do sistema decodificador 14 identifica os pacotes da camada MAC a partir dos pacotes de camada PHY e remonta o conteúdo em pacotes MAC RLP. A unidade de camada MAC 36, em seguida, remonta os conteúdos dos pacotes MAC RLP para prover os pacotes de vídeo e de áudio para inserção dentro da fila RLP 38. A unidade RTP / RCTP / UDP / TP / PPP 40 remove a informação de cabeçalho acompanhante e provê pacotes de vídeo ao decodificador de vídeo 42 e pacotes de áudio ao decodificador de áudio 44. O decodificador de vídeo 42 decodifica os quadros de dados de vídeo para produzir um fluxo de dados de vídeo para utilização em condução de um dispositivo de exibição. O decodificador de áudio 44 decodifica os dados de áudio para produzir informações de áudio para a apresentação a um usuário, por exemplo, através de um altofalante.
[0052] Como mencionado acima, o sistema 10 pode prover a transmissão de vídeo e áudio bidirecional, por exemplo, para vídeo telefonia através do canal de transmissão 16. Em alguns exemplos, um problema pode ocorrer quando uma taxa de link de rede de canal 16 varia, o que pode ocorrer com Wi-Fi, celular, ou outros links de rede. Tal como descrito em maior detalhe com respeito à figura 2 abaixo, um ou mais armazenadores podem ser incluídos nos equipamentos de rede para lidar com as flutuações da taxa e, potencialmente, para executar o gerenciamento de filas.
[0053] Por exemplo, um fluxo de VT, com uma certa taxa de envio (por exemplo, uma taxa de codificação utilizada pelo codificador de vídeo 20) pode sofrer uma queda repentina na taxa de link, o que pode criar um gargalo para o escoamento. Devido a um atraso de reação no sistema codificador 12 para essa queda da taxa de link (por exemplo, o que pode ser causado por atrasos de retorno de controle de congestionamento de receptor, atrasos no percurso de retorno do receptor para o remetente, atrasos de reação de adaptação de taxa, ou semelhantes) a taxa de envio pode ficar significativamente superior à taxa de link durante um período de tempo. Isso pode resultar em aumento dos níveis de armazenador temporário no link do gargalo e, consequentemente, aumento do atraso ponta a ponta (ou até mesmo pacotes perdidos) entre o sistema codificador 12 e sistema decodificador 14, o que pode afetar negativamente a experiência de qualidade da sessão de VT.
[0054] Depois que o sistema codificador 12 diminui a taxa de bits na qual os dados são transmitidos através do canal 16 (por exemplo, diminui a taxa de envio), o atraso construído pode persistir por algum tempo. Por exemplo, em alguns casos, o período de tempo que o atraso construído persistir pode depender da diferença entre a taxa de envio e a taxa de link reduzida (por exemplo, a taxa de link causando o gargalo). Se a diminuição da taxa de envio é muito pequena, o atraso construído irá diminuir de forma relativamente lenta, o que pode ter impacto na experiência do usuário no sistema decodificador 14. Uma abordagem conservadora de taxa de envio é consistentemente enviar a uma taxa significativamente mais baixa do que a taxa de link estimada. No entanto, esta abordagem pode resultar em subutilização do link no canal 16 e uma experiência de qualidade de vídeo em geral reduzida.
[0055] De acordo com as técnicas descritas nesta divulgação, o codificador vídeo 20 pode codificar vídeo a partir da fonte de vídeo 18, com base nas condições de canal 16. Em particular, o codificador de vídeo 20 pode reduzir uma taxa de codificação (também referida aqui como uma taxa de envio), com base em uma redução na largura de banda no canal 16. A redução da taxa de codificação pode ser aqui referida como comutação descendente. O sistema codificador 12 pode reduzir temporariamente a taxa de envio de dados codificados pelo codificador de vídeo 20 depois de uma queda significativa na taxa de link no canal 16 ser detectada, por exemplo, depois de uma mensagem de retorno controle de congestionamento lado do receptor gerada pelo sistema decodificador 14 ter sido recebida pelo sistema codificador 12.
[0056] Em um exemplo, de acordo com aspectos da presente divulgação, o sistema codificador 12 pode, inicialmente, transmitir dados através do canal 16 a uma primeira taxa de bit. O sistema codificador 12 pode identificar uma redução na taxa de link de rede no canal 16 a partir de uma primeira taxa de link de rede a uma segunda taxa de link de rede. Em alguns exemplos, o sistema codificador 12 pode identificar a redução da taxa de link de rede com base em um ou mais relatórios recebidos do sistema decodificador 14.
[0057] De acordo com aspectos da presente divulgação, em resposta a identificar a redução da taxa de link de rede, o sistema codificador 12 pode determinar uma taxa de bits de recuperação na qual transmitir os dados através do canal 16, onde a taxa de bits de recuperação é menor do que a segunda taxa de link de rede. Sistema codificador 12 pode também determinar uma duração de armazenamento que inclui uma diferença entre um tempo de identificação da redução da taxa de link de rede e um tempo real estimado da redução da taxa de link de rede. Por exemplo, como notado acima, pode existir algum tempo de reação associado com a identificação do atraso e ajuste da taxa na qual o codificador de vídeo 20 codifica os dados. O sistema codificador 12 pode armazenar temporariamente dados codificados pelo codificador de vídeo 20 em ou próximo à taxa de link de rede inicial (mais elevada) até o codificador de vídeo 20 ter tempo de identificar e ajustar a taxa de codificação para a taxa mais baixa.
[0058] O sistema codificador 12 pode determinar uma duração de taxa de recuperação durante a qual transmitir os dados na taxa de bit de recuperação com base na taxa de bits de recuperação e na duração de armazenamento temporário. O sistema codificador pode, então, transmitir os dados à taxa de bit de recuperação para a duração da taxa de recuperação determinada. Deste modo, as técnicas podem reduzir o atraso construído de ponta a ponta de forma relativamente rápida e pode preservar a qualidade da experiência de usuário, utilizando a taxa de link disponível após o atraso ponta a ponta ser reduzido (por exemplo, versus manter a taxa de envio a uma taxa reduzida por um longo período de tempo). Embora descrito em relação ao sistema codificador 12 para fins de exemplo, deve ser entendido que certas técnicas acima mencionadas podem adicional ou alternativamente ser realizadas pelo sistema decodificador 14.
[0059] Ainda outras técnicas desta divulgação incluem técnicas para comutação ascendente (por exemplo, aumento) da taxa na qual dados são codificado com base nas condições de rede. Por exemplo, durante a apresentação de "Discussion on Upswitch Principals", SA4 MTS1 SWG Conference Call No. 4 on End-to-End Video Rate Adaptation E2EMTSI-S4, S4-AHM215, 24 de junho de 2014, ("AHM215") uma série de problemas com comutação ascendente foi identificada. Tal como documentado em "Report from SA4 MTSI SWG Conference Call No. 4 on End-to-end Video Rate Adaptation of E2EMTSI-S4 (24 de Junho de 2014), "Tdoc S4 (14)0768, uma discussão mais aprofundada foi sentida necessária para investigar as novas ideias da chamada de conferência antes de concordar sobre os princípios para a comutação ascendente.
[0060] De um modo geral, o modelo apresentado em AHM215 baseia-se em um modelo de sondagem de aceleração, que pode ter uma desvantagem em que a sondagem pode introduzir atraso no sistema quando a sonda não coincidir com as condições de canal. Um modelo mais robusto é permitir que um receptor, como o sistema decodificador 14, meça passivamente o estado do canal 16 para determinar se poderia haver excesso de capacidade no sistema. Com base nisso, sistema decodificador 14 pode fazer uma estimativa mais precisa da taxa sustentável do sistema.
[0061] O modelo apresentado em AHM215 também sugere uma abordagem em duas fases em que sistema codificador 12 primeiro sonda o canal para ver se pode haver mais capacidade. Se a fase de sondagem for bem sucedida, codificador de vídeo 20 pode aumentar mais agressivamente sua taxa durante uma "fase de aceleração". Um tal modelo pode introduzir uma quantidade relativamente grande de congestionamento no sistema, porque uma sonda bem sucedida com um pequeno aumento na taxa de dados pode não implicar que o sistema pode lidar com um aumento muito maior em seguida. Na verdade, quando se aumenta a taxa de codificador de vídeo 20 para coincidir com a capacidade do sistema, a abordagem mais robusta é primeiro aumentar a taxa em uma quantidade relativamente grande, seguida de tomar medidas menores conforme a taxa converge para a taxa sustentável suportada pelo canal 16.
[0062] Para acompanhar a abordagem potencialmente mais robusta de convergir para a taxa sustentável da maneira descrita acima, a entidade aciona a adaptação (por exemplo, o remetente (sistema codificador 12) ou receptor (sistema decodificador 14) deve ter uma estimativa da taxa sustentável do sistema. Um remetente pode contar com relatórios de receptor RTCP para detectar condições de canal ponta a ponta e pode calcular a capacidade de vazão líquida, embora com algum atraso de medição devido aos relatórios RTCP. Um receptor pode calcular tanto uma capacidade de vazão líquida quanto uma quantidade de atraso adicional que pode ser aceita antes dos pacotes chegarem muito tarde ao sistema decodificador 14 para sua reprodução programada. Portanto, se as métricas relevantes calculadas no receptor são enviadas diretamente para o remetente, um modelo de adaptação orientada para o receptor é conseguido e pode ser mais robusto e deve ser usado na determinação do desempenho de adaptação mínimo.
[0063] De acordo com aspectos desta divulgação, sistema decodificador 14 pode implementar uma técnica de comutação ascendente de taxa acionada pelo receptor após a determinação de que a largura de banda em canal 16 está sendo subutilizada. Por exemplo, de acordo com aspectos da presente divulgação, o sistema decodificador 14 pode prover dados para o sistema codificador 12 que avisa ao codificador de vídeo 20 para aumentar uma taxa de codificação.
[0064] Em alguns exemplos, de acordo com aspectos da presente divulgação, o sistema decodificador 14 pode determinar um parâmetro de excesso de atraso permitido com base na diferença entre um tempo no qual os dados são recebidos pelo sistema decodificador 14 e um tempo no qual os dados recebidos são programados para serem reproduzidos. O parâmetro de excesso de atraso permitido pode indicar uma quantidade de atraso que é suportável pelo canal 16 antes de uma experiência do usuário ser afetada, por exemplo, os dados chegam muito tarde para serem decodificados e reproduzidos no tempo apropriado. O sistema decodificador 14 também pode determinar um aumento da taxa de bits remetente para aumentar a taxa de bits em que os dados devem ser enviados a partir de sistema codificador 12 para o sistema decodificador 14 com base no parâmetro de excesso de atraso permitido determinado. O sistema decodificador 14 pode também transmitir uma indicação do aumento da taxa de bit remetente para sistema codificador 12.
[0065] Desta forma, o sistema decodificador 14 pode controlar a taxa de bits média do fluxo de vídeo de uma maneira controlada para melhorar a experiência de usuário sem introduzir o congestionamento da rede. As técnicas podem não aumentar significativamente o atraso ponta a ponta, o que poderia resultar em perdas de pacotes.
[0066] A figura 2 é um diagrama de blocos que ilustra sistema codificador 12 que pode implementar adaptação de taxa de fonte de vídeo de acordo com as técnicas desta divulgação. Como mostrado na figura 2, um codificador de vídeo 20 inclui uma máquina de codificação de vídeo 50, o armazenador de vídeo 52 e o controlador de taxa de vídeo 54. O codificador de vídeo 20 também recebe informação de taxa de link de rede 56, que pode ser preparada pelo sistema decodificador 14 (tal como descrito em maior detalhe abaixo).
[0067] A máquina de decodificação de vídeo 50 obtém dados de vídeo da fonte de vídeo 18 e codifica os dados de vídeo a um taxa controlada pelo controlador de taxa de vídeo 54. A máquina de codificação de vídeo 50 coloca então o vídeo codificado no armazenador de vídeo 52. O controlador de taxa de vídeo 54 pode monitorar a plenitude do armazenador de vídeo 52, e controlar a taxa de codificação de vídeo aplicada pela máquina de codificação de vídeo 50, pelo menos em parte, com base na plenitude. Além disso, tal como descrito em maior detalhe abaixo, controlador de taxa de vídeo 54 pode controlar a taxa baseada na informação de taxa de link de rede 56 e/ou outros dados associados com condições de canal 16 (figura 1) •
[0068] Em alguns exemplo, codificador de vídeo 20 pode prover uma esquema de controle de taxa de fonte de vídeo que é geralmente independente de CODEC. Por exemplo, codificador de vídeo 20 pode ser adaptado para codificação de vídeo de acordo com HEVC, MPEG4, ITU H.263 ou TTU H.264. Além disso, codificador de vídeo 20 pode ser adequado para implementçaao dentro de um DSP ou núcleo de lógica embutido. Em algumas modalidades, codificador de vídeo 20 (por exemplo, controlador de taxa de vídeo 54 do codificador de vídeo 20) pode aplicar controle de taxa baseado em modelo, por exemplo, aplicar controle de taxa de bloco de vídeo no domínio rho. Por exemplo, uma vez que um orçamento de bit de quadro é estabelecido para um quadro de vídeo particular, o orçamento de bit de quadro pode ser alocado entre os blocos de vídeo, por exemplo, unidades de codificação (CUs) e/ou macroblocos (MBs), dentro do quadro usando controle de taxa de domínio rho. Os valores de domínio rho para MBs individuais podem em seqguida ser mapeados para valores de parâmetro de quantização (QP).
[0069] De acordo com aspectos desta divulgação, o controlador de taxa de vídeo 54 pode executar comutação descendente de taxa com base nas condições de rede. Por exemplo, a máquina de codificação de vídeo 50 pode, inicialmente, codificar os dados a uma primeira taxa de bit para a transmissão através de um meio de transporte, tais como canal 16 (figura 1). O controlador de taxa de vídeo 54 pode identificar uma redução da taxa de link de rede a partir de uma primeira taxa de link de rede para uma segunda taxa de link de rede. Em alguns exemplos, o controlador de taxa de vídeo 54 pode identificar a redução da taxa de link de rede a partir do retorno no codificador de vídeo 20. Em outros exemplos, controlador de taxa de vídeo 54 pode identificar a redução da taxa de link de rede com base em informações de taxa de link de rede 56.
[0070] Em resposta à identificação da redução da taxa de link de rede, controlador de taxa de vídeo 54 pode determinar uma taxa de bits de recuperação para um codificador de vídeo 20, que é menor que a segunda taxa de link de rede (reduzida). A taxa de recuperação pode ser usada para reduzir a quantidade de dados que foi armazenada entre o tempo real da diminuição da taxa de link de rede e a identificação da diminuição na taxa de link de rede. Reduzir tais dados armazenados temporariamente pode ajudar a garantir que a experiência de usuário não seja afetada pelo dispositivo receptor. Assim, o controlador de taxa de vídeo 54 pode determinar uma taxa de bits de recuperação para uso no codificador de vídeo 20 que não alcança a taxa de link de rede reduzida, a fim de diminuir a quantidade de dados armazenada pelo codificador de vídeo 20.
[0071] De acordo com aspectos desta divulgação, o controlador de taxa de vídeo 54 pode determinar a taxa de recuperação com base em um fator não alcançado. O controlador de taxa de vídeo 54 pode determinar o fator não alcançado com base na diferença entre a primeira taxa de link de rede e a taxa de link de rede reduzida. Isto é, controlador de taxa de vídeo 54 pode determinar um fator não alcançado que tem uma magnitude que varia de acordo com a magnitude da redução na taxa de link de rede. Consequentemente, se a redução na taxa de link de rede é relativamente elevada, o controlador de taxa de vídeo 54 pode determinar um fator não alcançado que é relativamente elevado. Da mesma forma, se a redução da taxa de link de rede é relativamente baixa, o controlador de taxa de vídeo 54 pode determinar um fator não alcançado que é relativamente baixo.
[0072] Em alguns exemplos, o controlador de taxa de vídeo 54 pode determinar um fator não alcançado que pode ser aplicado com a taxa de link de rede reduzida para determinar a taxa de recuperação. Por exemplo, controlador de taxa de vídeo 54 pode determinar um fator não alcançado fracionado e pode aplicar o fator não alcançado fracionado na taxa de link de rede reduzida para determinar a taxa de recuperação. Em um exemplo, o controlador de taxa de vídeo 54 pode determinar o fator não alcançado com base em uma razão da magnitude na redução na taxa de link de rede para a primeira taxa de link de rede.
[0073] De acordo com aspectos desta divulgação, o controlador de taxa de vídeo 54 pode determinar quanto tempo manter a taxa de recuperação com base na quantidade de dados que é armazenada pelo codificador de vídeo 20 (ou, mais geralmente, a quantidade de dados que é armazenada em um dispositivo remetente que inclui um codificador de vídeo 20) entre o tempo da identificação da redução na taxa de link de rede e um tempo real estimado na redução da taxa de link de rede. O tempo associado com o armazenamento temporário de dados no dispositivo remetente pode ser aqui referido como o período de armazenamento (ou o período de tempo de armazenamento), enquanto que a duração com as quais manter a taxa de recuperação pode ser aqui referida como um duração da taxa de recuperação (ou período de tempo de taxa reduzido). Em alguns casos, a duração da taxa de recuperação pode também ser referida como uma duração não alcançada ou período, porque a taxa à qual os dados são codificados durante a duração da taxa de recuperação é menor do que a taxa de link de rede.
[0074] Tal como descrito em maior detalhe com relação à figura 5 a seguir, o controlador de taxa de vídeo 54 pode determinar a duração de armazenamento em uma variedade de maneiras. Por exemplo, controlador de taxa de vídeo 54 pode determinar a duração de armazenamento ao estimar a duração de armazenamento a partir da informação da taxa de link de rede 56, tal como o tempo de ida e volta (RTT) entre o dispositivo remetente que incorpora o codificador de vídeo 20 e um dispositivo receptor, atrasos de downlink (por exemplo, atrasos de receptor para remetente), dados relativos ao atraso de reação de adaptação de taxa, um atraso de reação do controle de congestionamento (por exemplo, a estimativa da taxa de link), atrasos de geração de mensagens (pacotes RTCP), ou semelhantes. A informação da taxa de link de rede 56 pode estar disponível no codificador de vídeo 20 ou pode ser sinalizada para codificador de vídeo 20 pelo dispositivo receptor.
[0075] De acordo com aspectos desta divulgação, o controlador de taxa de vídeo 54 pode determinar a duração da taxa de recuperação com base em uma magnitude da taxa de recuperação e com base na duração de armazenamento. Em alguns exemplos, o controlador de taxa de vídeo 54 pode determinar uma duração de armazenamento que é proporcional à magnitude da redução da taxa de link de rede (por exemplo, como indicado pela taxa de recuperação) e a quantidade de tempo associada com a reação para a redução da taxa de link de rede (por exemplo, tal como indicado pela duração de armazenamento). Isto é, se a redução da taxa de link de rede é relativamente grande e/ou o tempo necessário para reagir com a redução da taxa de link de rede é relativamente longo, o controlador de taxa de vídeo 54 pode determinar uma duração de taxa de recuperação que é proporcionalmente longa. Da mesma forma, se a redução na taxa de link de rede é relativamente pequena e/ou o tempo necessário para reagir à redução na taxa de link de rede é relativamente curto, o controlador de taxa de vídeo 54 pode determinar uma duração de taxa de recuperação que é proporcionalmente curta.
[0076] De acordo com outros aspectos da presente divulgação, controladores de taxa de vídeo 54 podem adicional ou alternativamente realizar comutação ascendente de taxa com base nas condições de rede. Por exemplo, o controlador de taxa de vídeo 54 pode receber informação de taxa de link de rede 56 a partir de um dispositivo receptor, tal como um dispositivo que inclui um sistema decodificador 14 (figura 1). Controlador de taxa de vídeo 54 pode utilizar a informação de taxa de link de rede recebida 56 para comutar ascendentemente a taxa de envio (por exemplo, taxa de codificação) que está sendo usada pela máquina de codificação de vídeo 50 para codificar os dados.
[0077] Em alguns exemplos, a informação de taxa de link de rede recebida 56 pode incluir uma taxa de envio solicitada particular (por exemplo, taxa de codificação) que está sendo implementada pela máquina de codificação de vídeo 50. Em outros exemplos, a informação de taxa de link de rede recebida 56 pode incluir um aumento de etapa de taxa a ser adicionada a uma taxa de envio atual (por exemplo, uma etapa de taxa de envio). Em ambos os casos, tal como descrito em maior detalhe em relação à figura 3 a seguir, a informação de taxa de link de rede recebida 56 pode basear-se em um parâmetro de excesso de atraso que indica que os pacotes foram recebidos no dispositivo receptor antes dos pacotes serem programados para serem reproduzidos. Em tais casos, o controlador de taxa de vídeo 54 pode aumentar a taxa de envio usada pela máquina de codificação de vídeo até o tempo de chagada de pacotes mais proximamente coincidir com o tempo de reprodução programada dos pacotes no dispositivo receptor.
[0078] Deve ser entendido que, enquanto as técnicas da figura 2 são descritas como sendo efetuadas por um componente particular da figura 2 (por exemplo, tal como controlador de taxa de vídeo 54), tais técnicas podem adicional ou alternativamente ser realizadas por um ou mais outros componentes de um dispositivo de vídeo telefonia. Como exemplo, um dispositivo MTSI pode realizar certas técnicas descritas acima para realizar adaptação de taxa e/ou controle de congestionamento. Neste exemplo, o dispositivo MTSI pode, então, prover dados para controlador de taxa de vídeo 54 para a implementação do controle de taxa adequada no codificador de vídeo.
[0079] A figura 3 é um diagrama de blocos ilustrando o sistema decodificador de vídeo 14 que pode implementar adaptação de taxa de fonte de vídeo, de acordo com as técnicas desta divulgação. Como mostrado na figura 3, decodificador de vídeo 42 recebe os dados codificados e a informação de taxa de link de rede 60 e inclui uma máquina de decodificação de vídeo 62, unidade de determinação de reprodução 64, e unidade de controle de taxa 66, que gera dados de controle de taxa 68.
[0080] Máquina de decodificação de vídeo 62 recebe dados codificados e informação de taxa de link de rede 60 e decodifica os dados de vídeo. Em alguns exemplos, máquina de decodificação de vídeo 62 pode estar em conformidade com uma ou mais normas de codificação de vídeo. Como observado acima, padrões de codificação de vídeo exemplares incluem HEVC, MPEG4, H.263 ITU ou ITU H.264.
[0081] A taxa à qual os dados de vídeo são recebidos pode ser controlada pelo controlador de taxa de vídeo 54 de um codificador de vídeo 20 (figura 2). De acordo com aspectos da presente divulgação, a unidade de controle de taxa 66 pode preparar e enviar dados de controle de taxa 68 para o codificador de vídeo 20, para utilização no ajuste da taxa de codificação. Em alguns exemplos, dados de controle de taxa 68 podem incluir dados para a realização de comutação descendente no dispositivo remetente. Em outros exemplos, adicional ou em alternativa, os dados de controle de taxa 68 podem incluir dados para executar comutação ascendente no dispositivo remetente. A unidade de controle de taxa 66 pode preparar os dados que permitem que o dispositivo remetente determine a taxa de bits apropriada, ou pode solicitar uma taxa de bits particular a partir do dispositivo remetente.
[0082] No que diz respeito à preparação de dados para comutação descendente, de acordo com aspectos da presente divulgação, a unidade de controle de taxa 66 pode determinar uma taxa de recuperação, uma duração de armazenamento, e/ou uma duração da taxa de recuperação de um modo semelhante ao descrito acima com respeito à figura 2. Em outros exemplos, a unidade de controle de taxa 66 pode gerar dados e/ou transmitir mensagens que podem ser utilizadas por um dispositivo remetente (tais como o sistema codificador 12) para determinar uma taxa de recuperação, uma duração de armazenamento, e/ou uma duração da taxa de recuperação.
[0083] Em um exemplo, a unidade de controle de taxa 66 pode gerar uma mensagem de solicitação de taxa de bits de Fluxo de Mídia Máxima Temporária RTCP (TMMBR) ao dispositivo remetente com uma taxa de bits máxima estimada para um canal direto para indicar uma redução na taxa de link de rede. De um modo geral, como descrito no RFC 5104 mencionado acima, um receptor, tradutor, ou misturador pode usar uma TMMBR (referido como "madeira") para solicitar um remetente a limitar a taxa de bits máxima para um fluxo de mídia, ou abaixo, do valor provido. A Notificação de Taxa de Bits de Fluxo de Mídia Máxima (TMMBN) contém a visualização atual do remetente de mídia do subconjunto mais limitante dos limites definidos por TMMBR que recebeu para ajudar os participantes a suprimir TMMBRs que não iriam restringir ainda mais o remetente de mídia.
[0084] De acordo com aspectos desta divulgação, uma mudança na taxa de bits máxima para o canal direto a partir de uma primeira para uma segunda taxa inferior indica uma redução da taxa de link de rede. Em alguns exemplos, a unidade de controle de taxa 66 pode enviar TMMBR imediatamente ou quase imediatamente após o congestionamento ser detectado (por exemplo, pode haver atrasos de geração de mensagem associada com a geração da mensagem de TMMBR). Enquanto uma mensagem de TMMBR é descrita para fins de ilustração, deve ser entendido que uma variedade de outras mensagens que indicam atrasos / congestionamento pode ser usada.
[0085] Para facilitar o dispositivo remetente com estimar a duração de armazenamento aqui descrita, a unidade de controle de taxa 66 também pode gerar e transmitir uma mensagem de relatório receptor de RTCP (RR). Por exemplo, tal como descrito em RFC 3550 mencionado acima, vários tipos de pacotes RTCP podem ser utilizados para transportar uma variedade de informação de controle. Um relatório remetente (SR) pode ser utilizado para as estatísticas de transmissão e recepção a partir dos participantes que são os remetentes ativos. Um RR pode ser utilizado para as estatísticas de recepção dos participantes que não são remetentes ativos e em combinação com SR para os remetentes ativos relatando sobre mais de 31 fontes.
[0086] De acordo com aspectos desta divulgação, a unidade de controle de taxa 66 pode gerar transmitir uma mensagem após a mensagem de TMMBR, por exemplo, imediatamente ou quase imediatamente após a mensagem de TMMBR. Neste exemplo, o dispositivo remetente pode receber a mensagem de TMMBR e a mensagem de RR e pode determinar uma ligação superior para a duração de armazenamento como uma diferença em tempo entre o tempo de envio de um SR que é referida no RR pela última marca de tempo de SR (dados LSR) incluídos no RR e o tempo que o RR é recebido pelo dispositivo remetente. Em outras palavras, a unidade de controle de taxa 66 pode enviar primeiros dados que indicam uma solicitação para uma limitação de taxa de bits (por exemplo, mensagem de TMMBR e segundos dados que indicam um tempo no qual uma mensagem foi gerada (por exemplo, os dados LSR). Os dados LSR podem incluir os 32 bits do meio de uma marca de tempo de protocolo de tempo de rede de 64 bits (NTP) recebida como parte do pacote SR RTCP mais recente proveniente de uma fonte. Se nenhum SR não tiver sido recebida ainda, no entanto, o campo de marca de tempo de LSR pode ser definido para zero. O dispositivo remetente pode receber os dados acima mencionados e pode utilizar os dados para determinar uma duração de armazenamento que pode ser usada durante a comutação descendente.
[0087] Em outro exemplo, em vez de enviar duas mensagens sucessivas separadas (por exemplo, uma TMMBR e um RR RTCP), a unidade de controle de taxa 66 pode agrupar os dados TMMBR e dados RR RTCP em uma única mensagem RTCP e pode enviar a única mensagem para o dispositivo remetente. No mínimo, a unidade de controle de taxa 66 pode enviar os dados de LSR, que permitem que o dispositivo remetente calcule a duração de armazenamento. Neste exemplo, o tamanho da mensagem pode ser reduzido em relação ao envio de duas mensagens separadas.
[0088] Em alguns exemplos, a unidade de controle de taxa 66 pode usar o LSR do último SR RTCP recebido para enviar para o dispositivo remetente, mesmo se a unidade de controle de taxa 66 tiver enviado anteriormente o RR RTCP que tem o mesmo LSR. Se a unidade de controle de taxa 66 ainda não tiver enviado um RR, a unidade de controle de taxa 66 pode combinar um RR completo com a TMMBR. Em outros exemplos, para reduzir o tamanho da mensagem, a unidade de controle de taxa 66 só pode enviar os dados de LSR juntamente com a TMMBR, que o dispositivo remetente pode receber e utilizar para determinar o TTR. Em ainda outro exemplo, se a unidade de controle de taxa 66 já enviou um RR, o dispositivo remetente pode calcular a duração de armazenamento com mais precisão como a diferença de tempo entre o tempo da recepção do último RR recebido e o tempo de recepção do novo RR (por exemplo, o RR que foi enviada pela unidade de controle de taxa 66 após o congestionamento ter sido detectado).
[0089] A unidade de controle de taxa 66 também pode determinar a duração da taxa de recuperação e/ou gerar e enviar dados para um dispositivo remetente para determinar a duração da taxa de recuperação. Por exemplo, em alternativa ou em combinação com as técnicas descritas acima, a unidade de controle de taxa 66 (ou o dispositivo remetente) pode monitorizar o jitter interchegada de RR RTCP para determinar quando se deve terminar a duração da taxa de recuperação. Em geral, os dados de jitter interchegada podem prover uma estimativa da variância estatística do tempo interchegada de pacote de dados RTP, medido em unidades de marca de tempo e expresso como um inteiro não sinalizado. O jitter interchegada J pode ser definido como sendo o desvio médio (valor absoluto suavizado) da diferença D em espaçamento entre pacotes no receptor em comparação com o remetente de um par de pacotes. Como mostrado na equação (1) abaixo, isto é equivalente à diferença entre o "tempo de trânsito relativo" para os dois pacotes; o tempo relativo de trânsito é a diferença entre uma marca de tempo RTP do pacote e o relógio do receptor no tempo da chegada, medida nas mesmas unidades. Se Si é a marca de tempo RTP a partir de pacotes i, e Ri é o tempo de chegada em unidades de marca de tempo RTP para pacote i, então, para dois pacotes i e j, D pode ser expresso como: D(i,j) = (Rj-Ri) – (Sj-Si) = (Rj-Sj) – (Ri-Si) (1)
[0090] De acordo com aspectos da presente divulgação, o dispositivo remetente pode encerrar a redução da taxa (por exemplo, o dispositivo remetente pode aumentar a taxa de envio a partir da taxa reduzida para aproximadamente a taxa de link de rede) se o jitter interchegada se torna zero ou menor do que um valor limite. O limite pode ser constante ou adaptativo às mudanças nas condições de rede. Em alguns exemplos, o dispositivo remetente pode encerrar a redução da taxa sobre enquanto o jitter interchegada é mantido a zero ou inferior a um valor limite durante um período mínimo de tempo. Em alguns casos, quanto mais frequentemente a unidade de controle de taxa 66 sinalizar o RR e SR RTCP, mais precisamente o dispositivo remetente pode monitorizar o jitter interchegada.
[0091] Em ainda outro exemplo, um dispositivo remetente (tais como o sistema codificador 12) pode controlar o atraso (por exemplo, RTT) e o remetente pode manter a taxa de envio à taxa reduzida até que o atraso seja suficientemente reduzido. Por exemplo, o dispositivo remetente pode manter a taxa de envio à taxa reduzida até que a quantidade de dados armazenada na memória intermediária esteja abaixo de um nível limite.
[0092] Em outras técnicas desta divulgação, a unidade de determinação de reprodução 64 pode examinar os pacotes de vídeo recebidos e determinar se os dados recebidos são chegando cedo, em tempo, ou muito tarde para a sua reprodução programada. O tempo de reprodução programada pode ser indicado com os dados codificados. Se os pacotes chegam tarde (por exemplo, o tempo de reprodução ocorre antes de os pacotes são recebidos / examinados), unidade de controle de taxa 66 pode solicitar ao dispositivo remetente para diminuir a taxa de bits a enviar. Em alguns exemplos, a unidade de controle de taxa 66 pode enviar uma mensagem de TMMBR com a taxa selecionada.
[0093] De acordo com alguns aspectos, a unidade de controle de taxa 66 pode estimar uma quantidade de dados logados de volta (por exemplo, dados armazenados temporariamente no dispositivo remetente) pela determinação da quantidade de excesso de atraso que necessita de ser removido e multiplicando este parâmetro de excesso de atraso pela taxa de dados de vídeo que chega tal como medida pela unidade de controle de taxa 66. Em outras palavras, a unidade de controle de taxa 66 pode determinar um atraso com base na diferença entre a data em que os dados são recebidos / examinados e o tempo de reprodução indicado com os dados. A unidade de controle de taxa 66 pode, em seguida, multiplicar esse tempo de atraso pela taxa de bits em que os dados estão sendo recebidos para determinar uma quantidade de dados sendo armazenada pelo remetente.
[0094] Em alguns exemplos, a unidade de controle de taxa 66 pode requerer uma taxa inicial (por exemplo, na mensagem de TMMBR) que é menor do que uma taxa sustentável do percurso de transporte entre o decodificador de vídeo 42 e o dispositivo remetente (por exemplo, uma largura de banda utilizável do link de rede) para permitir que o sistema descongestione o canal. Em um exemplo, a unidade de controle de taxa 66 pode selecionar uma taxa inicial que é suficientemente baixa para permitir que o sistema descongestione o canal em um valor fixo de tempo (indicado pela variável T_descongest). Se a variável R_sustain é igual à taxa sustentável do canal, e a variável ΔDelay é igual à quantidade de atraso que precisa de ser removido, então, a unidade de controle de taxa 66 pode, inicialmente, solicitar o dispositivo remetente a codificar os dados a uma taxa de bits R de acordo com a equação (2) a seguir: R = R_sustain (1 - ΔDelay)/T_decongest) (2) Depois de enviar a mensagem que inclui a taxa de bits solicitada (por exemplo, a mensagem de TMMBR), a unidade de controle de taxa 66 pode esperar o tempo de descongestionamento (T_decongest) passar. A unidade de controle de taxa 66 pode então enviar outra taxa de bit solicitada (por exemplo, uma mensagem de TMMBR adicional) à taxa que é sustentável pelo link de rede (R_sustain), terminando assim o período de descongestionamento.
[0095] Em um outro exemplo, a unidade de controle de taxa 66 pode não enviar outra mensagem (por exemplo, a mensagem de TMMBR adicional) para aumentar a taxa. Neste exemplo, a unidade de controle de taxa 66 pode simplesmente começar a medir uma quantidade permitida de atraso (por exemplo, um atraso que é inferior a um limite predeterminado). Se a unidade de controle de taxa 66 determina que o valor do atraso é menor do que o requerido (por exemplo, os pacotes chegam mais cedo do que o necessário para reprodução adequadamente programada), então, a unidade de controle de taxa 66 pode enviar uma outra mensagem (por exemplo, uma outra mensagem de TMMBR) para aumentar / subir da taxa de codificação do dispositivo remetente.
[0096] Com relação à comutação ascendente, quando um canal de comunicação entre um dispositivo remetente e um dispositivo receptor (tal como um canal 16 entre o sistema codificador 12 e sistema decodificador 14 (figura 1)) está sendo subutilizado pelo dispositivo remetente é provável que a entrega dos pacotes de vídeo ao decodificador de vídeo 42 irá ocorrer antes de tais pacotes de vídeo realmente precisarem de ser reproduzidos (por exemplo, recebidos antes de um tempo de reprodução indicado com os dados). Em tais casos, a taxa de remetente pode ser aumentada e algum atraso adicional pode ser introduzido no sistema sem afetar negativamente a experiência do usuário.
[0097] Os bits em excesso que podem ser introduzidos no percurso de transmissão podem ser calculados de acordo com a equação (3) abaixo, em casos em que a largura do canal é igual à taxa de recepção média medida na unidade de controle de taxa 66 (por exemplo, o pior caso sem reposição de largura de banda de canal disponível): excess_bits = rate_increase_step * (RTT + receiver_detection_delay) (3) onde excess_bits indica bits adicionais sendo introduzidos no sistema, rate_increase_step indica um aumento da taxa de codificação, RTT indica um tempo de ida e volta, e receiver_detection_delay indica um atraso associado com a detecção do atraso no sistema pelo receptor (que pode ser determinada de acordo com qualquer uma das técnicas aqui descritas).
[0098] Em alguns exemplos, a unidade de controle de taxa 66 pode determinar o pior caso correspondente de excesso de atraso (excess_delay) devido aos bits em excesso sendo introduzidos (excess_bits) de acordo com a equação (4) a seguir: excess_delay = rate_increase_step + (RTT + receiver_detection_delay) / avg_receiving_rate (4) onde o excess_delay indica uma quantidade de atraso introduzido no dispositivo remetente, rate_increase_step indica um aumento da taxa de codificação, RTT indica um tempo de ida e volta entre o dispositivo remetente e decodificador de vídeo 42, receiver_detection_delay indica um atraso associado com a detecção do atraso no sistema pela unidade de controle de taxa 66, e avg_receiving_rate indica a taxa na qual os dados são recebidos pelo decodificador de vídeo 42.
[0099] Assim, em alguns exemplos, de acordo com aspectos da presente divulgação, a unidade de controle de taxa 66 do decodificador de vídeo 42 pode determinar um número de bits excessivos associados com um aumento de taxa particular (por exemplo, excess_bits) e um atraso associado com a introdução dos bits em excesso (por exemplo, excess_delay).
[0100] A unidade de controle de taxa 66 pode calcular uma quantidade de aumento de taxa com base no parâmetro de excesso de atraso permitido. Por exemplo, a unidade de controle de taxa 66 pode determinar o quanto a taxa de envio pode ser aumentada pelo dispositivo remetente sem a introdução de congestionamento e/ou atraso no sistema de acordo com a equação (5) abaixo: rate_increase_step = allowable_excess_delay * avg_receivind_rate / (RTT + receiver_detection_delay) (5) onde rate_increase_step indica um valor pelo qual a taxa de envio pode ser aumentada (que pode ser referida como um aumento de taxa de bits de remetente) allowable_excess_delay indica um parâmetro de excesso de atraso permitido (como descrito em maior detalhe abaixo), avg_receiving_rate indica uma taxa média na qual os dados foram recebidos antes de se determinar o aumento da taxa, RTT indica um tempo de ida e volta entre o decodificador de vídeo 42 e um dispositivo remetente (tal como codificador de vídeo 20) e receiver_detection_delay indica uma quantidade de tempo necessária para identificar atraso no decodificador de vídeo 42. Em alguns casos, o parâmetro de atraso de detecção de receptor pode ser dependente da aplicação e pode ser medido ou estimado em testes off-line. Se um tal atraso de detecção de receptor não está disponível, a unidade de controle de taxa 66 pode ser configurada para utilizar um atraso de reação estimado, que pode ser uma estimativa relativamente conservadora do tempo necessário para a unidade de controle de taxa 66 identificar atraso.
[0101] Uma vez que a uma forma de atraso a partir do dispositivo remetente para o dispositivo receptor que inclui decodificador de vídeo 42 é geralmente desconhecida para o dispositivo receptor, o dispositivo receptor tipicamente pode não utilizar esta para calcular o parâmetro de excesso de atraso permitido (allowable_excess_delay). Em vez disso, de acordo com aspectos desta divulgação, a unidade de controle de taxa 66 pode determinar uma quantidade de excesso de retardo permitido a partir dos pacotes de vídeo recebidos. Por exemplo, a unidade de controle de taxa 66 pode determinar um tempo em que os pacotes de vídeo são recebidos e/ou processados no decodificador de vídeo 42. A unidade de controle de taxa 66 também pode determinar um tempo no qual os dados de vídeo associados com os pacotes de vídeo são designados para serem reproduzidos (por exemplo, apresentados a um usuário). A unidade de controle de taxa 66 pode determinar um parâmetro de retardo de excesso permitido com base em uma diferença entre o tempo no qual os pacotes são recebidos e/ou avaliados e o tempo de reprodução.
[0102] O parâmetro de excesso de atraso admissível pode geralmente indicar uma quantidade de tempo que pode ser utilizada pelo dispositivo remetente como uma base para aumentar a taxa de bits, sem afetar a experiência do usuário. Por exemplo, o parâmetro de excesso de atraso permitido pode indicar uma quantidade de tempo que pode ser utilizada para aumentar a taxa de envio, sem impactar experiência do usuário, por exemplo, sem aumentar a taxa de envio a uma taxa que não é suportável pelo canal 16, de modo que os dados chegam muito tarde no decodificador de vídeo 42 para serem decodificados e reproduzidos no tempo apropriado. A métrica de excesso de atraso admissível pode ser mais precisa do ponto de vista da experiência do usuário, uma vez que o parâmetro de excesso de atraso permitido indica diretamente se as informações de vídeo em pacotes recebidos podem realmente ser exibidas para o usuário sem degradação (por exemplo, como jitter, gagueira, ou quadro perdidos).
[0103] De acordo com aspectos desta divulgação, com base na análise acima, a unidade de controle de taxa 66 pode impor os seguintes requisitos em um dispositivo receptor e um dispositivo remetente para realizar comutação ascendente: • O receptor deve examinar a chegada de pacotes e comparar este com os seus tempos de reprodução programados regularmente para determinar se existe uma quantidade aceitável de atraso que pode ser introduzida no percurso de transmissão: allowable_excess_delay • O receptor deve examinar a chegada de pacotes para calcular a taxa de recepção média: avg_receiving_rate • O receptor deve calcular o tempo de ida e volta: RTT • O receptor deve calcular a rate_increase_step da seguinte forma: rate_increase_step = allowable_excess_delay * avg_receiving_rate / (RTT + receiver_detection_delay) • Quando permitido pelas regras de transmissão do Provedor Visual de Áudio com Retorno (AVPF) RTCP, o receptor: deve enviar uma solicitação taxa de bits de fluxo de mídia máximo temporário (TMMBR) quando ele detecta rate_increase_step > 5% x avg_receiving_rate, e deve enviar uma TMMBR quando detecta que o rate_increase_step > 15% x avg_receiving_rate • Ao enviar uma mensagem de TMMBR a requested_rate na TMMBR: deve ser igual a: avg_receiving_rate + rate_increase_step devem ser: avg_receiving_rate + 0.80 (rate_increase_step) <= requested_rate <= avg_receiving_rate + rate_increase_step
[0104] Além disso, de acordo com aspectos desta divulgação, os seguintes requisitos podem ser impostos no dispositivo remetente para realizar comutação ascendente: • Ao receber uma solicitação de taxa de bits de fluxo de mídia temporária máxima (TMMBR), o remetente de vídeo deve aumentar a sua taxa de envio para requested_rate dentro de 500ms e deve aumentá-la dentro de 1 segundo.
[0105] Deve ser entendido que os “requisitos” referidos acima são providos para fins de exemplo, e que as técnicas da presente divulgação pode também ser aplicadas usando valores diferentes dos valores específicos acima descritos. Além disso, enquanto as técnicas particulares são atribuídas às unidades particulares da figura 3 para fins de explicação (por exemplo, como unidade de controle de taxa 66), deve ser entendido que uma ou mais outras unidades de decodificador de vídeo 42 podem ser responsáveis pela realização de tais técnicas. Além disso, porque VT é frequentemente um fluxo de comunicação de duas vias, técnicas semelhantes podem ser aplicadas em ambos os percursos de rede direto e reverso, por exemplo, tanto por um dispositivo aqui designado como por um dispositivo remetente (tal como um dispositivo que incorpora um codificador de vídeo 20 de figura 2 e um dispositiv designado aqui como um dispositivo receptor (tal como um dispositivo que incorpora o decodificador de vídeo 42 da figura 3).
[0106] A figura 4A e figura 4B são gráficos que ilustram técnicas de adaptação de taxa de fonte de vídeo compatíveis com a presente divulgação. Por exemplo, a figura 4A ilustra geralmente uma taxa de bits de dados codificados em um dispositivo remetente (por exemplo, tal como o sistema codificador 12), durante um tempo que inclui uma diminuição na taxa de um link de rede. A figura 4B ilustra genericamente o atraso resultante que está associado com a diminuição da taxa de link de rede. As técnicas das figuras 4A e 4B são descritas com relação ao sistema codificador 12, deve ser entendido que as técnicas podem ser realizadas por uma variedade de outros dispositivos remetentes tendo uma variedade de outros componentes.
[0107] No exemplo da figura 4A, no instante de tempo t0, uma taxa de link (também referida como uma taxa de link de rede ou largura de banda) diminui de R0 para R1 tal como ilustrado pela linha 80, onde a taxa de envio = taxa de link). Em resposta ao declínio na taxa de link de rede, sistema codificador 12 pode reduzir a taxa de envio. No entanto, como mostrado no exemplo da figura 4A, existe um atraso de resposta (ΔT) de t0 para t1 associado com a redução da taxa de envio, tal como ilustrado pela linha tracejada 82. O atraso de resposta também pode ser aqui descrito como uma duração de armazenamento, durante este tempo a taxa de envio ultrapassa a taxa de link de rede e sistema codificador 12 é responsável por armazenar temporariamente os dados que não podem ser acomodados pelo link de rede.
[0108] Tal como ilustrado pela linha 84 no exemplo da figura 4B, o atraso (por exemplo, o tempo entre os dados codificados que estão disponíveis para a transmissão e o tempo que os dados codificados são transmitidos de fato) aumenta de forma relativamente rápida de DO para D1 durante o retardo de resposta (ΔT). Ou seja, atraso aumenta de forma relativamente rápida de D0 para D1 entre o tempo do declínio da taxa de link de rede t0 e o tempo da identificação do declínio na taxa de link de rede t1. A demora pode ser proporcional a uma quantidade de dados que é armazenada no sistema codificador 12.
[0109] No tempo t1, os exemplos da figura 4A e 4B ilustram técnicas de taxa de envio divergentes. Por exemplo, linha cheia 80 ilustra um primeiro exemplo em que o sistema codificador 12 mantém a taxa de envio à taxa de link de rede. Por exemplo, ao identificar a diminuição da taxa de link de rede, sistema codificador 12 reduz a taxa de envio da taxa original R0 para a nova taxa de link de rede reduzida R1. Neste exemplo, o atraso correspondente permanece relativamente elevado, tal como ilustrado pela linha cheia 88. Isto é, porque a taxa de envio está definida na taxa de link de rede de R1, não existe excesso de largura de banda com o qual reduzir a quantidade de dados que foi armazenada.
[0110] As linhas tracejadas 82 e 86 ilustram um segundo exemplo no qual o sistema codificador 12 reduz o envio da taxa inicial R0 para uma taxa reduzida Ru que é inferior à taxa de link de rede R1. Isto pode ser referido como "excedendo" a taxa de link de rede. Neste exemplo, o sistema codificador 12 pode manter a taxa reduzida Ru por uma duração de taxa de recuperação determinada (ΔTu). Durante este tempo, como ilustrado pela linha tracejada 90, o sistema codificador 12, reduz o atraso de D1 para D2 no tempo t2.
[0111] Como aqui descrito, o sistema codificador 12 pode determinar a taxa reduzida (RU), a duração de armazenamento (ΔT), e a duração da taxa de recuperação (ΔTu) utilizando uma variedade de técnicas. Em um exemplo, o sistema codificador 12 pode determinar a taxa reduzida Ru baseada na expressão (1-fU) x R1 onde fU é um fator não alcançado e R1 é a taxa de link reduzida, e com fU determinando o fator não alcançado de taxa (1-fU) e 0 < fU < 1, que refere-se à taxa de envio para a taxa de link R1. Em alguns exemplos, fU pode ser dependente da magnitude da queda de taxa de link de rede, que pode ser representada pela equação ΔR = (R0-R1). Neste exemplo, como mostrado na figura 4A, R0 é a primeira taxa de link de rede antes de ser reduzida. Se a magnitude do declínio da taxa de link de rede ΔR é grande, fU pode ser proporcionalmente grande. fU = ΔR / R0 (6)
[0112] Se o sistema codificador 12 armazena todos os bits durante a duração de armazenamento (AT) e contribui para um atraso, o sistema codificador 12 pode determinar a duração da taxa de recuperação (ΔTu) com base na equação (7) a seguir: ΔTu = ΔT (R0-R1) / (fU R1) (7) onde ΔTu é a duração da taxa de recuperação, ΔT compreende a duração de armazenamento, R0 compreende a primeira taxa de link de rede, R1 compreende a segunda taxa de link de rede reduzida e fU compreende o fator de redução de taxa.
[0113] Em alguns exemplos, o sistema codificador 12 pode aplicar um requisito mínimo de taxa de bits. O requisito mínimo de taxa de bits pode ser baseado na capacidade do codificador de vídeo 20, requisitos mínimos de sistema para a experiência do usuário, ou semelhante. Nos exemplos em que o sistema codificador 12 aplica um requisito mínimo de taxa de bits, o codificador de vídeo 20 pode aplicar o requisito mínimo de taxa de bits para Ru e, portanto, também para o fator não alcançado fU. Por exemplo, o sistema codificador 12 pode aplicar as equações (8) e (9) a seguir para determinar a taxa reduzida Ru e o fator não alcançado fU: RU >= Rmin (8) fU <= 1-(Rmin/R1) com R1>Rmin (9) onde RU é a taxa de bits reduzida, Rmin é uma taxa de codificação mínima, R1 representa a segunda taxa de link de rede reduzida, e fU é o fator não alcançado.
[0114] Se, durante a duração da taxa de recuperação (ΔTu) uma mensagem de TMMBR é recebida pelo sistema codificador 12 que carrega um novo valor de taxa R2, e R2 é significativamente maior do que R1 (por exemplo, R2 é maior do que ou igual a 1,2 multiplicado por R1), então o sistema codificador 12 pode encurtar a duração da taxa de recuperação. Por outro lado, se R2 for inferior a R1, então o sistema codificador 12 pode determinar uma duração da taxa de recuperação adicional ou prolongada.
[0115] Em geral, como referido acima em relação às figuras 2 e 3, sistema codificador 12 pode estimar a duração de armazenamento (ΔT) a partir da informação de rede tal como RTT, atrasos de downlink (por exemplo, receptor para remetente), confirmação sobre atraso de reação de controle de taxa, atraso de reação do controle de congestionamento (por exemplo, estimativa da taxa de link), atrasos de geração de mensagem (por exemplo, atraso associado com a geração de pacotes RTCP), ou outros semelhantes. Esta informação de rede pode estar disponível no lado do remetente ou pode ser sinalizada para o sistema codificador 12, por um dispositivo receptor, tal como um dispositivo que incorpora decodificador de vídeo 42 (figura 3).
[0116] Enquanto o exemplo das figuras 4A e 4B ilustram as alterações passo a passo (por exemplo, uma única variação da taxa de entre R0 e RU para fins de ilustração), deve ser entendido que as técnicas podem ser aplicadas de forma iterativa de tal modo que o perfil não alcançado é mais gradual.
[0117] A figura 5 é um diagrama conceitual ilustrando a determinação de uma duração de armazenamento consistente com as técnicas desta divulgação. No exemplo da figura 5, um dispositivo remetente (por exemplo, tal como o sistema codificador 12) pode enviar um relatório RTCP remetente (SR) para um dispositivo receptor (por exemplo, como sistema decodificador 14) no tempo 120. Por exemplo, conforme descrito em RFC 3550 como mencionado acima, vários tipos de pacotes RTCP podem ser utilizados para transportar uma variedade de informação de controle. Um relatório remetente (SR) pode ser utilizado para as estatísticas de transmissão e recepção dos participantes que são os remetentes ativos. Do mesmo modo, pode ser utilizado um receptor de relatório (RR) para estatísticas de recepção dos participantes que não são remetentes ativos e em combinação com SR para relatórios de remetentes ativos sobre mais de 31 fontes. O dispositivo receptor pode receber o SR RTCP no tempo 122.
[0118] O dispositivo receptor pode enviar uma mensagem RTCP TMMBR a um dispositivo remetente com a taxa de bits máxima estimada para o canal direto no tempo 124. Em alguns exemplos, embora possa haver atrasos associados com a geração de mensagens, o dispositivo receptor pode enviar uma mensagem de TMMBR imediatamente depois de detectar o congestionamento. Enquanto uma mensagem de TMMBR é descrita para fins de ilustração, uma variedade de outras mensagens que podem indicar atrasos / congestionamento pode ser utilizada.
[0119] Para facilitar o dispositivo remetente com estimar a duração de armazenamento (ΔT), o dispositivo receptor pode também enviar a mensagem de RR RTCP no tempo 124. De acordo com aspectos da presente divulgação, um dispositivo receptor pode enviar uma mensagem de RR imediatamente após a mensagem de TMMBR. Desta forma, o dispositivo remetente pode receber a mensagem de TMMBR e mensagem de RR no tempo 126 e pode calcular o limite superior pela duração de armazenamento (ΔT) 128 como a diferença de tempo entre o envio do SR que é referido no RR pela última marca de tempo de SR (dados de LSR) incluída no RR e o tempo que o RR é recebido. Em outras palavras, o dispositivo receptor pode enviar primeiros dados que indicam uma solicitação para uma limitação de taxa de dados (por exemplo, a mensagem TMMBR) e segundo dados que indicam um tempo no qual uma mensagem foi gerada (por exemplo, dados LSR). Os dados LSR podem incluir os 32 bits do meio de uma marca de tempo de protocolo de tempo de rede de 64 bits (NTP) recebido como parte do pacote SR RTCP mais recente de uma fonte. Se nenhum SR tiver sido recebido ainda, a marca de tempo de LSR pode ser definida para zero.
[0120] Em outro exemplo, em vez de enviar duas mensagens sucessivas separadas (por exemplo, TMMBR e RR RTCP) com os dados acima mencionados, os dados TMMBR e dados RR RTCP podem ser agrupados em uma única mensagem RTCP. No mínimo, o dispositivo receptor pode enviar os dados de LSR, que permitem que o dispositivo remetente calcule a duração de armazenamento (ΔT) 128. No presente exemplo, o tamanho da mensagem pode ser reduzido.
[0121] O dispositivo receptor pode usar o LSR da última mensagem de SR RTCP recebido, mesmo se o dispositivo receptor tivesse anteriormente enviado uma mensagem de RR RTCP que tem o mesmo LSR. Se o dispositivo receptor ainda não tivesse enviado um RR, o dispositivo receptor pode combinar uma mensagem de RR completa com a mensagem de TMMBR. Em outros exemplos, para reduzir o tamanho da mensagem, o dispositivo receptor só pode enviar os dados LSR juntamente com a mensagem de TMMBR, que pode ser utilizado para calcular o TTR.
[0122] Em um outro exemplo, se o dispositivo receptor já enviou um RR, o dispositivo remetente pode calcular a duração de armazenamento (ΔT) 128 de forma mais precisa como a diferença de tempo entre a recepção da última mensagem de RR recebida e a nova mensagem de RR (por exemplo, que foi enviada pelo receptor depois o congestionamento ser detectado).
[0123] Em ainda outro exemplo, o dispositivo remetente pode monitorar o atraso (por exemplo, o RTT) e o dispositivo remetente pode manter o envio de dados à taxa reduzida de Ru até que o atraso seja suficientemente reduzido. Por exemplo, o dispositivo remetente pode manter a taxa de envio à taxa reduzida de Ru até que a quantidade de dados armazenada num armazenador do dispositivo remetente caia abaixo de um nível limite.
[0124] Ad figuras 6A e 6B são gráficos que ilustram um declínio da taxa de link de rede e um tempo de atraso correspondente, respectivamente. O gráfico da figura 6A pode ser associado com a linha 80 da figura 4A, enquanto o gráfico da figura 6B pode ser associado com a linha 88 da figura 4B. Por exemplo, a figura 6A mostra uma largura de banda de rede 140 ilustrada pela linha tracejada (também referida como taxa de link de rede) e uma taxa de envio 142 ilustrada por uma linha cheia (também referida como uma taxa de codificação de bits) (por exemplo, medida em kilobytes por segundo (Kbps)). Tal como ilustrado na figura 6A, um dispositivo remetente (por exemplo, tal como o sistema codificador 12) pode codificar os dados na taxa de envio 142, a uma taxa igual ou semelhante à largura de banda 140. Assim, quando a largura de banda 140 é reduzida no tempo 144, o dispositivo remetente pode reduzir a taxa de envio 142 para aproximadamente o mesmo valor que a largura de banda 140.
[0125] Conforme mostrado no gráfico de atraso correspondente da figura 6B, após o declínio da largura de banda 140, o atraso no sistema codificador 12 pode ser aumentado a partir de um primeiro nível 146 para um segundo nível 148 (por exemplo, medido em milissegundos (ms)). Tal como aqui descrito, o atraso aumenta mediante a diminuição da largura de banda, porque não há um tempo de reação associado com a redução da taxa de envio 142 para o nível de largura de banda 140. O sistema codificador 12 pode armazenar dados que são codificados à taxa original (superior) antes de reduzir a taxa de envio 142 para coincidir com a largura de banda 140. Tal como mostrado na figura 6B, o atraso pode persistir durante um período relativamente longo, se técnicas para reduzir o atraso não são aplicadas.
[0126] As figuras 7A e 7B são gráficos que ilustram um declínio da taxa de link de rede e um tempo de atraso correspondente, respectivamente. O gráfico da figura 7A pode ser associado com as linhas 82 e 86 da figura 4A, enquanto o gráfico da figura 7B pode ser associado com a linha tracejada 90 da figura 4B. Por exemplo, a figura 7A mostra uma largura de banda de rede 160 ilustrada por uma linha tracejada (também referida como taxa de link de rede) e uma taxa de envio 162 ilustrada por uma linha cheia (também referida como uma taxa de codificação de bits) (por exemplo, medida em kilobytes por segundo (Kbps)). Como ilustrado na figura 7A, um dispositivo remetente (por exemplo, tal como o sistema codificador 12) pode, inicialmente, codificar os dados na taxa de envio 162, a uma taxa igual ou semelhante à largura de banda 160.
[0127] De acordo com aspectos da presente divulgação, quando a largura de banda 160 é reduzida no tempo 164, o dispositivo remetente pode reduzir a taxa de envio a uma taxa reduzida, que é menor do que a largura de banda 160. Isto é, o dispositivo remetente pode determinar uma taxa de envio 162 que não alcança largura de banda 140, a fim de reduzir o atraso associado com a diminuição da largura de banda 160. Tal como aqui descrito, o dispositivo remetente pode determinar um tempo de armazenamento, uma taxa reduzida e/ou uma duração da taxa de recuperação de acordo com as técnicas desta divulgação.
[0128] Conforme mostrado no gráfico de atraso correspondente da figura 7B, após a diminuição em largura de banda 160, o atraso no sistema codificador 12 pode ser aumentado a partir de um primeiro nível 166 para um segundo nível 168 (por exemplo, medido em milissegundos (ms)). Como observado acima, o atraso aumenta mediante a diminuição da largura de banda, porque não há um tempo de reação associado com a redução da taxa de envio 162, em resposta à diminuição em largura de banda 160. No entanto, ao reduzir a taxa de envio 162 a uma taxa reduzida (não alcance de largura de banda 160), sistema codificador 12 pode reduzir o atraso mais rapidamente do que o exemplo mostrado na figura 6B.
[0129] A figura 8 é um diagrama de fluxo que ilustra um exemplo de processo para comutação descendente de uma taxa à qual os dados são transmitidos. O exemplo da figura 8 é descrito no que diz respeito ao sistema codificador 12 para finalidades de ilustração. No entanto, deve ser entendido que o processo da figura 8 pode ser efetuado por uma variedade de outros dispositivos e/ou processadores.
[0130] O sistema codificador 12 pode codificar e transmitir dados através de uma rede em uma primeira taxa (180). Ao transmitir os dados na primeira taxa, o sistema codificador 12 pode identificar uma redução na taxa de link de rede a partir de uma primeira taxa para uma segunda taxa (182). Por exemplo, o sistema codificador 12 pode monitorizar as condições de rede e/ou receber uma ou mais mensagens que indicam uma redução da taxa de link de rede.
[0131] O sistema codificador 12 pode determinar uma taxa de bits de recuperação que é menor que a segunda taxa de link de rede (reduzida) (184). Por exemplo, o sistema codificador 12 pode determinar uma taxa de bits para os dados de codificação que não alcança a nova taxa de link de rede. De acordo com aspectos da presente divulgação, o sistema codificador 12 pode determinar a taxa de bits de recuperação com base na diferença entre a primeira taxa de link de rede e a taxa de link de rede reduzida. Por exemplo, se a redução da taxa de link de rede é relativamente grande, o sistema codificador 12 pode determinar uma taxa de bits de recuperação que é relativamente agressiva (por exemplo, não alcançar a taxa reduzida por uma margem substancial). Da mesma forma, se a redução na taxa de link de rede é relativamente baixa, o sistema codificador 12 pode determinar uma taxa de bits de recuperação que é relativamente conservadora (por exemplo, não alcançar a taxa reduzida por uma margem relativamente pequena.
[0132] Sistema codificador 12 pode também determinar uma duração de armazenamento com base em um atraso de reação (por exemplo, um tempo associado com a redução da taxa de envio, em resposta à redução da taxa de link de rede) (186). O sistema codificador 12 pode determinar a duração de armazenamento em uma variedade de maneiras. Por exemplo, o sistema codificador 12 pode determinar a duração de armazenamento estimando a duração de armazenamento de informação de rede, tal como tempo de ida e volta (RTT) entre o sistema codificador 12 e um dispositivo receptor, atrasos de downlink, um atraso de reação de adaptação de taxa, um atraso de reação de controle do congestionamento, atrasos de geração de mensagem, ou semelhante. O sistema codificador 12 pode determinar a informação da rede de forma independente ou pode receber a informação de rede do dispositivo receptor.
[0133] O sistema codificador 12 pode, então, determinar a duração da taxa de recuperação para manter a taxa de bits de recuperação (188). Em alguns exemplos, o sistema codificador 12 pode determinar a duração da taxa de recuperação com base em uma magnitude da taxa de recuperação e com base na duração de armazenamento. Em alguns exemplos, o sistema codificador 12 pode determinar um tempo de armazenamento que é proporcional à magnitude da redução da taxa de link de rede (por exemplo, como indicado pela taxa de recuperação) e a quantidade de tempo associada com a reação para a redução da taxa de link de rede (por exemplo, tal como indicado pela duração de armazenamento).
[0134] O sistema codificador 12 pode transmitir dados na taxa de bits de recuperação para a duração de taxa de recuperação (190). Em alguns exemplos, se a taxa de link de rede aumenta durante a duração da taxa de recuperação, o sistema codificador 12 pode terminar a duração da taxa de recuperação precoce e pode comutação ascendente a uma taxa de envio superior. Deve ser entendido que, dependendo do exemplo, certos atos ou eventos de qualquer uma das técnicas descritas em relação à figura 8 podem ser realizados em uma sequência diferente, podem ser adicionados, fundidos, ou deixados de fora (por exemplo, nem todas as ações ou eventos descritos são necessários para a prática das técnicas).
[0135] A figura 9 é um diagrama de fluxo que ilustra um processo exemplar de comutação ascendente de uma taxa à qual os dados são transmitidos. O exemplo da figura 9 é descrito no que diz respeito ao sistema decodificador 14 para efeitos de ilustração. No entanto, deve ser entendido que o processo da Figura 9 pode ser realizado por uma variedade de outros dispositivos e/ou processadores.
[0136] Sistema decodificador 14 pode determinar um tempo no qual os dados são recebidos (200). Por exemplo, em alguns casos, o sistema decodificador 14 pode identificar o tempo no qual dados são recebidos e armazenados pelo sistema decodificador 14. Em outros casos, o sistema decodificador 14 pode identificar o tempo no qual os dados são processados (por exemplo, decodificados) pelo sistema decodificador 14.
[0137] O sistema decodificador 14 pode também determinar um tempo de reprodução dos dados recebidos (202). Por exemplo, os dados recebidos podem incluir uma indicação do tempo no qual pretende-se que os dados sejam emitidos para exibição a um usuário. Por conseguinte, a indicação do tempo de reprodução pode ajudar o sistema decodificador 14 em organizar e dados para emissão.
[0138] Sistema decodificador 14 pode determinar um parâmetro de excesso de atraso permitido (204). Por exemplo, o sistema decodificador 14 pode determinar o parâmetro de excesso de atraso permitido com base na diferença entre o tempo no qual os dados são recebidos e o tempo no qual os dados recebidos são programados para serem reproduzidos. Como aqui descrito, o atraso pode referir-se ao tempo entre os dados que estão disponíveis para a transmissão através de um link de rede e o tempo que os dados são realmente transmitidos para a rede no dispositivo remetente. Por conseguinte, o parâmetro de excesso de atraso permitido pode indicar uma quantidade de atraso que é suportável pelo sistema antes de experiência do usuário ser afetada. Isto é, o parâmetro de excesso de atraso admissível pode geralmente indicar uma quantidade de tempo que pode ser utilizada pelo dispositivo remetente como uma base para aumentar a taxa de bits, sem afetar a experiência do usuário.
[0139] Sistema decodificador 14 pode, então, determinar um aumento da taxa de bits remetente (206). Por exemplo, de acordo com aspectos da presente divulgação, o sistema decodificador 14 pode determinar o aumento de taxa de bits remetente com base no parâmetro de excesso de atraso permitido. Ou seja, o sistema decodificador 14 pode determinar quanto a taxa remetente pode ser aumentada pelo dispositivo remetente sem a introdução de congestionamento no sistema.
[0140] Em alguns exemplos, o sistema decodificador 14 pode determinar um aumento da taxa passo a passo a ser adicionado à taxa de envio. Por exemplo, o sistema decodificador 14 pode determinar o aumento de taxa de bits remetente com base no parâmetro de excesso de atraso permitido uma taxa de envio média atual na qual os dados foram recebidos antes de se determinar o aumento de taxa de envio (por exemplo, uma taxa de recepção atual). Neste exemplo, o sistema decodificador 14 pode determinar o quanto a taxa de envio atual pode ser aumentada sem aumentar a taxa além de uma taxa de link sustentável (por exemplo, uma taxa em que os pacotes chegam ao sistema decodificador 14, após um tempo de reprodução programado dos pacotes).
[0141] Em alguns casos, o sistema decodificador 14 pode também considerar uma quantidade de tempo necessária para transmitir mensagens entre o sistema decodificador 14 e um dispositivo remetente (por exemplo, um tempo de ida e volta) e/ou um atraso associado com a identificação de atraso no sistema decodificador 14. Por exemplo, o sistema decodificador 14 pode determinar o aumento da taxa de bit remetente com base em uma relação entre o parâmetro de excesso de atraso admissível multiplicado pela taxa de recepção para uma soma do tempo de ida e volta e um tempo para a detecção de um atraso no sistema decodificador 14.
[0142] O sistema decodificador 14 pode, em seguida, transmitir uma indicação de aumento de taxa de envio (208). Por exemplo, o sistema decodificador 14 pode enviar dados que representam um aumento de taxa de envio passo a passo para o dispositivo remetente para o dispositivo remetente para adicionar à taxa de envio. Em outro exemplo, o sistema decodificador 14 pode enviar dados que representam uma taxa de envio solicitada que incorpora o aumento de taxa de envio para o dispositivo remetente.
[0143] Em alguns exemplos, o sistema decodificador 14 só pode transmitir a indicação do aumento da taxa de bit remetente quando o aumento da taxa de bit remetente exceder um valor limite. Por exemplo, o sistema decodificador 14 pode comparar um aumento de taxa de bits remetente para um determinado limite. Em um exemplo, o sistema decodificador 14 só pode transmitir a indicação do aumento da taxa de bits remetente quando o aumento da taxa de bits remetente exceder cerca de cinco por cento da taxa de recepção. Em outro exemplo, o sistema decodificador 14 só pode transmitir a indicação do aumento da taxa de bits remetente quando o aumento da taxa de bits remetente exceder cerca de quinze por cento da taxa de recepção. Outros valores limites ou percentagens são também possíveis.
[0144] Deve ser entendido que, dependendo do exemplo, certos atos ou eventos de qualquer uma das técnicas descritas em relação à figura 9 podem ser realizados em uma sequência diferente, podem ser adicionados, fundidos, ou deixados de fora (por exemplo, nem todas os atos ou eventos descritos são necessários para a prática das técnicas).
[0145] Enquanto certos exemplos aqui descritos foram descritos com relação a uma perspectiva particular (por exemplo, ser realizado por um "dispositivo remetente" ou um "dispositivo receptor") deve-se compreender que as técnicas desta divulgação não são limitadas desta forma. Por exemplo, como notado acima, VT é frequentemente um fluxo de comunicação de duas vias. Por conseguinte, as técnicas similares podem ser aplicadas em ambos os percursos de rede direto e reverso, por exemplo, tanto por um "dispositivo remetente" quanto por um "dispositivo receptor". Além disso, enquanto alguns dispositivos são mostradas e descritos em relação a uma determinada perspectiva, para fins de ilustração, deve ser entendido que os dispositivos aqui descritos podem ter mais ou menos componentes do que os mostrados. Como um exemplo, um dispositivo remetente pode incorporar tanto codificador de vídeo 20 (figura 2) quanto o decodificador de vídeo (figura 3) e pode realizar cada uma das técnicas aqui descritas.
[0146] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware, ou qualquer combinação dos mesmos. Se implementadas em software, as funções podem ser armazenadas em ou transmitidas através de, como uma ou mais instruções de código, ou um meio legível por computador e executadas por uma unidade de processamento com base em hardware. Meios legíveis por computador podem incluir meios de armazenamento legíveis por computador, que correspondem a um meio tangível tal como mídia de armazenamento de dados ou mídia de comunicação, incluindo qualquer meio que facilite a transferência de um programa de computador de um lugar para outro, por exemplo, de acordo com um protocolo de comunicação. Deste modo, meios legíveis por computador podem geralmente corresponder a (1) meios de armazenamento legível por computador tangível que é não transitório ou (2) um meio de comunicação, tal como um sinal ou onda de portadora. Mídia de armazenamento de dados pode ser qualquer mídia disponível que pode ser acessada por um ou mais computadores ou um ou mais processadores para recuperar instruções de código, e/ou estruturas de dados para a implementação das técnicas descritas nesta divulgação. Um produto de programa de computador pode incluir um meio legível por computador.
[0147] A título de exemplo, e não como limitação, tais meios de armazenamento legíveis por computador podem compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco óptico, armazenamento em disco magnético, ou outros dispositivos de armazenamento magnético, memória flash, ou qualquer outro meio que possa ser utilizado para armazenar o código de programa desejado sob a forma de instruções ou estruturas de dados, e que pode ser acessado por um computador. Além disso, qualquer ligação é denominada adequadamente um meio legível por computador. Por exemplo, se as instruções são transmitidas de um site, servidor ou outra fonte remota utilizando um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fio, tais como infravermelhos, rádio e micro-ondas, então o cabo coaxial, cabo de fibra óptica, par trançado, DSL, ou tecnologias sem fio, tais como infravermelho, rádio e micro-ondas estão incluídas na definição de meio. Deve ser entendido, no entanto, que mídias de armazenamento legíveis por computador e mídias de armazenamento de dados não incluem conexões, ondas de portadoras, sinais ou outras mídias de comunicação transitórias, mas são direcionadas para meios de armazenamento tangível não transitório. Disco e disquete, como aqui utilizado, incluem disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco Blu-ray, onde discos geralmente reproduzem dados magneticamente, enquanto que discos reproduzem dados opticamente com lasers. Combinações dos anteriores também devem ser incluídas no âmbito dos meios legíveis por computador.
[0148] Instruções podem ser executadas por um ou mais processadores, tais como um ou mais processadores de sinal digital (DSPs), microprocessadores de uso geral, circuitos integrados de aplicação específica (ASIC), arranjos lógicos programáveis em campo (FPGA), ou outro equivalente integrado ou conjunto de circuitos lógicos discretos. Por conseguinte, o termo "processador" tal como aqui utilizado pode referir-se a qualquer uma da estrutura precedente ou de qualquer outra estrutura adequada para aplicação das técnicas aqui descritas. Além disso, em alguns aspectos, a funcionalidade aqui descrita pode ser provida dentro de hardware dedicado e/ou unidades de software ou módulos configurados para codificação e decodificação, ou incorporada em um codec combinado. Além disso, as técnicas podem ser totalmente implementadas em um ou mais circuitos ou elementos lógicos.
[0149] As técnicas da presente divulgação podem ser implementadas em uma vasta variedade de dispositivos ou aparelhos, incluindo um aparelho telefônico sem fio, um circuito integrado (IC) ou um conjunto de ICs (por exemplo, um conjunto de chips). Vários componentes, módulos ou unidades são descritos nesta divulgação para enfatizar os aspectos funcionais de dispositivos configurados para executar as técnicas divulgadas, mas não precisam necessariamente de realização por diferentes unidades de hardware. Em vez disso, tal como descrito acima, várias unidades podem ser combinadas em uma unidade de hardware codec ou providas por um conjunto de unidades de hardware interoperativo, incluindo um ou mais processadores, conforme descrito acima, em conjunto com o software e/ou firmware adequado.
[0150] Vários exemplos foram descritos. Estes e outros exemplos estão dentro do âmbito das reivindicações seguintes.

Claims (12)

1. Método de processamento de dados de vídeo, caracterizado pelo fato de que compreende: determinar (204), por um dispositivo receptor, um excesso de atraso admissível indicando uma quantidade de tempo que pode ser utilizada para determinar uma taxa de bits de remetente aumentada, o valor do excesso de atraso admissível sendo determinado como a diferença entre um tempo no qual os dados recebidos são recebidos pelo dispositivo receptor e um tempo no qual os dados recebidos são programados para serem reproduzidos; determinar uma taxa de recepção na qual os dados foram recebidos pelo dispositivo receptor; determinar um tempo de ida e volta para a transmissão de dados entre o dispositivo receptor e o dispositivo remetente; determinar (206), pelo dispositivo receptor, uma quantidade pela qual aumentar uma taxa de bits remetente atual utilizando o excesso de atraso admissível determinado, a taxa de recepção e o tempo de ida e volta; e transmitir (208) uma indicação da quantidade pela qual aumentar uma taxa de bits remetente atual para o dispositivo remetente.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a determinação da quantidade pela qual aumentar uma taxa de bits remetente atual compreende a determinação do aumento da taxa de bits remetente apenas quando o tempo no qual os dados são recebidos é anterior ao tempo no qual os dados recebidos são programados para serem reproduzidos, tal que o excesso de atraso admissível é maior que zero.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a determinação da quantidade pela qual aumentar uma taxa de bits remetente atual compreende a determinação de uma razão do excesso de atraso permitido multiplicado pela taxa de recepção para o tempo de ida e volta.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que adicionalmente compreende a determinação da quantidade pela qual aumentar uma taxa de bits remetente atual adicionalmente utiliza um tempo para detectar um atraso no dispositivo receptor, e compreende utilizar uma razão do excesso de atraso admissível multiplicado pela taxa de recepção para uma soma do tempo de ida e volta e do tempo para detectar um atraso no dispositivo receptor.
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a transmissão da indicação da quantidade pela qual aumentar uma taxa de bits remetente atual compreende a transmissão de um aumento em etapas a ser adicionado, pelo dispositivo remetente, à taxa de bits remetente atual.
6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a transmissão da indicação da quantidade pela qual aumentar uma taxa de bits remetente atual compreende a transmissão de uma taxa de envio solicitada para o dispositivo remetente, a taxa de envio solicitada compreendendo uma combinação da quantidade pela qual aumentar uma taxa de bits remetente atual e uma taxa de recepção à qual os dados foram recebidos pelo dispositivo receptor antes de determinar o aumento da taxa de bits remetente.
7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que a transmissão da taxa de envio solicitada compreende a transmissão da taxa de envio solicitada apenas quando a quantidade pela qual aumentar uma taxa de bits remetente atual excede um limite predeterminado.
8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que o limite predeterminado é superior a aproximadamente cinco por cento da taxa de recepção a que os dados foram recebidos pelo dispositivo receptor antes de determinar a quantidade pela qual aumentar uma taxa de bits remetente atual.
9. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que o limite predeterminado é superior a aproximadamente 15 por cento da taxa de recepção a que os dados foram recebidos pelo dispositivo receptor antes de determinar a quantidade pela qual aumentar uma taxa de bits remetente atual.
10. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que a transmissão da taxa de envio solicitada compreende a geração de uma mensagem de Solicitação de taxa de bits de fluxo de mídia máxima temporária, TMMBR, que inclui uma indicação de taxa de envio solicitada.
11. Dispositivo receptor para processamento de dados de vídeo, caracterizado pelo fato de que compreende: meios para determinar um excesso de atraso admissível indicando uma quantidade de tempo que pode ser utilizada para determinar uma taxa de bits de remetente aumentada, os meios configurados para determinar o excesso de atraso admissível como a diferença entre um tempo no qual os dados recebidos são recebidos pelo dispositivo receptor e um tempo no qual os dados recebidos são programados para serem reproduzidos; meios para determinar uma taxa de recepção na qual os dados foram recebidos pelo dispositivo receptor; meios para determinar um tempo de ida e volta para a transmissão de dados entre o dispositivo receptor e o dispositivo remetente; meios para determinar uma quantidade pela qual aumentar uma taxa de bits remetente atual, os meios configurados para utilizar o excesso de atraso admissível determinado, a taxa de recepção e o tempo de ida e volta; e meios para transmitir uma indicação da quantidade pela qual aumentar uma taxa de bits remetente atual para o dispositivo remetente.
12. Memória legível por computador, caracterizada pelo fato de que compreende gravado na mesma o método de acordo com qualquer uma das reivindicações de 1 a 10.
BR112017001510-2A 2014-07-29 2015-07-29 Método e dispositivo receptor para processamento de dados de vídeo, e memória legível por computador BR112017001510B1 (pt)

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,569 US9438853B2 (en) 2014-07-29 2015-07-28 Receiver driven up-switching in video telephony
US14/811,569 2015-07-28
PCT/US2015/042664 WO2016019019A1 (en) 2014-07-29 2015-07-29 Receiver driven up-switching in video telephony

Publications (2)

Publication Number Publication Date
BR112017001510A2 BR112017001510A2 (pt) 2017-11-21
BR112017001510B1 true BR112017001510B1 (pt) 2023-10-24

Family

ID=55181425

Family Applications (2)

Application Number Title Priority Date Filing Date
BR112017001040-2A BR112017001040B1 (pt) 2014-07-29 2015-07-29 Redução do atraso na telefonia por vídeo
BR112017001510-2A BR112017001510B1 (pt) 2014-07-29 2015-07-29 Método e dispositivo receptor para processamento de dados de vídeo, e memória legível por computador

Family Applications Before (1)

Application Number Title Priority Date Filing Date
BR112017001040-2A BR112017001040B1 (pt) 2014-07-29 2015-07-29 Redução do atraso na telefonia por vídeo

Country Status (11)

Country Link
US (2) US9438853B2 (pt)
EP (2) EP3175584B1 (pt)
JP (3) JP6602842B2 (pt)
KR (2) KR102366630B1 (pt)
CN (2) CN106537855B (pt)
AU (1) AU2015296540B2 (pt)
BR (2) BR112017001040B1 (pt)
CA (1) CA2953711C (pt)
ES (2) ES2739527T3 (pt)
HU (2) HUE037155T2 (pt)
WO (2) WO2016019015A1 (pt)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2942958B1 (en) * 2013-01-07 2018-03-21 NEC Corporation Coding unit split signaling for pcm coded blocks
US9438853B2 (en) * 2014-07-29 2016-09-06 Qualcomm Incorporated Receiver driven up-switching in video telephony
US9913167B2 (en) 2015-02-02 2018-03-06 Accelerated Media Technologies, Inc. Systems and methods for assigning bit rate
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
WO2020034463A1 (en) * 2018-11-14 2020-02-20 Zte Corporation Systems and methods for determining communication parameters for non terrestrial networks
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

Family Cites Families (38)

* 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
US8416694B2 (en) 2004-06-22 2013-04-09 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
US8626896B2 (en) * 2007-12-13 2014-01-07 Dell Products, Lp System and method of managing network connections using a link policy
JP4843090B2 (ja) * 2007-12-20 2011-12-21 株式会社エヌ・ティ・ティ・ドコモ 移動局、基地局装置、通信制御方法及び移動通信システム
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
CN103999414B (zh) * 2011-09-30 2017-09-08 英国电讯有限公司 一种归因针对相应用户寄存器的共享资源的拥塞贡献的方法和装置
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
CN104718735A (zh) * 2012-08-21 2015-06-17 惠普发展公司,有限责任合伙企业 网络中的拥塞通知
US9247448B2 (en) * 2012-08-27 2016-01-26 Qualcomm Incorporated Device and method for adaptive rate multimedia communications on a wireless network
ES2784863T3 (es) * 2012-09-26 2020-10-01 Lg Electronics Inc Método y aparato para controlar la potencia de transmisión del canal de control de enlace ascendente
TWI474740B (zh) 2012-12-04 2015-02-21 Univ Nat Taiwan Science Tech 資料叢發排程方法
WO2014155043A1 (en) 2013-03-28 2014-10-02 British Telecommunications Public Limited Company Re-marking of packets for queue control
CN105075323B (zh) * 2013-03-29 2019-02-05 Vid拓展公司 早期分组丢失检测和反馈
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
US9794311B2 (en) * 2014-03-18 2017-10-17 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US9438853B2 (en) 2014-07-29 2016-09-06 Qualcomm Incorporated Receiver driven up-switching in video telephony

Also Published As

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

Similar Documents

Publication Publication Date Title
BR112017001510B1 (pt) Método e dispositivo receptor para processamento de dados de vídeo, e memória legível por computador
US10419502B2 (en) Systems and methods for using client-side video buffer occupancy for enhanced quality of experience in a communication network
JP5023144B2 (ja) ビデオストリーミング診断
EP3335341B1 (en) Sender side video telephony downgrade method
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
US10492085B2 (en) Real-time transport protocol congestion control techniques in video telephony
GB2527365A (en) A telecommunication end-point device data transmission controller

Legal Events

Date Code Title Description
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 29/07/2015, OBSERVADAS AS CONDICOES LEGAIS