BRPI0822489B1 - Método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo, dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo, e, meio legível por computador - Google Patents

Método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo, dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo, e, meio legível por computador Download PDF

Info

Publication number
BRPI0822489B1
BRPI0822489B1 BRPI0822489-7A BRPI0822489A BRPI0822489B1 BR PI0822489 B1 BRPI0822489 B1 BR PI0822489B1 BR PI0822489 A BRPI0822489 A BR PI0822489A BR PI0822489 B1 BRPI0822489 B1 BR PI0822489B1
Authority
BR
Brazil
Prior art keywords
target rate
video
rate
indicator
delay
Prior art date
Application number
BRPI0822489-7A
Other languages
English (en)
Inventor
Arto Juhani Mahkonen
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of BRPI0822489A2 publication Critical patent/BRPI0822489A2/pt
Publication of BRPI0822489B1 publication Critical patent/BRPI0822489B1/pt

Links

Images

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/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
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/18End to end
    • 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/25Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/752Media network packet handling adapting media to network capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • 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/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805Controlling the feeding rate to the network, e.g. by controlling the video pump
    • 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/442Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637Control signals issued by the client directed to the server or network components
    • H04N21/6373Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/29Flow control; Congestion control using a combination of thresholds
    • H04L65/1006
    • H04L65/608

Abstract

método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo, dispositivo para calcular uma nova taxa alvo alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo, provedor de vídeo, e, meio legível por computador um dispositivo, sistema, e método para adaptar uma taxa alvo atual de um sinal de vídeo [vs] transmitida de um provedor de vídeo [32] para um receptor de vídeo [10]. o método inclui receber o sinal de vídeo [vs] no receptor de vídeo [10], medindo no receptor de vídeo [10] pelo menos um indicador do sinal de vídeo recebido [vs], o pelo menos um indicador sendo diferente a partir de uma taxa de perda de pacote, calculando no receptor de sinal [vs], o pelo menos um indicador, e pelo menos uma referência, e transmitir a partir do receptor de vídeo [10] a nova taxa alvo para o provedor de vídeo [32] para adaptar a taxa alvo atual.

Description

CAMPO TÉCNICO
[001] A presente invenção relaciona-se geralmente a sistemas habilitados de vídeo, dispositivos, software e métodos e, mais particularmente, a mecanismos e técnicas para adaptar uma taxa alvo de um sinal de vídeo.
FUNDAMENTOS
[002] Com o desenvolvimento da Internet e tecnologias relacionadas e devido ao aumento contínuo das capacidades de largura de faixa das redes de comunicação, a transmissão de informação de vídeo através da Internet torna-se mais popular e mais confiável. No passado, a qualidade dos sinais de vídeo transmitidos através da Internet têm sido baixa pelas razões a seguir. Nos serviços de telefonia de vídeo conversational, o codificador de vídeo usualmente aplica uma função de controle de taxa pré-determinada, que tenta manter uma taxa de bit de fonte média constante, tão próxima quanto possível de uma taxa de bit alvo desejada.
[003] Em redes comutadas por pacote, como Vídeo Telefonia sobre IP (VToIP), um retardo de transporte de pacotes de vídeo variará devido a diversas razões. Uma das razões é a carga variável nos enlaces de transporte, o que pode causar uma flutuação de baixa freqüência do retardo de transporte e mesmos picos de congestionamento em salvas, conforme mostrado por exemplo, na Figura 1. Figura 1 mostra um exemplo de um pico de congestionamento entre 40 e 50 s. O retardo de transporte de vídeo está ocorrendo conforme mostrado na Figura 1, quando o transmissor/receptor não tem adaptação de taxa alvo e o tamanho da armazenagem temporária é infinito. O tamanho da armazenagem temporária infinito significa que pacotes jamais são perdidos devido a sobrecarga da armazenagem temporária. O pico de congestionamento pode ocorrer devido a um aumento súbito no tráfego da Internet e pode durar até vários segundos. Na Figura 1, o congestionamento dura de 10 s a 50 s. Os picos de congestionamentos convencionalmente podem fazer com que a transmissão dos dados de vídeo fique lenta, o que resulta, no lado do receptor, em uma degradação de uma qualidade de uma imagem percebida, como por exemplo, uma variação de retardo, perdas de pacote ou um congelamento e salto de uma imagem visualizada. Então,no passado era improvável, usando a Internet e não uma rede de transmissão dedicada, receber um sinal de vídeo de boa qualidade que permanecesse ao longo de um certo tempo, por exemplo, o par de minutos que poderia ser necessário para ter uma vídeo conferência ou uma conversação de videofone.
[004] A integridade do vídeo decodificado é usualmente danificada devido a perda, pois é sabido que a compressão de vídeo é baseada na compensação de movimento, que usa quadros decodificados anteriores como referência para os quadros futuros. Quanto tempo estas perturbações permanecem, dependerá do processo de Intra-Restauração (IR isto é, codificar um quadro ou partes do quadro sem compensação de movimento) que é usado. O processo de IR é necessário porque uma transmissão de dados de vídeo através de uma rede sem fio pode ser não confiável devido a perda de canal. Erros resultantes da perda de canal podem impactar adversamente a qualidade do vídeo apresentado a um usuário. Em particular, erros de canal podem reduzir não só a qualidade de um quadro atual, como também quadros Inter-Codificados subseqüentes gerados a partir do quadro atual, usando técnicas de estimativa e compensação de movimento. Para limitar a propagação de erros induzidos de canal de um quadro para outro, um codificador de vídeo tipicamente aplica um processo de IR. Os processos de IR são descritos, por exemplo, pelo Grupo de Especialistas de Imagem Móvel (MPEG) ou pela União de Telecomunicação Internacional (ITU).
[005] Para equacionar estes problemas, foram propostas várias técnicas do estado da arte atual. Algumas das técnicas existentes se baseiam nos métodos de controle de admissão, que tipicamente bloqueiam novas sessões quando uma rede de comunicação carregada (ou um enlace carregado entre nós) é detectada. Algumas das técnicas usam adaptação de taxa de vídeo alvo, que é baseada em uma realimentação de um receptor de vídeo para um remetente.
[006] Entretanto, um problema associado aos métodos de adaptação de taxa de vídeo alvo é que estes são usualmente baseados em alguma capacidade máxima agregada média, que pode ser insensível a congestionamentos temporários (tempo curto) causados por multiplexação estatística de fluxos de taxa variável. Os congestionamentos temporários são relevantes e deveriam ser equacionados se o melhor esforço de tráfego estiver competindo pelos mesmos recursos. Há também métodos de controle de admissão dinâmicos baseados em medição mais avançados, porém estes métodos são usualmente baseados em nível de enlace a enlace ao invés de nível de extremidade a extremidade. O nível de enlace a enlace refere-se, por exemplo, a um sistema de estações base múltiplas e telefones móveis. Dois telefones móveis são conectados um a outro através de diversos enlaces, cada enlace conectando uma estação base ao telefone móvel ou a estação base a uma outra estação base ou a um outro nó de rede (como um controlador de rede rádio, ponto de conexão ou roteador). O número de enlaces entre os dois telefones móveis depende da distância geográfica entre os telefones e se os telefones móveis estão localizados na mesma rede de acesso rádio ou não. Então, neste exemplo particular, mais de dois enlaces podem existir entre os dois telefones móveis e os métodos de controle medem vários parâmetros para cada enlace. Diferentemente do nível de enlace a enlace, o nível de extremidade a extremidade monitora os sinais recebidos nos dois telefones móveis e não nos enlaces entre vários nós de rede.
[007] Os métodos de adaptação de taxa alta geralmente usam monitoração de nível de extremidade a extremidade. Entretanto, os métodos existentes são baseados em um mecanismo de realimentação mais suave, que usualmente não pode conviver com os picos de congestionamentos em salvas. Um outro problema dos métodos existentes é a recuperação pobre da taxa alvo de volta a seu nível original, após terminar o período de congestionamento. Por exemplo, um método tradicional adapta uma taxa alvo com base em medições de perda de pacote. Um primeiro problema deste método é que leva muito tempo para receber medições confiáveis da taxa de perda de pacote (PLR) no transmissor, a partir do receptor. Quando a PLR é considerada alta, a taxa alvo no codificador é reduzida, porém este processo ocorre tarde demais, e o pico de congestionamento pode até ter terminado. Ainda um outro problema associado a este método é que, quando a PLR = 0, é difícil saber de quanto aumentar a taxa alvo sem causar perdas de pacote e deteriorar a qualidade de vídeo transmitido, porque a combinação de (i) uma PLR medida que é 0 e (ii) uma taxa alvo reduzida não implica necessariamente em que o congestionamento tenha terminado. Para evitar este problema, a taxa alvo nos métodos existentes se recupera muito lentamente ou pode mesmo permanecer baixa permanentemente, o que resulta no codificador de vídeo usar uma taxa alvo baixa e conseqüentemente degradar desnecessariamente a qualidade percebida do vídeo transmitido, mesmo após um pico de congestionamento temporário.
[008] Então, é um alvo das seguintes realizações típicas equacionar e resolver um ou mais dos problemas discutidos acima dos métodos e técnicas existentes.
SUMÁRIO
[009] De acordo com uma realização típica, há um método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de video para um receptor de vídeo. O método inclui receber o sinal de vídeo no receptor de vídeo; medir, no receptor de vídeo, pelo menos um indicador do sinal de vídeo recebido, o pelo menos um indicador sendo diferente de uma taxa de perda de pacote; calcular, no receptor de vídeo, uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido, o pelo menos um indicador, e pelo menos uma referência; e transmitir a partir do receptor de vídeo a nova taxa alvo para o provedor de vídeo adaptai' a taxa alvo atual.
[0010] De acordo com uma outra realização típica, há um método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo. O método inclui transmitir o sinal de vídeo na taxa alvo atual a partir do provedor de vídeo; receber no provedor de vídeo pelo menos um indicador do sinal de vídeo recebido pelo receptor de vídeo, o pelo menos um indicador sendo diferente de uma taxa de perda de pacote; calcular, no provedor de vídeo, uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo transmitido, no pelo menos um indicador e em pelo menos uma referência; e adaptar, no provedor de vídeo, a taxa alvo atual à nova taxa alvo.
[0011] De acordo ainda com uma outra realização típica, há um dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo. O dispositivo inclui pelo menos uma porta de entrada/saída configurada para receber o sinal de vídeo; um processador conectado à pelo menos uma porta de entrada/saída e configurado para determinar pelo menos um indicador a partir do sinal de vídeo recebido, o pelo menos um indicador sendo diferente de uma taxa de perda de pacote; calcular, uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido, no pelo menos um indicador e em pelo menos uma referência; e a porta de entrada/saída é adicionalmente configurada para transmitir a nova taxa alvo ao provedor de vídeo, de tal modo que o provedor de vídeo adapta a taxa atual à nova taxa alvo.
[0012] De acordo com uma outra realização típica, há um provedor de vídeo para adaptar uma taxa alvo atual de um sinal de vídeo transmitido a um receptor de vídeo. O provedor de vídeo inclui uma entrada/saída configurada para transmitir o sinal de vídeo na taxa alvo atual e receber pelo menos um indicador medido pelo receptor de vídeo, com base no sinal de vídeo recebido, o pelo menos um indicador sendo diferente de uma taxa de perda de pacote; e um processador configurado para calcular uma nova taxa alvo com base na taxa alvo atual do sinal de vídeo transmitido, no pelo menos um indicador e em pelo menos uma referência, e para adaptar a taxa alvo atual à nova taxa alvo.
[0013] De acordo com uma realização típica, há um dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo. O dispositivo inclui meios para recebe o sinal de vídeo; meios para medir, no dispositivo, pelo menos um indicador a partir do sinal de vídeo recebido, o pelo menos um indicador sendo diferente de uma taxa de perda de pacote; meio para calcular no dispositivo uma nova taxa alvo com base na taxa alvo atual do sinal de vídeo recebido, no pelo menos um indicador e em pelo menos uma referência; e o meio para receber é adicionalmente configurado para transmitir a nova taxa alvo ao provedor de vídeo, de tal modo que o provedor de vídeo adapta a taxa atual à nova taxa alvo.
[0014] De acordo com uma outra realização típica, há um sistema para adaptar uma taxa alvo atual de um sinal de vídeo. O sistema inclui um provedor de vídeo configurado para transmitir o sinal de vídeo na taxa alvo atual; um receptor de vídeo configurado para receber o sinal de vídeo, medir pelo menos um indicador a partir do sinal de vídeo recebido, o pelo menos um indicador sendo diferente de uma taxa de perda de pacote, calcular, uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido, no pelo menos um indicador e em pelo menos uma referência, e transmitir a nova taxa alvo ao provedor de vídeo; e uma estação base configurada para conectar o receptor de vídeo ao provedor de vídeo. O provedor de vídeo adapta a taxa atual à nova taxa alvo.
[0015] De acordo com uma outra realização típica, há um meio legível por computador incluindo instruções executáveis por computador, onde as instruções, quando executadas por um processador, fazem com que um receptor de vídeo incluindo o processador calcule uma nova taxa alvo do sinal de vídeo. As instruções incluem receber o sinal de vídeo no receptor de vídeo; medir, no receptor de vídeo, pelo menos um indicador do sinal de vídeo recebido, o pelo menos um indicador sendo diferente de uma taxa de perda de pacote; calcular, no receptor de vídeo, uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido, no pelo menos um indicador e em pelo menos uma referência; e transmitir a partir do receptor de vídeo a nova taxa alvo para o provedor de vídeo, para adaptação à taxa alvo atual. LISTA DE ABREVIAÇÕES VToIP - Vídeo Telefonia sobre IP; IR - Intra-Restauração; MPEG - Grupo de Especialistas de Imagem Móvel; ITU - União de Telecomunicação Internacional; PLR - Taxa de Perda de Pacote; PSNR - Relação de Sinal de Pico para Ruído; CDF - Funções de Distribuição Cumulativas; CCDF - Funções de Distribuição Cumulativas Complementares; LAN - Rede de Área Local; VS - Sinal de Vídeo; RTCP - Protocolo de Controle em Tempo Real; SDP - Protocolo de Descrição de Sessão; SR - Relatório de Remetente; RR - Relatório de Recepção; RTP - Protocolo de Transporte em Tempo Real; MBR - Taxa de Bit Máxima; GBR - Taxa de Bit Garantida; DVD -Disco Versátil Digital; ASIC - Circuito Integrado Específico de Aplicação; DSP - Processador de Sinal Digital; FPGA - Arranjo de Porta Programável em Campo; IC - Circuito Integrado; FM - Freqüência Modulada; ECD - Visor de Cristal Eíquido; OEED - Diodo Emissor de Euz Orgânico; WEAN - Rede de Área Focal Sem Fio;
BREVE DESCRIÇÃO DOS DESENHOS
[0016] Os desenhos anexos, que estão incorporados e constituem parte da especificação, ilustram uma ou mais realizações, e juntamente com a descrição explicam estas realizações. Nos desenhos: Figura 1 é um gráfico mostrando um pico de congestionamento em salvas; Figura 2 é um diagrama esquemático de um dispositivo habilitado por vídeo de acordo com uma realização típica; Figura 3 é um diagrama esquemático de um sistema de vídeo de acordo com uma realização típica; Figura 4 é um diagrama esquemático de um processo para ajustar uma taxa alvo atual de um sinal de vídeo de acordo com uma realização típica; Figura 5 é um gráfico mostrando uma variação da taxa alvo atual no tempo; Figura 6 é um gráfico mostrando um retardo de transporte em um receptor sem adaptação de taxa; Figura 7 é um gráfico mostrando um retardo de transporte em um receptor com adaptação de taxa alvo; Figura 8 é um gráfico mostrando distribuições cumulativas complementares dos retardos para três sistemas diferentes; Figura 9 é um gráfico mostrando um retardo de transporte e limites alto e baixo correspondentes; Figura 10 é um gráfico mostrando uma Relação de Sinal de Pico para Ruído (PSNR) para os três sistemas diferentes; Figura 11 é um gráfico mostrando as funções de distribuição cumulativas (CDF) das PSNRs para os três sistemas diferentes; Figura 12 é um fluxograma ilustrando um método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido a partir de um provedor de serviço para um receptor de vídeo; Figura 13 é um fluxograma ilustrando um outro método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido a partir de um provedor de serviço para um receptor de vídeo; Figura 14a é um diagrama esquemático de um sistema de vídeo de acordo com uma realização típica, na qual uma adaptação de taxa alvo baseada em requisição é usada; Figura 14b é um diagrama esquemático de um sistema de vídeo de acordo com uma realização típica, na qual uma adaptação de taxa alvo baseada em medição é usada; e Figura 15 é um diagrama esquemático de um processo para ajustar uma taxa alvo atual de um sinal de vídeo de acordo com a realização típica mostrada na Figura 14a.
DESCRIÇÃO DETALHADA
[0017] A seguinte descrição das realizações típicas refere-se aos desenhos que a acompanham. Os mesmos números de referência em diferentes desenhos identificam os mesmos ou elementos similares. A seguinte descrição detalhada não limita a invenção. Ao invés disso, o escopo da invenção é definido pelas reivindicações anexas. As seguintes realizações são discutidas, para simplicidade, com relação à terminologia e estrutura de um Vídeo Telefone. Entretanto, as realizações a serem discutidas a seguir não estão limitadas a um Vídeo Telefone porém podem ser aplicadas a outros dispositivos capazes de receber sinais de vídeo.
[0018] A referência através da especificação a “uma realização” significa que uma característica particular, estrutura ou característica descrita em conexão com uma realização está incluída em pelo menos uma realização da presente invenção. Então, o surgimento da frase “em uma realização” em vários locais através da especificação não está necessariamente se referindo totalmente à mesma realização. Adicionalmente, as apresentações particulares, estruturas ou características podem ser combinadas de qualquer maneira adequada em uma ou mais realizações.
[0019] No sentido de prover algum contexto para esta discussão, um dispositivo habilitado por vídeo 10 típico é mostrado na Figura 2. O dispositivo 10 pode ser um provedor de vídeo, um receptor de vídeo ou uma combinação dos dois. O dispositivo 10 inclui uma porta de entrada/saída 12 que é configurada para receber um sinal de vídeo VS. A porta de entrada/saída 12 pode ser conectada via um barramento 14 a uma antena 16 ou a uma linha com fio (não mostrada) para receber o sinal de vídeo VS. O sinal de vídeo VS pode ser transmitido ao longo da linha com fio ao dispositivo 10, ou sem fio. A antena 16 pode ser uma antena única ou uma antena múltipla e pode ser configurada para receber o sinal de vídeo VS via uma interface infravermelho, rádio freqüência ou outras interfaces sem fio conhecidas. A porta de entrada/saída 12 é também conectada a um processador 18 que recebe o sinal de vídeo VS para processamento. O processador 18 pode ser conectado via barramento 14 a uma memória 20. A memória 20 pode armazenar o sinal de vídeo VS e outros dados necessários para o processador 18, por exemplo, um alvo de taxa de dados do provedor de vídeo. Em uma realização típica, o dispositivo 10 pode possuir um visor 22 configurado para exibir uma imagem correspondente ao sinal de vídeo VS recebido. O dispositivo 10 pode possuir, em uma outra realização típica, uma interface de entrada/saída 24, por exemplo, um teclado, um mouse, uma microfone, uma câmera de vídeo, etc., que é capaz de inserir comandos a partir de um usuário. O dispositivo 10 pode possuir, em uma outra realização típica, uma unidade de medição 26, conectada ao barramento 14, que é capaz de medir vários indicadores do sinal de vídeo VS recebido.
[0020] Exemplos de vários indicadores incluem, porém não estão limitados a um retardo de transporte, retardo de armazenagem temporária ou nível, taxa de bits recebidos, ou taxa de pacotes, taxa de perda de pacotes, etc. Exemplos de definições dos vários indicadores são conforme a seguir. O retardo de transporte é definido como um tempo medido da transmissão de um pacote a partir do dispositivo de envio até a recepção do pacote no receptor. O retardo de armazenagem temporária é um tempo que um pacote leva, em uma armazenagem temporária de memória, desde sua recepção até seu consumo (como fornecer no visor no caso de vídeo). O nível de armazenagem temporária indica o número de pacotes pendentes em uma armazenagem temporária de memória no lado do receptor. A taxa de bit recebida é medida dividindo a soma dos tamanhos de pacotes recebidos em bits durante um certo período de tempo pela duração daquele período de tempo. A taxa de pacote recebida é medida dividindo o número de pacotes recebidos durante um certo período de tempo pelo período de tempo de duração. A taxa de perda de pacote é o número de pacotes perdidos durante um certo período de tempo, dividida para duração do período de tempo (usualmente dado em percentagem). Um pacote perdido é um pacote que foi transmitido porém não chegou no receptor (ou não é consumido pelo receptor). A detecção de uma perda de pacote é usualmente baseada em uma numeração de seqüência inserida no pacote do lado do remetente. Exemplos do dispositivo 10 habilitado por vídeo são um computador, um telefone fixo, um telefone móvel, um copiador, uma máquina de fax, um assistente digital pessoal, uma câmera de vídeo, uma câmera fixa, etc.
[0021] Em uma outra realização típica mostrada na Figura 3, um sistema 30 inclui o dispositivo 10 e pelo menos um dentre um provedor de vídeo com fio 32 e um provedor de vídeo sem fio 36. O provedor de vídeo com fio 32 é conectado ao dispositivo 10 via uma rede 34, que pode ser uma rede telefônica tradicional, uma rede LAN, a Internet, ou qualquer rede baseada em cabo. O provedor de vídeo sem fio 36 transmite o sinal de vídeo VS através de uma rede sem fio, que inclui pelo menos uma dentre uma estação base 38 em um sistema de comunicação, um roteador/modem sem fio em uma rede doméstica e outros provedores sem fio conhecidos, ao dispositivo 10, que pode ser, por exemplo, um telefone móvel.
[0022] Retornando agora a um processo 40 descrevendo a transmissão e controle de dados de vídeo a partir de um provedor de vídeo (por exemplo, provedor de vídeo 32) a um receptor de vídeo (por exemplo, dispositivo 10). Figura 4 mostra que, na etapa 42, o provedor de vídeo possui uma taxa alvo de transmissão pré-determinada, isto é, uma taxa alvo atual. Em uma realização típica, a taxa alvo atual é de 120.000 bits/s. Para simplicidade da discussão, o elemento 32 é chamado um provedor de vídeo e o elemento 10 é chamado um receptor de vídeo. Entretanto, é notado que ambos elementos 10 e 32 podem transmitir e receber sinais de vídeo e podem atuar como receptores/transmissores. O processo 40 descreve a transmissão e controle dos dados de vídeo em um alto nível. Detalhes relacionados ao processo 40 são discutidos mais tarde. O sinal de vídeo VS é transmitido ao receptor de vídeo à taxa alvo atual. O receptor de vídeo, de acordo com uma realização típica, mede na etapa 44 um ou mais indicadores do sinal de vídeo recebido VS. A taxa alvo de vídeo é então controlada com base nos indicadores medidos conforme discutido a seguir.
[0023] De acordo com uma realização típica, a taxa alvo de vídeo (por exemplo, taxa de bit) é controlada por uma realimentação interativa com base em indicadores mais sensíveis (m) que a PLR convencional, de tal modo que a realimentação pode reagir mais rapidamente aos congestionamentos em salvas que podem surgir na rede de transmissor. Por exemplo, se o sinal de vídeo transmite 25 quadros por segundo, a PLR é convencionalmente medida duas vezes por segundo enquanto os indicadores “m” são medidos para cada pacote recebido. Em uma outra realização típica, os indicadores são medidos pelo receptor de vídeo 10 para cada quadro. Um quadro pode ser fragmentado para n pacotes (por exemplo, um pacote por fatia ou grupo de blocos, GOB, dependendo do padrão de vídeo usado), onde n é um inteiro entre 2 e dezenas, dependendo da classe de qualidade (isto é, largura de faixa) do vídeo fonte. Em uma realização típica, pode haver um ou mais de tais indicadores mj (j = 1 para o número de indicadores). O(s) indicador(s) pode(m) ser baseado(s) em diferentes medições, como retardo de transporte, retardo de armazenagem temporária ou nível, taxa de bit recebida ou taxa de pacote, PLR, etc.
[0024] Os valores determinados dos indicadores são comparados a referências correspondentes fixas ou adaptivas rk (k = 1 para o número de referências). De acordo com uma realização típica, uma referência é pelo menos um dentre um retardo filtrado por passa baixa, um retardo filtrado por passa baixa as simetricamente ponderado e limiares de retardo baseados na adição de estimativas escaladas de retardo filtrado de passa baixa da potência do retardo filtrado de passa alta. Uma nova taxa (trnew) é determinada com base em uma função de estado recursiva q(m, r, troid) que atua nos indicadores “m”, nas referências “r” e na taxa alvo prévia troid- A nova taxa alvo é ilustrada pela seguinte equação:
Figure img0001
onde troid é a taxa alvo antiga, ré um vetor representando as referências (i'k) e ,ftéum vetor representando os indicadores (nij). A função q(.) é definida de tal modo que a nova taxa alvo está variando na direção correta e com etapas adequadas, dependendo dos valores dos indicadores m.j e referências n, como será discutido mais tarde. Em uma realização típica, a função “q” para adaptação de taxa alvo para baixo é dada por:
Figure img0002
onde as quantidades definindo as funções 1 são explicadas mais tarde.
[0025] A nova taxa alvo é calculada na etapa 46, de acordo com uma realização típica, no receptor de vídeo. Alternativamente, a nova taxa alvo pode ser calculada no provedor de vídeo, dede que o receptor de vídeo transmita os indicadores medidos ao provedor de vídeo. A nova taxa alvo calculada é realimentada na etapa 48 ao provedor de vídeo, de tal modo que o provedor de vídeo pode ajustar sua taxa de bit de vídeo de acordo com o tráfego e outras condições presentes na rede. Um exemplo de uma outra condição é o desvanecimento em um acesso rádio, que depende do movimento do cliente móvel (em adição ao tráfego cruzado). Se o tráfego na rede é baixo, a taxa de bit pode ser ajustada para cima pelo provedor de vídeo e se o tráfego na rede é alto, a taxa de bit pode ser ajustada para baixo como será discutido mais tarde. A realimentação é entendida em uma realização típica para significar sinalização da nova taxa alvo, do receptor de vídeo para o provedor de vídeo.
[0026] Dependendo de qual informação é transmitida na malha de realimentação, a adaptação de taxa alvo pode ser baseada na medição ou baseada em requisição. Se o receptor de vídeo envia os indicadores medidos ao provedor de vídeo, que então calcula a nova taxa alvo, o processo é chamado de adaptação baseada em medição. Alternativamente, se o receptor conhece a taxa alvo usada pelo remetente, então o receptor calcula a nova taxa alvo e a envia ao remetente como uma requisição. Esta é chamada adaptação baseada em requisição. A segunda abordagem é mais eficiente em termos de sinalização de sobrecarga que a primeira abordagem. As realizações típicas deste pedido são aplicáveis a ambos os processos. Entretanto, para simplicidade da discussão, a terminologia do processo baseado em requisição é usada, e exemplos relacionados ao processo baseado em requisição são apresentados a seguir.
[0027] Uma desvantagem da adaptação de taxa alvo baseada em medição é a necessidade de um acordo comum entre vendedores (produtores do provedor de vídeo, receptor de vídeo e processos associados) sobre quais parâmetros medir e como calcular a taxa alvo. A adaptação de taxa alvo baseada em requisição é mais flexível porque este método não requer acordos entre vendedores e não requer capacidade de transmissão estendida. Também, a taxa alvo baseada em requisição permite que o receptor use mais indicadores e referências adaptivas para a adaptação, do que a adaptação baseada em medição. Neste sentido, a adaptação baseada em medição da taxa alvo é limitada em termos do número de indicadores e referências, porque um grande número de indicadores e referências resulta em grande sobrecarga de transmissão, o que é difícil devido à disponibilidade de largura de faixa limitada.
[0028] Quando o provedor de vídeo recebe, na etapa 48, a nova taxa alvo calculada pelo receptor de vídeo, o provedor de vídeo ajusta, na etapa 50, sua taxa alvo atual e continua a transmitir sinais de vídeo na nova taxa alvo na etapa 52. Uma vantagem do processo discutido acima em comparação com processos tradicionais que usam PLR para determinar a nova taxa alvo, é que os indicadores usados pelo processo 40 são sensíveis no tempo a um pico de congestionamentos por salvas, diferentemente da PLR, conforme discutido acima.
[0029] Entretanto, se a taxa alvo real varia e o processo de variação de taxa dispara uma determinação da nova taxa alvo freqüentemente demais, a transmissão do sinal de vídeo pode ser negativamente afetada devido à quantidade de medições e cálculos tendo lugar no receptor de vídeo. Para evitar mudanças de taxas alvo freqüentes e oscilações, certas condições de disparo podem ser usadas em uma realização típica, isto é, uma mudança na taxa alvo é efetuada somente se certos indicadores caem abaixo de uma condição limite pré-determinada. Diferentes condições de disparo podem ser usadas para aumentar ou diminuir a taxa alvo. Em outras palavras, para aumentar a taxa alvo, uma condição (condup) para variar para cima a taxa alvo atual que é diferente de uma condição (conddown) para variar para baixo a taxa alvo atual. As condições podem ser, em uma realização típica, baseadas em funções Booleanas dos indicadores medidos e referências armazenadas. Opcionalmente, as condições podem incluir algumas condições de temporização, por exemplo, não mais freqüentemente do que uma vez no período do protocolo de controle em tempo real regular (RTCP) ou não antes da requisição prévia ou medição ter sido respondida por uma notificação, etc. Então, nesta realização típica, uma nova taxa alvo é calculada se qualquer uma destas condições é verdadeira.
[0030] De acordo com uma outra realização típica, a taxa alvo pode ser limitada dentro de uma certa faixa. Então, a taxa alvo não tem permissão para aumentar acima de um certo valor máximo trmax ou diminuir abaixo de um limite inferior trmjm. Uma outra alternativa é suspender o componente de vídeo, se a taxa alvo é requisitada para ir abaixo de tr^m- A faixa pode ser acordada por sinalização de controle (como INVITE e REINVITE da sinalização SIP/SDP, ver por exemplo, IETF RFC 4566 (2006): “SDP: Session Description Protocol”, cujo conteúdo inteiro é aqui incorporado por referência).
[0031] Nas realizações típicas a seguir, o processo que ajusta a taxa atual é descrito em mais detalhe. Para fins de exemplo, uma lista completa de instruções a serem executadas por um processador para calcular a nova taxa alvo para ajustar a taxa corrente é apresentada abaixo. Vários ambientes de linguagem de computador podem ser usados para prover as instruções para o processador. Em uma outra realização, circuitos elétricos podem ser programados para executar as instruções. As instruções discutidas a seguir são aplicáveis a cada quadro de vídeo recebido “i”.
[0032] De acordo com uma realização típica, a adaptação de taxa alvo de vídeo é obtida com base no uso de uma estimativa de retardo de transporte di, onde “i” é o índice de quadro e di é o indicador. Em uma rede baseada em comutação de pacote, o retardo de transporte é a quantidade de tempo requerida para inserir todos os bits do pacote no fio. Em outras palavras, este é o retardo causado pela taxa de dados do enlace. O retardo de transporte pode ser uma função da extensão do pacote e não nada a ver com a distância entre os dois nós. O retardo é proporcional à extensão do pacote em bits. O retardo é também produzido pelo retardo de enfileiramento nas armazenagens temporárias dos nós de rede através dos quais o pacote viaja. Isto é uma causa da variação do retardo de transporte causada pelo tráfego cruzado e também uma razão para congestionamento. Isto pode ser melhorado requisitando aos remetentes (competidores) para reduzir sua taxa de bit de envio e conseqüentemente tornar os tamanhos de pacotes menores. Opcionalmente, a adaptação de taxa alvo de vídeo pode usar uma perda de pacote pin como o indicador, em adição ao indicador di. O indicador de perda de pacote pin é determinado ao longo do intervalo de tempo entre duas mensagens consecutivas de Remetente RTCP ou Relatórios de Receptor (SR/RR) (de acordo com IETF RFC 3550).
[0033] Vários indicadores de retardo são determinados pelas equações:
Figure img0003
onde M é o número de quadros completos recebidos mais recentemente através dos quais os indicadores são determinados e NÍJ é o número de pacotes pertencentes ao quadro i-j, e “mediana” e “max” são as funções matemáticas correspondentes a calcular uma mediana e um máximo, respectivamente, de uma coleção de valores correspondentes ao retardo de transporte d’i do quadro, que é estimado como uma média sobre os retardos de transporte di de pacotes individuais por quadro (se houver muitos). Em uma realização típica, M pode ser 3.
[0034] Um retardo de transporte único di de um pacote, medido em ms, é determinado pela seguinte equação:
Figure img0004
onde taiT.j é o tempo de chegada do pacote i, TSi é o valor de marcação de tempo de Protocolo de Transporte em Tempo Real (RTP) do pacote “i” em períodos de relógio de 90 kHz, e clkSkew é um valor desconhecido representando o desvio do relógio entre a fonte e o destino. O RTP define um formato de pacote padronizado para fornecer áudio e vídeo através da Internet, que foi desenvolvido pelo Grupo de Trabalho de Transporte de Áudio-Vídeo da Força Tarefa de Engenharia da Internet, ver RFC 3550. As funções que dependem de di nas instruções listadas abaixo, são insensíveis ao desvio do relógio, removendo a necessidade de demandar uma sincronização precisa entre o tempo do remetente e o tempo do receptor. Em uma realização típica, diferenças de tempo de curso de repouso e estacionário entre o provedor de vídeo e o receptor de vídeo podem ser toleradas.
[0035] Uma variável minMaxi é definida como o menor máximo e maxMaxii o maior máximo através de todas as janelas deslizantes definidas no conjunto de equações (2), uma vez que a adaptação de taxa prévia e estas variáveis são dadas pelas equações:
Figure img0005
onde maxii-j é definido no conjunto de equações (3) e Ii é o número de quadros desde a adaptação da taxa anterior.
[0036] Em uma realização típica, para determinar uma estimativa de um nível mínimo atual do retardo de transporte (ou um assim chamado retardo fixo, fixDeli) o sinal medi definido no conjunto de equações (2) é filtrado por um filtro passa baixa ponderado as simetricamente definido no conjunto de equações (6):
Figure img0006
onde FIXDEL_MAX_N é uma constante em linha dada (FIXDEL_MAX_N = 2000 em uma realização típica).
[0037] Para obter uma estimativa de um nível de variação estatística do retardo na entrega de dados em uma rede o valor absoluto dos retardos de quadro filtrados por passa alta d) definidos no conjunto de equação (3), são calculados pela equação (7) conforme segue:
Figure img0007
[0038] O clksiew é cancelado ao calcular /z;.
[0039] O sinal filtrado passa alta Zz, é filtrado passa baixa pelo conjunto de equações (8):
Figure img0008
onde IARRJIT_MAX_N é uma dada constante em Unha (IARRJIT_MAX_N = 1000 em uma realização típica).
[0040] Os limites lowThresholdi e highThresholdi são definidos pelo conjunto de equações (9):
Figure img0009
onde iarrJiti é definido no conjunto de equações (8) e fixDeli no conjunto de equações (2). LOW_COEF, HIGH_COEF, MIM-LOW-MARGIN, MIM_HIGH_MARGIN e MAX_HIGH_MARGIN são parâmetros em linha. Em uma realização típica, os seguintes valores são usados: LOW-COEF = 1,2, HIGH-COEF = 3,5, MIM_LOW_MARGIN = 5 ms, MIM_HIGH_MARGIN = 20 ms e MAX-HIGH-MARGIN = 200 ms.
[0041] O processo de adaptação de taxa alvo é habilitado ou desabilitado por certas variáveis Booleanas condup e conddown, que podem ser usadas para embutir as restrições de temporização, como quando uma nova requisição de taxa alvo é primeiramente permitida após a anterior. De acordo com uma realização típica, as condições de acordo com o conjunto de equações (10) são usadas:
Figure img0010
onde tnow = tempo atual, treguiarRTCP = próximo tempo programado para enviar um RTCP SR/RR regular (de acordo com RFC 3550 do IETF), earlySent = variável Booleana que indica se a última mensagem RTCP transmitida foi cedo (definida no RFC 4585 do IETF) e rateNotified = variável Booleana que indica se uma notificação para uma requisição de taxa alvo foi recebida pelo receptor de vídeo.
[0042] Um conjunto de instruções de disparo de requisição de taxa alvo completo, de acordo com uma realização típica é apresentado no pseudo código a seguir. Entretanto, outras variantes do conjunto de instruções podem ser usadas como seria entendido pelos especialistas na técnica. O conjunto de instruções inclui:
Figure img0011
Figure img0012
[0043] Algumas das variáveis das instruções acima são definidas nas equações (1) - (8) enquanto o restante das variáveis é explicado a seguir. Uma variável estática é considerada a seguir como uma variável que lembra seu valor atual até o próximo instante. tprevRTCP é um tempo prévio programado para enviar uma mensagem RTCP SR/RR regular (variável estática); regularRTCPinterval é um intervalo entre duas mensagens RTCP SR/RR regulares, isto é, um valor randômico em torno de alguma média nominal (500 ms em uma realização típica); targetRateOld é o último alvo notificado e em uma realização típica é suposto que esta taxa alvo é correntemente usada pelo remetente do vídeo; MBR é uma taxa de bit alvo máxima (valor dado constante, 128.000 bps na realização típica); GBR é uma taxa de bit alvo garantida (valor alvo constante, 60.000 bps na realização típica); exactRate é o valor exato da taxa de bit alvo atual, este é ajustado igual a uma taxa alvo notificada, quando recebida a partir do remetente do vídeo (variável estática); maxUpSlope é um valor atual para pup (variável estática); upSlopeStep é um valor atual para um incremento pelo qual maxUpSlope é incrementado, quando a taxa alvo é modificada para cima (variável estática); STEP_INC é uma etapa pela qual upSlopeStep é incrementado quando a taxa alvo é modificada para cima (na realização típica esta variável é dada por 1 s e requer escalamento pelo intervalo entre mensagens RTCP SR/RR regulares (parâmetro em linha de 0,00001 na realização típica); MAX_STEP é um valor máximo para upSlopeStep, é dado por 1 s e requer, na realização típica, um escalamento pelo intervalo entre mensagens RTCP SR/RR regulares (parâmetro em linha de 0,006 na realização típica); MAX_UP é um limite de maxUpSlope (parâmetro em linha de 1,1 na realização típica); MIN_UP é um limite inferior de maxUpSlope (parâmetro em linha de 1,0001 n realização típica); PLOSS_WEIGHT é um fator de ponderação de perdas de pacote (parâmetro em linha de 0,1 na realização típica); PDOWN_MAX é um parâmetro em linha (1,0 na realização típica); e PDOWNJSLOPE é um parâmetro em linha (0,5 na realização típica).
[0044] Na realização típica discutida acima, a adaptação para baixo se comporta diferentemente da adaptação para cima. A taxa alvo tem permissão para se mover rapidamente para baixo inicialmente (ataque rápido) e depois disso o tamanho de etapa máximo é reduzido proporcionalmente à relação da diferença entre a taxa atual e GBR até a (constante pré ajustada) diferença entre MBR e GBR. Então, a taxa alvo se aproxima as sinto ticamente de GBR enquanto a condição para diminuir a taxa alvo prevalece. Também, RTCP anterior é permitido em uma realização típica somente para adaptação para baixo. A taxa se recupera com uma velocidade mais lenta e adaptação para cima é efetuada em uma realização típica, somente quando pacotes RTCP SR/RR regulares estão para serem enviados. A proporção (pup) pela qual a taxa alvo é aumentada é ajustada para seu mínimo (MIN_UP) toda vez que a taxa alvo é adaptada para baixo. Depois disso, pup é quadraticamente aumentada com uma aceleração constante (STEP_INC, que é dado por 1 s) toda vez que a taxa alvo é aumentada. Então, a recuperação acelera quando a perturbação persistente termina. A velocidade crescente upSlopeStep pela qual pup (ou igualmente a variável estática mαxUpSlope) é aumentada é também limitada para cima em um certo valor (MAX_STEP que é dado por 1 s). Também, em uma realização típica, não é permitido que pup aumente acima de um certo limite superior (MAX_UP).
[0045] Nestas realizações típicas, os valores para os parâmetros são selecionados de tal modo que a mudança para baixo do valor de taxa alvo pode ser pelo menos 50% da faixa de adaptação MBR-GBR quando a taxa alvo atual é MBR. A variação para cima não pode ser mais de 10% da taxa alvo em uma realização típica. Também um certo tempo de estabelecimento é usado no início de uma sessão para permitir que os transientes iniciais de referências adaptivas terminem. Em uma realização típica, o tempo de estabelecimento foi ajustado para 1 s.
[0046] Em uma realização típica, o processo para ajustar a taxa alvo do sinal de vídeo é insensível a desvio do relógio. Nesta realização, o processo foi executado com um valor de clkSkew correspondendo a um clkSkew de 100.000.000 entre a fonte e o destino do vídeo. Os resultados do processo são (exatamente em bits) iguais a um valor clkSkew correspondendo a um clkskew de 0. Adicionalmente, as perdas de pacotes são levadas em conta, de tal modo que a taxa é adaptada para baixo com uma quantidade extra de cerca de 10% da faixa de taxa de bit restante entre a taxa alvo atual e GBR por pacote perdido, se os pacotes foram perdidos durante o intervalo de tempo entre os dois últimos pacotes RTCP SR/RR regulares.
[0047] Um exemplo ilustrativo específico é discutido a seguir. Embora ilustrativo, este exemplo não é destinado a limitar as realizações típicas ou a sugerir que outros valores, indicadores e funções não sejam possíveis. Uma meta da adaptação de taxa alvo de vídeo é reduzir a taxa alvo em muitas etapas, quando inicia um congestionamento, no sentido de evitar ou minimizar a quantidade de perdas de pacote devido a sobrecargas de armazenagem temporária ou interrupções e para evitar uma alta variação de retardo (isto é, variação estatística do retardo na entrega de dados em uma rede - jitter).A recuperação para cima da taxa alvo é obtida a uma velocidade mais lenta do que a adaptação para baixo, no sentido de detectar tão cedo quanto possível se o congestionamento ainda está prevalecendo e retornar a taxa alvo de volta para baixo, se necessário. Este processo é ilustrado na Figura 5, na qual a taxa alvo cai com uma alta velocidade em tl até uma taxa baixa e recupera entre tl e t2 a uma taxa mais lenta. O aumento pode ser de acordo com esta realização, baseado em uma forma contínua e monotônica, porque o congestionamento está ao longo de um tempo t3 = 50 s conforme mostrado na Figura 5. Adicionalmente, a Figura 5 mostra que a recuperação acelera entre t3 e t4 e começando com t4, a taxa alvo está de volta à taxa alvo original, isto é, antes do congestionamento ter ocorrido. Então, de acordo com uma realização típica, a recuperação da taxa alvo entre tl e t4 é adaptiva, dependendo da severidade do congestionamento. Em outras palavras, o processo ajusta para cima a taxa alvo com um degrau que varia no tempo. Nesta realização típica, o degrau para ajustar para cima a taxa alvo é diferente para cada um dos intervalos de tempo tl-t2, t2-3 e t3-t4. Uma ou mais etapas podem ser usadas para ajustar para cima a taxa alvo.
[0048] A seguir, a eficiência dos métodos e dispositivos baseados nas realizações típicas discutidas acima é comparada com aquela dos métodos tradicionais. Neste sentido, a Figura 6, similar à Figura 1, mostra os perfis de retardo sem adaptação de taxa alvo, quando pacotes que estavam pendentes mais dos que um retardo de corte de 400 ms no percurso (ou nos armazenamentos) são perdidos. Este retardo de corte causa perdas de pacote (PLR = 3,2%) durante o período de congestionamento. Ambas as Figuras 1 e 6 mostram que os picos de retardo estão presentes por cerca de 40 segundos, entre 10 e 50 segundos e o retardo de transporte é da ordem de 300 a 700 ms para estes casos.
[0049] Figura 7 mostra os retardos de transporte de vídeo quando a adaptação de taxa alvo discutida nas realizações típicas acima é aplicada. Os armazenadores são considerados finitos e também não estão tendo lugar perdas de pacotes. O novo processo de adaptação de taxa torna os retardos de transporte menores do que para um sistema sem a adaptação de taxa alvo ilustrada nas Figuras 1 e 6. Os retardos de transporte são da ordem de 150 a 300 ms para este cenário.
[0050] Figura 8 mostra funções de distribuição cumulativas complementares (CCDF) dos retardos para os três cenários mostrados nas Figuras 1, 6 e 7. O eixo y é uma probabilidade de um evento de que um retardo é maior que o valor no eixo x. Figura 8 mostra que 99% da quantidade (isto é, pontos de cruzamentos das curvas com a linha horizontal y = 0,01) do retardo de transporte e2e (de extremidade a extremidade) é menor com uma adaptação de taxa de aproximadamente 250 ms e maior sem a adaptação de taxa com armazenadores infinitos, aproximadamente 750 ms. Então, de acordo com esta realização típica com a taxa de adaptação, 99% dos pacotes são menos retardados que 250 ms.
[0051] Figura 9 mostra os retardos de transporte medidos juntamente com limites alto baixo para um método baseado nas realizações típicas. Os dois limites definem a faixa na qual o retardo de transporte é desejável de ser mantido. Figura 9 também mostra a estimativa de retardo fixo. O sistema tenta manter o retardo de transporte e2e abaixo da linha de limite alto, reduzindo a taxa alvo se necessário, e determina a taxa alvo para aumentar todas as vezes que o retardo estiver com alta probabilidade abaixo da linha de limite baixo, até que a taxa alvo atinja MBR.
[0052] Figura 10 mostra a Relação de Sinal de Pico para Ruído (PSNR) através de uma faixa de tempo de 0 a 70 s. PSNR é um método alvo entendido pelos especialistas na técnica para medir a qualidade perceptual de um sinal de vídeo passando através de um sistema, comparando o sinal de vídeo com o mesmo sinal de vídeo que não passou através do sistema. Figura 11 mostra as funções de distribuição cumulativas (CDF) das PSNRs para os três cenários discutidos acima. O eixo y é uma probabilidade de um evento de que a PSNR seja menor que o valor do eixo x. Figura 10 mostra que, sem a adaptação de taxa, a quantidade 99% de PSNR é de aproximadamente 18 dB e com a adaptação de taxa alvo é de aproximadamente 31 dB. Quanto mais alta a PSNR, melhor a qualidade do sistema. Então, para o caso com a adaptação de taxa, a PSNR de 99% dos quadros é maior que 31 dB. Codec de vídeo H.264 foi usado para gerar os dados mostrados nas Figura 10 e 11.
[0053] De acordo com uma realização típica, etapas de um método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo são mostradas na Figura 12.0 método inclui uma etapa 120 para receber o sinal de vídeo no receptor de vídeo, uma etapa 122 para medição no receptor de vídeo de pelo menos um indicador do sinal de vídeo recebido, uma etapa 124 de calcular, no receptor de vídeo, uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido, o pelo menos um indicador e pelo menos uma referência, e uma etapa 126 de transmitir a partir do receptor de vídeo, a nova taxa alvo ao provedor de vídeo, para adaptar a taxa alvo atual.
[0054] De acordo com uma outra realização típica, etapas de um método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido a partir de um provedor de vídeo para um receptor de vídeo, são mostradas na Figura 13. O método inclui uma etapa 130 de transmitir o sinal de vídeo à taxa alvo atual a partir do provedor de vídeo, uma etapa 132 de receber no provedor de vídeo pelo menos um indicador do sinal de vídeo recebido pelo receptor de vídeo, uma etapa 134 de calcular, pelo provedor de vídeo, uma nova taxa alvo com base na taxa alvo atual do sinal de vídeo transmitido, o pelo menos um indicador e pelo menos uma referência, e uma etapa 136 de adaptar, no provedor de vídeo, a taxa alvo atual à nova taxa alvo.
[0055] Os métodos e processos discutidos acima podem ser implementados, de acordo com uma realização típica, em um sistema 30 conforme mostrado na Figura 14a. o sistema pode incluir o remetente do vídeo 32 que envia, através da rede 34, dados de vídeo ao receptor de vídeo 10. Um codificador de vídeo e unidade de controle de taxa 140 do remetente do vídeo 32 envia dados de vídeo a uma taxa alvo ao receptor de vídeo 10. Os dados de vídeo são recebidos pela unidade de decodificador de vídeo 142 do receptor de vídeo 10, que decodifica os dados de vídeo. Uma unidade de medição 144 mede certos indicadores e, com base nas medições, uma unidade de adaptação de taxa alvo 146 calcula a nova taxa alvo. A nova taxa alvo é realimentada ao remetente do vídeo 32 via rede 34 e o codificador de vídeo e unidade de controle de taxa 140 do remetente do vídeo 32 ajusta sua taxa de transmissão com base na realimentação a partir do receptor de vídeo 10. Figura 14a mostra somente uma realimentação de uma via, porém as realizações acima podem ser implementadas de tal modo que ambos remetente do vídeo e receptor de vídeo provêem realimentação um ao outro, de tal modo que cada dispositivo adapta sua própria taxa de transmissão. Figura 14b mostra uma realização típica na qual a adaptação de taxa alvo é efetuada no remetente de vídeo 30, isto é, a adaptação de taxa alvo 146 está presente no remetente de vídeo 30 que corresponde a adaptação de taxa alvo baseado em medição.
[0056] Figura 15 é um diagrama em blocos indicando como a taxa alvo é calculada no sistema 30 mostrado na Figura 14a. Na etapa 150, o receptor aguarda um próximo quadro chegar do remetente. Na etapa 152, um retardo fixo é estimado quando o próximo quadro tiver chegado. Na etapa 154, um nível de variação estatística do retardo na entrega de dados em rede - jitter inter chegada é estimado, conforme discutido acima. Na etapa 156, os limites baixo e alto para a taxa alvo são calculados. Na etapa 158, a adaptação de taxa alvo é permitida, se uma condição pré-determinada for verdadeira. Se a condição pré-determinada é verdadeira, o processo avança para a etapa 160, na qual é determinado se a adaptação é para baixo. Na etapa 158, se a condição pré-determinada não é verdadeira, o processo retorna à etapa 150. Na etapa 160, se a adaptação da taxa alvo não é para baixo, o processo avança para a etapa 162. Se a adaptação é para baixo, o processo avança para a etapa 164, onde o novo alvo é calculado para baixo e é provida realimentação ao remetente. Então, o processo avança para a etapa 150. Na etapa 162, o receptor determina se a adaptação de taxa alvo é para cima. Se a adaptação é para cima, o processo continua para a etapa 166, onde a nota taxa alvo é calculada para cima e realimentada ao remetente. Então, o processo avança para a etapa 150. Se a adaptação na é para cima, o processo retorna à etapa 150 e nenhuma realimentação é provida.
[0057] As realizações típicas descritas provêem um dispositivo, um sistema, um método e um produto de programa de computador para trocar sinais de vídeo com um outro dispositivo. Deveria ser entendido que esta descrição não é destinada a limitar a invenção. Ao contrário, as realizações típicas são destinadas a cobrir alternativas, modificações e equivalentes, que estão incluídas no espírito e escopo da invenção, conforme definido pelas reivindicações anexas. Adicionalmente, na descrição detalhada das realizações típicas, numerosos detalhes específicos são relatados no sentido de prover um entendimento da invenção reivindicada. Entretanto, um especialista na técnica entenderia que várias realizações podem ser praticadas sem tais detalhes específicos.
[0058] Como também será verificado por um especialista na técnica, as realizações típicas podem ser realizadas em um dispositivo de comunicação sem fio, uma rede de telecomunicação, como um método ou em um produto de programa de computador. Conseqüentemente, as realizações típicas podem tomar a forma de uma realização inteiramente em hardware ou uma realização combinando aspectos de hardware e software. Adicionalmente, as realizações típicas podem tomar a forma de um produto de programa de computador armazenado em um meio de armazenagem legível por computador possuindo instruções legíveis por computador realizadas no meio. Qualquer meio legível por computador adequado pode ser utilizado incluindo discos rígidos, CD- ROM, DVD (Disco Versátil Digital), dispositivos de armazenagem óptica ou dispositivos de armazenagem magnética tal como um disco flop ou fita magnética. Outros exemplos não limitantes de meios legíveis por computador incluem memórias do tipo flash ou outras memórias conhecidas.
[0059] As presentes realizações típicas podem ser implementadas em um terminal de usuário, uma estação base, e geralmente uma rede de comunicação sem fio ou sistema compreendendo ambos terminal de usuário e estação base. As realizações típicas podem também ser implementadas em um circuito integrado específico da aplicação (ASIC) ou um processador de sinal digital. Processadores adequados incluem, a título de exemplo, um processador de finalidade geral, um processador de finalidade especial, um processador convencional, um processador de sinal digital (DSP), diversos microprocessadores, um ou mais microprocessadores em associação com um núcleo DSP, um controlador, um microcontrolador, Circuitos Integrados Específicos de Aplicação (ASICs), circuitos de Arranjos de Porta Programáveis no Campo (FPGAs), qualquer outro tipo de circuito integrado (IC), e/ou uma máquina de estado. Um processador em associação com software pode ser usado para implementar um controlador para uso no provedor de vídeo, no receptor de vídeo ou qualquer computador principal. O receptor de vídeo pode ser usado em conjunto com módulos, implementados em hardware e/ou software, tal como uma câmera, um módulo de câmera de vídeo, um videofone, um telefone com microfone e alto-falante, um dispositivo de vibração, um alto-falante, um microfone, um transceptor de televisão, um conjunto de cabeça “hands free”, um teclado, um módulo Bluetooth, uma unidade rádio de freqüência modulada (FM), uma unidade de visualização de visor de cristal líquido (LCD), um unidade de visualização de diodo emissor de luz orgânico (OLED), um reprodutor de música digital, um reprodutor de mídia, um módulo reprodutor de videogame, um navegador da Internet e/ou qualquer módulo de rede de área local sem fio (WLAN).
[0060] Embora as características e elementos das presentes realizações típicas sejam descritos nas realizações em combinações particulares, cada característica ou elemento pode ser usado isoladamente sem as outras características e elementos das realizações, ou em várias combinações, com ou sem outras características e elementos aqui descrito. Os métodos ou fluxogramas providos no presente pedido podem ser implementados em um programa de computador, software ou firmware tangivelmente realizado em um meio de armazenagem legível por computador, para execução por um computador de finalidade geral ou um processador.

Claims (15)

1. Método para adaptar uma taxa alvo atual de um sinal de vídeo (VS) transmitido de um provedor de vídeo (32) para um receptor de vídeo (10), caracterizadopelo fato de compreender: receber (120) o sinal de vídeo (VS) no receptor de vídeo (10); medir (122), no receptor de vídeo (10), pelo menos um indicador do sinal de vídeo recebido (VS), o pelo menos um indicador sendo baseado em um retardo de transporte; calcular (124), no receptor de vídeo (10), uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido e no pelo menos um indicador, que é comparado a pelo menos uma referência fixa ou adaptativa correspondendo ao pelo menos um indicador, e em que a pelo menos uma referência fixa ou adaptativa correspondendo ao pelo menos um indicador é um segundo limite baixo e alto para o atraso de transporte da nova taxa alvo; e calcular compreende, quando o novo quadro tiver chegado, estimar um nível mínimo atual do atraso de transporte, estimar um nível de variação estatística do retardo na entrega de dados em rede entre chegadas, e determinar o limite baixo e o alto para o atraso de transporte e o nível de variação estatística do retardo na entrega de dados em rede, com base no nível mínimo atual de atraso de transporte e no nível de variação estatística do retardo na entrega de dados em rede entre chegadas, e transmitir (126) a partir do receptor de vídeo (10) a nova taxa alvo para o provedor de vídeo (32) adaptar a taxa alvo atual.
2. Método de acordo com a reivindicação 1, caracterizadopelo fato de compreender adicionalmente: ajustar para cima a taxa alvo atual com um degrau que varia no tempo.
3. Método de acordo com a reivindicação 1, caracterizadopelo fato de compreender adicionalmente: corrigir a nova taxa alvo para estar dentro de uma faixa pré- determinada, se a nova faixa alvo calculada for maior que um primeiro limite pré-determinado ou menor que um segundo limite pré-determinado.
4. Método de acordo com a reivindicação 1, caracterizadopelo fato de compreender adicionalmente: calcular a nova taxa alvo somente se uma condição pré- determinada é disparada.
5. Método de acordo com a reivindicação 4, caracterizadopelo fato de que a condição pré-determinada compreende pelo menos uma dentre: uma primeira condição que indica se a taxa alvo atual é menor que uma taxa alvo baixa pré-determinada; uma segunda condição que indica se a taxa alvo atual é maior que uma taxa alvo alta pré-determinada; e uma terceira condição que evita um cálculo da nova taxa alvo se um intervalo de tempo entre um cálculo prévio da nova taxa alvo e um cálculo atual da nova taxa alvo é menor que um intervalo de tempo pré- determinado.
6. Método de acordo com a reivindicação 1, caracterizadopelo fato de que a pelo menos uma referência é uma quantidade vetorial que inclui diversos componentes de referência.
7. Método de acordo com a reivindicação 1, caracterizadopelo fato de que o pelo menos um indicador é uma quantidade vetorial que inclui diversos componentes de indicador.
8. Método de acordo com a reivindicação 1, caracterizadopelo fato de que o cálculo compreende adicionalmente: ajustar para baixo a taxa alvo atual com um degrau maior do que a justar para cima a taxa alvo atual.
9. Método de acordo com a reivindicação 1, caracterizadopelo fato de compreender adicionalmente: medir no receptor de video a taxa de perda de pacote do sinal de vídeo recebido; e a etapa de calcular incluindo calcular a nova taxa alvo com base na taxa alvo atual, o pelo menos um indicador, a taxa de perda de pacote e a pelo menos uma referência.
10. Dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo (32), caracterizado pelo fato de compreender: pelo menos uma porta de entrada/saída configurada para receber o sinal de vídeo; um processador conectado à pelo menos uma porta de entrada/saída e configurado para determinar pelo menos um indicador a partir do sinal de vídeo recebido, onde o pelo menos um indicador é baseado em um retardo de transporte, calcular, uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido e no pelo menos um indicador, que é comparado a pelo menos uma referência fixa ou adaptativa correspondendo ao pelo menos um indicador; e em que a pelo menos uma referência fixa ou adaptativa correspondendo ao pelo menos um indicador é um segundo limite baixo e alto para o atraso de transporte da nova taxa alvo; e calcular compreende estimar um nível de variação estatística do retardo na entrega de dados em rede entre chegadas quando um próximo quadro tiver chegado, estimar um nível mínimo atual do atraso de transporte, e determinar o limite baixo e o alto para o atraso de transporte e o nível de variação estatística do retardo na entrega de dados em rede com base no nível mínio atual de atraso de transporte e no nível de variação estatística do retardo na entrega de dados em rede entre chegadas, e a porta de entrada/saída é adicionalmente configurada para transmitir a nova taxa alvo ao provedor de vídeo, de tal modo que o provedor de vídeo adapta a taxa atual à nova taxa alvo.
11. Dispositivo de acordo com a reivindicação 10, caracterizado pelo fato de que o processador é adicionalmente configurado para: ajustar para a taxa alvo atual com um degrau que varia no tempo.
12. Dispositivo de acordo com a reivindicação 10, caracterizado pelo fato de que o processador é adicionalmente configurado para: ajustar para baixo a taxa alvo atual maior que ajustar para cima a taxa alvo atual.
13. Dispositivo de acordo com a reivindicação 10, caracterizado pelo fato de que o processador é configurado para medir a taxa de perda de pacote do sinal de vídeo recebido, e para calcular a nova taxa alvo com base na taxa alvo atual, no pelo menos um indicador, na taxa de perda de pacote e na pelo menos uma referência.
14. Dispositivo de acordo com a reivindicação 10, caracterizado pelo fato de que o dispositivo é um receptor de vídeo incluindo um dentre um telefone, computador, assistente digital pessoal, aparelho de televisão, conversor set-top box e uma câmera.
15. Meio legível por computador armazenando instruções executáveis por computador, caracterizado pelo fato de que, as instruções, quando executadas por um processador (18) fazem com que um receptor de vídeo (10) incluindo o processador (18) calcule uma nova taxa alvo de um sinal de vídeo (VS), as instruções compreendendo: receber (120) o sinal de vídeo (VS) no receptor de vídeo (10); medir (122), no receptor de vídeo (10), pelo menos um indicador do sinal de vídeo recebido (VS), o pelo menos um indicador sendo baseado em um retardo de transporte; calcular (124), no receptor de vídeo (10), uma nova taxa alvo baseada na taxa alvo atual do sinal de vídeo recebido e no pelo menos um indicador, que é comparado a pelo menos uma referência fixa ou adaptativa correspondendo ao pelo menos um indicador, e em que a pelo menos uma referência fixa ou adaptativa correspondendo ao pelo menos um indicador é um segundo limite baixo e alto para o atraso de transporte da nova taxa alvo; e calcular compreende, quando o novo quadro tiver chegado, estimar um nível mínimo atual do atraso de transporte, estimar um nível de variação estatística do retardo na entrega de dados em rede entre chegadas, e determinar o limite baixo e o alto para o atraso de transporte e o nível de variação estatística do retardo na entrega de dados em rede, com base no nível mínimo atual de atraso de transporte e no nível de variação estatística do retardo na entrega de dados em rede entre chegadas, e transmitir (126) a partir do receptor de vídeo (10) a nova taxa alvo para o provedor de vídeo (32) adaptar a taxa alvo atual.
BRPI0822489-7A 2008-03-12 2008-03-12 Método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo, dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo, e, meio legível por computador BRPI0822489B1 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2008/050275 WO2009113924A1 (en) 2008-03-12 2008-03-12 Device and method for adaptation of target rate of video signals

Publications (2)

Publication Number Publication Date
BRPI0822489A2 BRPI0822489A2 (pt) 2015-06-16
BRPI0822489B1 true BRPI0822489B1 (pt) 2020-10-06

Family

ID=41065457

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0822489-7A BRPI0822489B1 (pt) 2008-03-12 2008-03-12 Método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo, dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo, e, meio legível por computador

Country Status (5)

Country Link
US (1) US8588071B2 (pt)
EP (1) EP2255535B1 (pt)
CN (1) CN101971629B (pt)
BR (1) BRPI0822489B1 (pt)
WO (1) WO2009113924A1 (pt)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8775665B2 (en) * 2009-02-09 2014-07-08 Citrix Systems, Inc. Method for controlling download rate of real-time streaming as needed by media player
FR2948249B1 (fr) * 2009-07-20 2011-09-23 Canon Kk Procedes et dispositifs d'estimation d'un niveau d'utilisation d'un reseau de communication et d'adaptation d'un niveau d'abonnements a des groupes multipoints
JP5506362B2 (ja) * 2009-12-15 2014-05-28 キヤノン株式会社 送信装置、送信方法
GB201003206D0 (en) * 2010-02-25 2010-04-14 Skype Ltd Method of estimating congestion
EP2586235B1 (en) * 2010-06-22 2018-10-10 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for detecting congestion in a communications network
US8863204B2 (en) * 2010-12-20 2014-10-14 Comcast Cable Communications, Llc Cache management in a video content distribution network
US9374406B2 (en) * 2012-02-27 2016-06-21 Qualcomm Incorporated Dash client and receiver with a download rate estimator
US9503490B2 (en) 2012-02-27 2016-11-22 Qualcomm Incorporated Dash client and receiver with buffer water-level decision-making
CN102752212B (zh) * 2012-07-12 2015-08-19 苏州阔地网络科技有限公司 一种传输速率控制方法
CN102945220B (zh) * 2012-10-17 2015-08-12 无锡江南计算技术研究所 基于序号的多队列保序方法
CN105099795A (zh) 2014-04-15 2015-11-25 杜比实验室特许公司 抖动缓冲器水平估计
US20160112825A1 (en) * 2014-10-15 2016-04-21 Qualcomm Incorporated Rendering A Media Stream By Wireless Devices Sharing Device Identifiers And Encryption Keys
JP6439414B2 (ja) * 2014-12-01 2018-12-19 富士通株式会社 通信装置
US10492085B2 (en) * 2016-01-15 2019-11-26 Qualcomm Incorporated Real-time transport protocol congestion control techniques in video telephony
CN106210926B (zh) * 2016-07-11 2018-12-04 天津大学 基于模糊控制的视频质量自适应控制方法
US11350268B2 (en) * 2018-05-18 2022-05-31 Qualcomm Incorporated End-to-end rate adaptation using RAN assisted rate adaptation
CN110971595B (zh) * 2019-11-22 2021-08-24 浙江中控技术股份有限公司 一种网络通信方法和系统
FI129689B (en) 2020-12-23 2022-06-30 NSION Oy Controlling the data flow between the source node and the destination node
NO346978B1 (en) 2021-11-26 2023-03-20 Pexip AS Method, system and computer program product for upspeeding in a videoconferencing session

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997022201A2 (en) 1995-12-12 1997-06-19 The Board Of Trustees Of The University Of Illinois Method and system for transmitting real-time video
US6701372B2 (en) * 1997-08-22 2004-03-02 Canon Kabushiki Kaisha Data communication apparatus and method
FI113124B (fi) * 1999-04-29 2004-02-27 Nokia Corp Tiedonsiirto
US6894974B1 (en) * 2000-05-08 2005-05-17 Nortel Networks Limited Method, apparatus, media, and signals for controlling packet transmission rate from a packet source
US7003794B2 (en) 2000-06-27 2006-02-21 Bamboo Mediacasting, Inc. Multicasting transmission of multimedia information
FI120125B (fi) * 2000-08-21 2009-06-30 Nokia Corp Kuvankoodaus
US20020194361A1 (en) * 2000-09-22 2002-12-19 Tomoaki Itoh Data transmitting/receiving method, transmitting device, receiving device, transmiting/receiving system, and program
US7304951B2 (en) 2000-11-21 2007-12-04 North Carolina State University Methods and systems for rate-based flow control between a sender and a receiver
JP3757857B2 (ja) * 2001-12-12 2006-03-22 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
US6910079B2 (en) 2002-01-25 2005-06-21 University Of Southern California Multi-threshold smoothing
JP3900413B2 (ja) * 2002-02-14 2007-04-04 Kddi株式会社 映像情報伝送方式およびプログラム
US20050201485A1 (en) 2002-05-22 2005-09-15 Koninkljke Phillips Electronics N.V. Transmission method using a virtual reception buffer to absorb fluctuation of the channel transmission rate
JP2006511162A (ja) 2002-12-20 2006-03-30 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 受信機駆動のストリーミングシステムでのマルチトラックヒンティング
ITBA20030039A1 (it) * 2003-08-29 2005-02-28 Grieco Luigi Alfredo Controllo di congestione rate-based del traffico entrante
KR100608821B1 (ko) 2004-07-22 2006-08-08 엘지전자 주식회사 휴대단말기의 왕복지연시간 측정장치 및 방법
KR100843073B1 (ko) * 2005-06-10 2008-07-03 삼성전자주식회사 오류 정정 패킷을 이용한 전송률 제어 방법 및 이를 이용한통신 장치
CN100521687C (zh) 2005-12-09 2009-07-29 北京瑞星国际软件有限公司 识别访问网络的模块的方法及装置
KR101091910B1 (ko) * 2005-12-29 2011-12-08 삼성테크윈 주식회사 실시간 전송 프로토콜을 사용하는 비디오 서버의 제어 방법및 그 기록 매체
CN1980238A (zh) * 2006-10-30 2007-06-13 上海广电(集团)有限公司中央研究院 基于实时传输/控制协议的h.264流媒体传输控制方法
US8180283B2 (en) * 2007-02-14 2012-05-15 Alcatel Lucent Method of providing feedback to a media server in a wireless communication system
BRPI0721332A2 (pt) * 2007-03-09 2014-03-18 Thomson Licensing Um método para um eficiente retro alimentação de condições de canal de recepção em sistemas de vídeo adaptativo multi-adição e de difusão.

Also Published As

Publication number Publication date
CN101971629A (zh) 2011-02-09
EP2255535A4 (en) 2012-03-14
WO2009113924A8 (en) 2010-10-07
EP2255535B1 (en) 2015-01-14
CN101971629B (zh) 2014-05-21
US20110013514A1 (en) 2011-01-20
EP2255535A1 (en) 2010-12-01
US8588071B2 (en) 2013-11-19
WO2009113924A1 (en) 2009-09-17
BRPI0822489A2 (pt) 2015-06-16

Similar Documents

Publication Publication Date Title
BRPI0822489B1 (pt) Método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo, dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo, e, meio legível por computador
US8621061B2 (en) Adaptive bitrate management for streaming media over packet networks
US9203886B2 (en) Content rate control for streaming media servers
KR101099800B1 (ko) 미디어 서버로의 피드백 제공 방법
US7218610B2 (en) Communication system and techniques for transmission from source to destination
AU2014252266B2 (en) Voip bandwidth management
CN106301684B (zh) 一种媒体数据传输方法及装置
KR101472922B1 (ko) 무선 송신 비율 제어 방법
CN108292970B (zh) 通过互联网直播分发的自适应比特率调整方法和装置
US20020194361A1 (en) Data transmitting/receiving method, transmitting device, receiving device, transmiting/receiving system, and program
US20090089447A1 (en) Proxy-driven content rate selection for streaming media servers
US20180227349A1 (en) Monitoring Network Conditions
JP2010517363A (ja) 複合および非複合rtcpパケット間のrtcp帯域幅の分割
JP5820238B2 (ja) データ送信装置およびデータ受信装置
US10298475B2 (en) System and method for jitter-aware bandwidth estimation
Papadimitriou et al. A rate control scheme for adaptive video streaming over the internet
Barzuza et al. Trend: A dynamic bandwidth estimation and adaptation algorithm for real-time video calling
TWI801835B (zh) 往返估算
KR101587547B1 (ko) 레이트 어댑테이션을 위한 네트워크 전송지연시간 변동 측정 방법 및 이를 이용하는 실시간 영상 서비스 제공 시스템
Dhamodaran et al. Adaptive Queue Management Scheme for Flexible Dual TCP/UDP Streaming Protocol
Singh Rate-control for conversational H. 264 video communication in heterogeneous networks
Hermanns Media Rate Adaptation for Conversational Video Services in Next Generation Mobile Networks

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: A CLASSIFICACAO ANTERIOR ERA: H04N 7/24

Ipc: H04L 29/06 (1990.01), H04N 21/238 (2011.01), H04N

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: 10 (DEZ) ANOS CONTADOS A PARTIR DE 06/10/2020, OBSERVADAS AS CONDICOES LEGAIS.