BR112017004323B1 - Videoconferência interativa - Google Patents

Abstract

VIDEOCONFERÊNCIA INTERATIVA. Trata-se de tecnologia para um equipamento de usuário (UE) local operável para realizar videoconferência com um UE remoto. O UE local pode definir uma região de interesse (ROI) dentro de um campo de visão de uma câmera do UE remoto. O UE local pode mapear a ROI para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF). O UE local pode enviar o um ou mais comandos de PTZF para o UE remoto, em que o UE remoto é configurado para identificar a ROI com base no um ou mais comandos de PTZF. O UE local pode receber vídeo codificado dentro da ROI a partir do UE remoto. O vídeo codificado pode incluir as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido para permitir que o vídeo codificado dentro da ROI seja renderizado e exibido no UE local.

Description

HISTÓRICO

[0001] O crescimento de serviços multimídia, o que inclui serviços de transmissão contínua e de conversação, é um dos principais impulsionadores da evolução para novas tecnologias e padrões de banda larga móvel. O conteúdo de vídeo digital é crescentemente consumido em dispositivos móveis. Há muitos aplicativos de vídeo extensivamente usados em dispositivos móveis no dia a dia. Por exemplo, transmissão contínua de vídeo online inclui serviços populares tais como YouTube e Hulu. A gravação de vídeo e videoconferência incluem serviços tais como Skype e Google Hangout. Em 2011, o YouTube teve mais de 1 trilhão de visualizações globais. Dez por cento das visualizações foram acessadas através de telefones móveis ou computadores do tipo tablet. À medida que mais telefones inteligentes, computadores do tipo tablet e outros dispositivos de computação móveis são comprados, seu uso para gravação de vídeo e videoconferência aumentará dramaticamente. Com tal alta demanda dos consumidores por serviços multimídia acoplados a desenvolvimentos em compressão de mídias e infraestruturas de rede sem fio, é de interesse o aprimoramento das capacidades de serviço multimídia de futuros sistemas de banda larga móvel e celular e a entrega de alta qualidade de experiência (QoE) aos consumidores, o que garante, assim, acesso ubíquo a conteúdo de vídeo e serviços a partir de qualquer lugar, a qualquer momento, com qualquer dispositivo e tecnologia.

BREVE DESCRIÇÃO DOS DESENHOS

[0002] Recursos e vantagens da revelação serão evidentes a partir da descrição detalhada a seguir, tomada em conjunto com os desenhos anexos que ilustram, em conjunto, a título de exemplo, os recursos da revelação; e em que:

[0003] A Figura 1 ilustra um serviço de telefonia multimídia por sistema de videoconferência com base em IMS (MTSI) que suporta um recurso de aproximação em região de interesse (ROI) de acordo com um exemplo;

[0004] A Figura 2 ilustra uma interface de usuário para gerar comandos de panoramização, inclinação, aproximação e foco (PTZF) e sinalizar os comandos de PTZF através de um protocolo de controle de câmera remota (FECC) de acordo com um exemplo;

[0005] A Figura 3 ilustra uma técnica para mapear uma região de interesse (ROI) definida por usuário para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF) de acordo com um exemplo;

[0006] A Figura 4 é um fluxograma que ilustra comunicações entre um equipamento de usuário (UE) remoto e um UE local para iniciar um recurso de aproximação em região de interesse (ROI) em um serviço de telefonia multimídia por aplicativo de videoconferência com base em IMS (MTSI) de acordo com um exemplo;

[0007] A Figura 5A ilustra uma mensagem de oferta de protocolo de descrição de sessão (SDP) que indica uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada com base em uma técnica de extensão de cabeçalho de protocolo de transporte em tempo real (RTP) de acordo com um exemplo;

[0008] A Figura 5B ilustra uma mensagem de resposta de protocolo de descrição de sessão (SDP) que aceita uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada com base em uma técnica de extensão de cabeçalho de protocolo de transporte em tempo real (RTP) de acordo com um exemplo;

[0009] A Figura 6A ilustra uma mensagem de oferta de protocolo de descrição de sessão (SDP) que indica uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada com base em uma técnica de retroalimentação de protocolo de controle de transporte em tempo real (RTCP) de acordo com um exemplo;

[0010] A Figura 6B ilustra uma mensagem de resposta de protocolo de descrição de sessão (SDP) que aceita uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada com base em uma técnica de retroalimentação de protocolo de controle de transporte em tempo real (RTCP) de acordo com um exemplo;

[0011] A Figura 7 retrata a funcionalidade de um equipamento de usuário (UE) local operável para realizar videoconferência com um UE remoto de acordo com um exemplo;

[0012] A Figura 8 retrata um diagrama de fluxo de pelo menos uma mídia de armazenamento legível por máquina não transitória que tem instruções inseridas na mesma para operar um aplicativo de videoconferência em um equipamento de usuário (UE) local que suporta um recurso de aproximação interativo de acordo com um exemplo;

[0013] A Figura 9 retrata a funcionalidade de um equipamento de usuário (UE) local operável para realizar videoconferência com um UE remoto de acordo com um exemplo;

[0014] A Figura 10 retrata a funcionalidade de um equipamento de usuário (UE) remoto operável para realizar videoconferência com um UE local de acordo com um exemplo; e

[0015] A Figura 11 ilustra um diagrama de um dispositivo sem fio (por exemplo, UE) de acordo com um exemplo.

[0016] Agora, será feita referência às modalidades exemplificativas ilustradas, e linguagem específica será usada no presente documento para descrever as mesmas. No entanto, deve-se compreender que nenhuma limitação do escopo da invenção é, desse modo, pretendida.

DESCRIÇÃO DETALHADA

[0017] Antes que a presente invenção seja revelada e descrita, deve-se compreender que esta invenção não é limitada às estruturas particulares, etapas de processo ou materiais revelados no presente documento, mas é estendida a equivalentes dos mesmos conforme seria reconhecido por aqueles de habilidade comum nas técnicas relevantes. Deve-se compreender também que a terminologia empregada no presente documento é usada para o propósito de descrever exemplos particulares somente e não se destina a ser limitante. As mesmas referências numéricas em diferentes desenhos representam o mesmo elemento. Os números fornecidos nos diagramas de fluxo e processos são fornecidos por questão de clareza nas etapas e operações de ilustração e não indicam necessariamente uma ordem ou sequência específica.

MODALIDADES EXEMPLIFICATIVAS

[0018] Uma visão geral inicial de modalidades de tecnologia é fornecida abaixo e, então, as modalidades de tecnologia específicas são descritas em mais detalhes posteriormente. Este sumário inicial é destinado a auxiliar os leitores na compreensão da tecnologia mais rapidamente, mas não é destinado a identificar os recursos-chave ou essenciais da tecnologia nem é destinado a limitar o escopo da matéria reivindicada.

[0019] A tecnologia é descrita para operar um aplicativo de videoconferência em um equipamento de usuário (UE) local que suporta um recurso de aproximação interativo. Um usuário local no UE local pode se comunicar com um usuário remoto em um UE remoto com o uso do aplicativo de videoconferência. O usuário local que visualiza uma cena através do aplicativo de videoconferência em uma tela de exibição do UE local pode selecionar uma área dentro da cena. Essa área pode ser chamada de região de interesse (ROI) dentro de um campo de visão no UE remoto. O usuário local pode selecionar a ROI quando o usuário local deseja uma representação mais detalhada do conteúdo dentro da ROI. O usuário local pode comutar dinamicamente de um fornecimento de vídeo da cena para a área selecionada dentro da cena (isto é, a ROI) com o uso do recurso de aproximação interativo. A ROI pode ser mapeada para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF). Em outras palavras, os comandos de PTZF podem descrever ou distinguir a ROI selecionada pelo usuário local no UE local. O UE local pode comunicar os comandos de PTZF para o UE remoto através de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP), ou alternativamente, com o uso de uma extensão de cabeçalho de protocolo de transporte em tempo real (RTP). O UE remoto pode processar os comandos de PTZF a fim de identificar a ROI. O UE remoto pode capturar vídeo dentro da ROI. Adicionalmente, o UE remoto pode codificar o vídeo dentro da ROI. O vídeo codificado pode incluir regiões dentro da ROI e excluir regiões fora da ROI. O UE remoto pode transmitir o vídeo codificado para o UE local. O vídeo codificado pode incluir as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido. Em outras palavras, o UE remoto pode fornecer o vídeo codificado dentro da ROI a fim de permitir a reprodução do vídeo codificado no UE local. Quando o UE remoto transmite apenas a área selecionada da cena (isto é, a ROI) para o UE local e exclui a área não selecionada da cena da transmissão, o aplicativo de videoconferência pode usar mais eficientemente a largura de banda disponível.

[0020] Houve inúmeros padrões multimídia que foram desenvolvidos para permitir que multimídia seja comunicada de, para ou entre dispositivos de computação móveis. Por exemplo, na transmissão contínua de vídeo, o projeto de parceria da terceira geração (3GPP) desenvolveu especificação técnica (TS) 26.234 (por exemplo, Versão 11.0.0) que descreve serviços de transmissão contínua comutados por pacote (PSS) que têm base no protocolo de transmissão contínua em tempo real (RTSP) para transmissão contínua de difusão ponto a ponto de conteúdo sob demanda ou conteúdo ao vivo. Adicionalmente, serviços de transmissão contínua com base em protocolo de transferência de hipertexto (HTTP), que incluem transferência por download progressiva e transmissão contínua adaptativa dinâmica por HTTP (DASH), são descritos em 3GPP TS 26.247 (por exemplo, Versão 11.0.0). A especificação dos serviços de difusão e difusão seletiva de multimídia (MBMS) com base em 3GPP TS 26.346 (por exemplo, Versão 11.0.0) especifica técnicas de transmissão contínua e transferência por download para distribuição de conteúdo por difusão/difusão seletiva. Desse modo, dispositivos de computação móveis com base em DASH/PSS/MBMS, tais como equipamentos de usuário (UEs), decodificam e renderizam vídeos de transmissão contínua nos dispositivos de UE. Suporte para o formato de arquivo 3GP em 3GPP TS 26.244 (por exemplo, Versão 11.0.0) é obrigatório em todas essas especificações para suportar casos de uso de transferência por download de arquivo e transmissão contínua com base em HTTP.

[0021] Um exemplo de um padrão para comunicação por vídeo de conversação, tal como videoconferência, é fornecido em 3GPP TS 26.114 (por exemplo, 11.0.0). O padrão descreve o serviço de telefonia multimídia por IMS (MTSI) que permite a entrega de conteúdo e serviços de conversação multimídia avançados por redes com base em subsistemas multimídia (IMS) de protocolo de internet (IP). IMS é padronizado em 3GPP TS 26.140 (por exemplo, Versão 11.0.0). O 3GPP TS 26.140 descreve manejo e interação de mídias, o que inclui controle de mídias, codecs de mídia e o transporte de mídias e dados de controle. O 3GPP TS 26.140 permite também compartilhamento de vídeo com o uso de serviços de compartilhamento multimídia (MMS), em que suporte para o formato de arquivo 3GP é fornecido.

[0022] Conforme descrito em mais detalhes abaixo, uma chamada de MTSI pode usar mecanismos de função de controle de sessão de chamada (CSCF) para reencaminhar sinalização de plano de controle entre os UEs envolvidos na chamada (por exemplo, o aplicativo de videoconferência). No plano de controle, os servidores de aplicativo (AS) podem estar presentes e fornecer serviços suplementares, tal como resumo ou retomada de chamada, encaminhamento de chamada e chamadas com vários participantes, etc.

[0023] Um terminal de UE transmissor com base em MTSI pode capturar e gravar vídeo e, depois, transferir o vídeo para um terminal de UE receptor com base em MTSI por uma rede 3GPP. Então, o terminal de UE receptor pode decodificar e renderizar o vídeo. Em MTSI, o protocolo de iniciação de sessão (SIP) pode servir como o protocolo de controle de camada de aplicativo para estabelecer, modificar e terminar sessões multimídia de conversação, tais como videoconferências, chamadas de telefonia por Internet e outros. Sinalização com base em protocolo de descrição de sessão (SDP) entre os terminais de envio e recebimento pode permitir considerações de oferta/resposta na negociação de capacidade relacionada às mídias, o que inclui codecs, taxas de bits, resoluções, etc. O transporte de mídias em MTSI tem base no protocolo de transporte em tempo real (RTP) (especificado por IETF RFC 3550) por UDP/IP.

[0024] As resoluções de dispositivos de captura e, portanto, vídeos comprimidos, estão crescendo rapidamente. Por exemplo, com o uso do padrão recente de Conversão em Código de Vídeo de Alta Eficiência (HEVC), conteúdo de 4K pode ser transportado e armazenado como parte de um produto operacional. As câmeras que têm resolução de 4k por 2k estão agora amplamente disponíveis. A transmissão contínua ao vivo de vídeo tem sido demonstrada com resoluções de 8k por 4k. As resoluções, em termos de números de pixels, têm probabilidade de aumentar no futuro. Com esses conteúdos de resolução muito alta, novos usos em transmissão contínua de vídeo são agora possíveis, tal como recursos de aproximação interativos.

[0025] Os serviços de vídeo de conversação que estão atualmente presentes no mercado, tal como MTSI, permitem adaptação dinâmica de vídeo em termos de largura de banda, resolução espacial, orientação, etc. Contudo, esses serviços de vídeo de conversação não permitem que usuários comutem dinamicamente para uma área selecionada por usuário no vídeo sendo continuamente transmitido, e aperfeiçoem codificações para essa área selecionada por usuário. Como resultado, a resolução de vídeo alcançável durante o uso de recursos de aproximação interativos em chamadas de vídeo pode ser limitada. Embora um aplicativo receptor possa aplicar aproximação na região de interesse (ROI) e recortar as partes indesejadas do vídeo (por exemplo, em resposta aos comandos de uma interface de usuário), uma limitação dos sistemas atuais é que o terminal de envio iria ainda codificar e transmitir o quadro de vídeo inteiro na ausência de qualquer sinalização de ROI do terminal de recebimento.

[0026] Em um exemplo, a sinalização das informações de ROI de um receptor de MTSI para um emissor de MTSI pode permite que o emissor de MTSI entregue uma corrente de qualidade superior. O emissor de MTSI pode usar uma taxa de bits negociada inteira ou preponderantemente na codificação da parte de ROI do vídeo. Para possibilitar isso, a sinalização em ambas as direções pode ser realizada. O emissor de MTSI pode enviar mensagens para o receptor de MTSI para expressar capacidade, e o receptor de MTSI pode enviar mensagens para o emissor de MTSI para expressar a ROI desejada.

[0027] A Figura 1 ilustra um serviço de telefonia multimídia através de sistema de videoconferência com base em IMS (MTSI) exemplificativo que suporta um recurso de aproximação em região de interesse (ROI). Um usuário (por exemplo, usuário A) associado a um equipamento de usuário (UE) remoto 128 (por exemplo, um telefone móvel, um computador do tipo tablet, um computador de mesa ou outro dispositivo adequado) pode estar em videoconferência com outro usuário (por exemplo, usuário B) associado a um UE local 148. Em outras palavras, tanto o UE remoto 128 quanto o UE local 148 podem estar executando um aplicativo de videoconferência bidirecional 160. O usuário A pode estar em proximidade ao UE remoto 128 (por exemplo, em frente ao UE remoto 128) e o usuário B pode estar em proximidade ao UE local 148 (por exemplo, em frente ao UE local 148). Tanto o UE remoto 128 quanto o UE local 148 podem, cada um, incluir uma câmera que permite que os usuários visualizem um ao outro enquanto o aplicativo de videoconferência 160 está sendo executa. O UE remoto 128 pode incluir uma câmera remota e o UE local 148 pode incluir uma câmera local. O UE remoto 128 pode incluir uma câmera que captura vídeo do usuário A durante operação, e uma tela de exibição, que exibe vídeo do usuário B para o usuário A durante operação. De modo similar, o UE local 148 pode incluir uma câmera que captura vídeo do usuário B durante operação, e uma tela de exibição, que exibe vídeo do usuário A para o usuário B durante operação. Em outras palavras, o usuário A pode ver o usuário B através da tela de exibição no UE remoto 128, e o usuário B pode ver o usuário A através da tela de exibição no UE local 148.

[0028] Em um exemplo, o aplicativo de videoconferência 160 pode funcionar através de um sistema de vídeo de conversação com base em MTSI. Em outras palavras, o aplicativo de videoconferência 160 pode operar por serviço de telefonia multimídia com base em 3GPP, que conecta o UE remoto 128 e o UE local 148 um ao outro e à rede de telefone.

[0029] O UE remoto 128 pode se conectar à rede de núcleo através de uma rede de acesso via rádio (RAN) 126, um nó suporte de serviço geral de rádio de pacotes (GPRS) servidor (SGSN) 124 e/ou um nó de suporte de GPRS de porta de comunicação (GGSN) 122. O UE remoto 128 pode enviar e receber dados através de uma função de controle de sessão de chamada proxy (P-CSCF) 120. A P-CSCF 120 pode enviar e receber dados com uma função de controle de sessão de chamada servidora (S-CSCF) 114. Em alguns exemplos, a S-CSCF 114 pode enviar e receber dados de um servidor de aplicativo (AS) 122, que pode fornecer serviços suplementares, tal como retenção/retomada de chamada, encaminhamento de chamada e chamadas de múltiplos participantes, etc. Nesse exemplo, a RAN 126, a SGSN 124, a GGSN 122, a P-CSCF 120, a S-CSCF 114 e o AS 112 podem ser associados a um operador A 110. A S- CSCF 114 pode enviar e receber dados de outras partes da rede de núcleo. Por exemplo, a S-CSCF 114 que é associada a um Operador A 110 pode se comunicar com uma CSCF interrogante (I-CSCF) 136 que é associada a um operador B 130.

[0030] O UE local 148 pode se conectar à rede de núcleo através de sua própria rede de acesso via rádio (RAN) 146, nó suporte de serviço geral de rádio de pacotes (GPRS) servidor (SGSN) 144 e nó de suporte de GPRS de porta de comunicação (GGSN) 142. O UE local 148 pode enviar e receber dados através de uma função de controle de sessão de chamada proxy (P-CSCF) 140. A P- CSCF 140 pode enviar e receber dados com uma função de controle de sessão de chamada servidora (S-CSCF) 134. Em alguns exemplos, a S-CSCF 134 pode enviar e receber dados a partir de um servidor de aplicativo (AS) 132, que pode fornecer serviços suplementares, tais como retenção/retomada de chamada, encaminhamento de chamada e chamadas com múltiplos participantes, etc. A S-CSCF 114 e a S-CSCF 134 podem, cada uma, se comunicar com uma CSCF interrogante (I-CSCF) 136. Em outras palavras, o operador A 110 pode se comunicar com o operador B 130 através de comunicações entre a S-CSCF 114 e a I-CSCF 136. A I-CSCF 134 pode ler e escrever para um servidor assinante local (HSS) 138 e/ou uma função de localização de assinante (SLF) 138. Nesse exemplo, a RAN 146, a SGSN 144, a GGSN 142, a P-CSCF 140, o(a) HSS/SLF 138, a I-CSCF 136, a S-CSCF 134 e o AS 132 podem ser associados ao operador B 130.

[0031] Em uma configuração, o aplicativo de videoconferência 160 pode suportar um recurso de aproximação. Por exemplo, o UE local 148 pode aplicar aproximação em um recurso ou local particular no campo de visão da câmera remota (isto é, a câmera associada ao UE remoto 128). No UE local 148, o usuário B pode definir uma região de interesse (ROI) 150 dentro de um campo de visão no UE remoto 128. Como um exemplo não limitante, no UE remoto 128, o usuário A pode ver a cabeça do usuário B na tela de exibição do UE remoto 128. No UE local 148, o usuário B pode ver a cabeça do usuário A e torso na tela de exibição do UE local 148. O usuário B pode desejar uma vista aprimorada do usuário A (por exemplo, o usuário B pode desejar aplicar aproximação na face do usuário A). O usuário B pode definir a ROI 150 no UE local 150, de modo que a ROI 150 inclua a face do usuário A. A ROI 150 pode ser definida no UE local 150 com o uso de, for exemplo, uma interface gráfica de usuário. Em outras palavras, o usuário B pode selecionar a região com o uso de um dispositivo de entrada, tal como um mouse de computador ou uma tela sensível ao toque. A ROI 150 pode incluir outras regiões adequadas dentro do campo de visão da câmera remota. Por exemplo, o usuário B pode definir a ROI 150 para incluir o torso do usuário A, uma árvore atrás do usuário A, etc. Como outros exemplos, a ROI 150 pode incluir uma região à direita no topo da tela de exibição do UE local 148 (que corresponde a um campo de visão apropriado da câmera remota), uma região à esquerda inferior da tela de exibição do UE local 148, etc.

[0032] Em um exemplo, o usuário B pode definir a ROI 150 para ter um tamanho e local arbitrários do campo de visão da câmera remota. Em outro exemplo, o UE remoto 128 pode permanecer estacionário quando a ROI 150 é definida, de modo que a seleção de uma ROI 150 não mova ou mude o campo de visão da câmera remota. Em ainda outro exemplo, o usuário B pode selecionar uma nova ROI 150 conforme desejar. Adicionalmente, o usuário A (no UE remoto 128) pode selecionar também uma ROI análoga para aplicar aproximação no usuário B (no UE local 148).

[0033] Conforme explicado em mais detalhes abaixo, a ROI 150 pode ser mapeada para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF). Os comandos de PTZF podem distinguir ou descrever a ROI 150 que é selecionada pelo usuário B. Em um exemplo, uma série ou sequência de comandos de PTZF pode ser usada para descrever a ROI 150. Os comandos de PTZF podem ser adicionalmente definidos no protocolo H.281/H.224. Os comandos de PTZF podem ser uma solução alternativa para distinguir a ROI 150 em oposição ao uso de coordenadas específicas. Os comandos de PTZF que descrevem a ROI 150 podem ser enviados do UE local 148 para o UE remoto 128. Conforme discutido em mais detalhes abaixo, os comandos de PTZF que descrevem a ROI 150 podem ser comunicados com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP). Em uma solução alternativa, os comandos de PTZF que descrevem a ROI 150 podem ser inseridos em pelo menos uma extensão de cabeçalho de protocolo de transporte em tempo real (RTP) no vídeo local capturado (isto é, vídeo capturado no UE local 148). A mensagem de retroalimentação de RTCP ou a extensão de cabeçalho de RTP pode direcionar o UE remoto 128 para capturar vídeo dentro da ROI 110.

[0034] Em alguns exemplos, o UE remoto 128 pode capturar vídeo que inclui apenas a ROI 150 e exclui regiões fora da ROI 150. Como um exemplo não limitante, a extensão de cabeçalho de RTP ou a mensagem de retroalimentação de RTCP (que inclui os comandos de PTZF que descrevem a ROI 150) podem instruir o UE remoto 128 para capturar uma ferida no queixo do usuário A. Em outras palavras, a câmera remota de UE pode capturar apenas a ferida no queixo do usuário A e nenhuma outra região que cerca a queixo do usuário A.

[0035] Capturando-se o vídeo de acordo com a ROI 150, o UE remoto 128 pode codificar o vídeo, for exemplo, com o uso de um esquema de codificação relativamente com baixa compressão. Portanto, o vídeo pode fornecer uma vista relativamente aproximada e detalhada da ROI 150, ao mesmo tempo que mantém substancialmente um nível de qualidade definido. O UE remoto 128 pode codificar o vídeo (com a ROI 150) com o esquema de codificação de menos perda, pois os recursos que foram previamente usados para codificar o campo de visão inteiro são agora are usados apenas para codificar a ROI 150. O UE remoto 128 pode transmitir o vídeo codificado (apenas com a ROI) para o UE local 148. Visto que o UE remoto 128 pode consumir substancialmente a mesma quantidade de largura de banda com a transmissão do vídeo codificado (apenas com a ROI 150), em oposição ao campo completo de visão da câmera remota (associado ao UE remoto 128), o vídeo codificado pode ser de qualidade substancialmente alta. Em outras palavras, o vídeo codificado da ROI pode ser relativamente claro e não granular ou embaçado. Em relação a isso, a técnica descrita no presente documento é superior a tecnologias anteriores em que um usuário (por exemplo, o usuário B) aplica aproximação manualmente no quadro exibido na tela de exibição, o que pode levar a um nível de qualidade reduzido. Na solução atual, o UE remoto 128 pode codificar apenas a ROI 150 com uma resolução negociada em vez de todo o quadro capturado, e isso levaria a uma resolução geral superior e melhor experiência de usuário no UE local 148.

[0036] Como um exemplo não limitante, o UE remoto 128 pode codificar um vídeo da ferida no queixo do usuário A. O UE remoto 128 pode usar um esquema de codificação com compressão relativamente baixa, de modo que o queixo do usuário A seja passível de visualização com uma resolução e nível de clareza relativamente altos. Em outras palavras, o vídeo codificado pode ser uma representação em aproximação do queixo do usuário A, mas ainda mantém um nível de qualidade relativamente alto (por exemplo, não granular). Adicionalmente, uma largura de banda inteira pode ser usada para enviar o vídeo codificado do queixo do usuário A, o que pode resultar em uma representação relativamente clara e detalhada do queixo do usuário A. Essa representação pode fornecer detalhes adicionais da face do usuário A em oposição a se toda a face do usuário A fosse incluída como parte do vídeo codificado.

[0037] Em uma configuração alternativa, o UE remoto 128 pode capturar vídeo que inclui todo o campo de visão da câmera remota (associado ao UE remoto 128). Contudo, o UE remoto 108 pode apenas codificar uma porção do vídeo que inclui a ROI 150. Adicionalmente, o UE remoto 108 pode transmitir o vídeo codificado que inclui apenas a ROI 150 e exclui regiões fora da ROI 150.

[0038] O UE local 148 pode receber o vídeo codificado do UE remoto 128, em que o vídeo codificado inclui regiões dentro da ROI 150 e exclui regiões fora da ROI 150. O UE local 148 pode renderizar e exibir o vídeo codificado na tela de exibição associada ao UE local 148. Como um exemplo não limitante, o usuário B que senta em frente ao UE local 148 pode ver uma representação detalhada e aproximada da ferida no queixo do usuário A. O usuário B pode sempre reverter para uma visualização anterior do usuário A, por exemplo, o usuário B pode retirar a aproximação e reverter para aquela visualização da face e torso inteiros do usuário A na tela de exibição do UE local 148.

[0039] O serviço multimídia com base em protocolo de transporte em tempo real (RTP) para controle de câmera remota do Setor de Padronização de Telecomunicação (ITU- T) da União Internacional de Telecomunicações (ITU) é definido nas especificações de ITU-T H.224/H.281 e na Solicitação de Comentários (RFC) da Força-Tarefa de Engenharia da Internet (IETF) 4573, com o uso do protocolo de internet em pilha (IP)/protocolo de datagrama de usuário (UDP)/RTP/H.224/H.281.

[0040] No protocolo de controle de câmera remota (FECC), a indicação de uma região de interesse (ROI) e a aproximação em uma ROI particular podem ser alcançadas pela sinalização de comandos de PTZF - panoramização, inclinação, aproximação e foco, conforme padronizado por ITU-T H.281. Por exemplo, o formato de mensagem de uma mensagem de INICIAR AÇÃO pode ser conforme a seguir na Tabela 1: Tabela 1

[0041] A mensagem de INICIAR AÇÃO pode incluir, para panoramização (P), um primeiro valor para direita (R) e um segundo valor para esquerda (L). A mensagem de INICIAR AÇÃO pode incluir, para inclinação (T), um primeiro valor para acima (U) e um segundo valor para baixo (D). A mensagem de INICIAR AÇÃO pode incluir, para aproximação (Z), um primeiro valor para mais perto (I) e um segundo valor para mais longe (O). A mensagem de INICIAR AÇÃO pode incluir, para foco (F), um primeiro valor para dar foco (I) e um segundo valor para tirar foco (O).

[0042] O protocolo de FECC conta com ITU-T H.281 por H.224. Portanto, as informações de ROI podem ser sinalizadas através de pacotes de RTP que carregam quadros de H.224. O FECC pode ser interno ao quadro de H.224 e pode ser identificado por um ID de cliente do pacote de H.224. Além disso, RFC 4573 define a sintaxe e semântica dos parâmetros de Protocolo de Descrição de Sessão (SDP) usados para suportar protocolo de controle de câmera remota com o uso de H.224. A oferta/resposta de SDP pode permitir negociar a capacidade entre os dois clientes de MTSI.

[0043] No caso de MTSI de 3GPP, a câmera pode ser fixa ao dispositivo (por exemplo, um computador do tipo tablet ou um telefone inteligente) e não ter capacidades de realmente ser independentemente controlada. Para uma câmera fixa sem capacidades de panoramização/inclinação, o comando de panoramização pode ser mapeado para movimentos para esquerda e direita/translações e o comando de inclinação pode ser mapeado para movimentos para cima e para baixo/translações pelo plano de imagem bidimensional (2D). Como tal, uma combinação de comandos de PTZ pode permitir a aproximação em uma região de interesse arbitrária. Essas funcionalidades são chamadas vPTZ (PTZ virtual). As moções de câmera podem ser simuladas mudando-se o armazenamento temporário de entrada da câmera, por exemplo, quando a panoramização ou inclinação for aplicada na imagem completa, nenhuma modificação é feita. Quando a câmera aplica aproximação, uma área retangular menor pode ser selecionada e, depois a inclinação e a panoramização podem ser aceitas por translação do retângulo selecionado.

[0044] Em um exemplo, o uso direto do protocolo de FECC com o propósito de sinalização de ROI pode ser desvantajoso de um ponto de vista da latência em um ambiente de comunicação móvel com características de enlace dinamicamente variadas com largura de banda potencialmente baixa. O FECC é um protocolo progressivo que usa transmissão contínua de comandos de PTZF pelo receptor (por exemplo, um UE local em que o usuário seleciona a ROI) até que o usuário obtenha a corrente com a ROI desejada. Em outras palavras, o emissor (por exemplo, um UE remoto em que a codificação ocorre) não tem as informações de ROI exatas. Adicionalmente, o receptor (por exemplo, o UE local com uma interface de usuário que gera informações de ROI) não conhece os tamanhos de etapa que o emissor (por exemplo, o UE remoto) usaria no processamento dos comandos de PTZF recebidos. Os tamanhos de etapa podem indicar um número de pixels de translação para cima/baixo e para esquerda/direita que resulta de um determinado comando de P e T. Os tamanhos de etapa podem indicar também uma quantidade de aproximação que ocorre depois da transmissão de um comando de Z. Esses fatores de incerteza podem necessitar enviar uma sequência de comandos de PTZF com o uso do protocolo de FECC até que a corrente com a ROI desejada possa ser recebida.

[0045] Como um exemplo não limitante, a ROI pode ser descrita com o uso de 13 comandos de PTZF. Em outras palavras, os 13 comandos de PTZF podem descrever a ROI selecionada pelo usuário no receptor (ou UE local). Os 13 comandos de PTZF podem ser enviados a partir do receptor (por exemplo, o UE local) para o emissor (por exemplo, o UE remoto). Em técnicas tradicionais, uma quantidade de tempo para enviar os 13 comandos de PTZF pode ter base em um tempo de ida e volta (RTT) e um atraso de interface de usuário (UI_delay) para expedir um novo comando PTZF. Como um exemplo não limitante, o tempo de ida e volta pode ser 300 milissegundos (ms) e o atraso de interface de usuário pode ser de 100 ms. Portanto, a quantidade de tempo para enviar os 13 comandos de PTZF (isto é, a latência) pode ser limitado entre 13 x UI_delay + RTT (ou 1,6 segundos) e 13 x RTT (ou 3,9 segundos). Em outras palavras, a latência no envio da sequência de comandos de PTZF, nesse exemplo, pode estar entre 1,6 segundos e 3,9 segundos. Portanto, a latência experimentada pelo usuário a fim de ver a corrente correspondente a uma ROI solicitada pode ser tão longa quanto 3,9 segundos com o uso de técnicas tradicionais, o que pode resultar em uma experiência de usuário ruim.

[0046] A tecnologia inovadora descrita no presente documento estende um protocolo de FECC anterior, de modo que um receptor de vídeo (por exemplo, um UE local) pode enviar uma sequência agrupada de múltiplos comandos de PTZF em um único pacote de RTP (isto é, em uma única transmissão) para um emissor de vídeo ou um terminal remoto (por exemplo, um UE remoto). Em uma solução alternativa, o receptor de vídeo pode enviar a sequência agrupada de múltiplos comandos de PTZF em um único pacote de RTCP para o emissor de vídeo. Os múltiplos comandos de PTZF podem ser executados em uma sequência no emissor de vídeo, o que permite que o emissor de vídeo emissor convirja rapidamente para uma ROI desejada com uma troca de ida e volta de mensagens. Essa versão estendida do protocolo de FECC é chamada de FECC aprimorada (eFECC). Em outras palavras, suporte a FECC aprimorado pode indicar que o receptor de vídeo (por exemplo, o UE local) é configurado para enviar a sequência de comandos de PTZF na única transmissão, e que o emissor de vídeo (por exemplo, o UE remoto) é configurado para processar a sequência de comandos de PTZF, identificar a ROI com base nos comandos de PTZF e codificar vídeo dentro da ROI, consequentemente.

[0047] No exemplo anterior, a quantidade de tempo para enviar os 13 comandos de PTZF pode ser estar entre 1,6 segundos e 3,9 segundos com o uso de técnicas tradicionais. Com o uso de FECC aprimorado, a quantidade de tempo para enviar os mesmos 13 comandos de PTZF pode ser reduzida. A latência experimentada pelo usuário a fim de ver a corrente correspondente à ROI solicitada pode ser determinada por UI_delay + RTT. Nesse exemplo, o UI_delay é de 300 ms e o RTT é 100, portanto, a latência pode ser 400 ms (ou 0,4 segundos). O uso cego do protocolo de FECC anterior em configurações móveis pode levar a níveis intoleráveis de latência experimentada pelo usuário antes de visualizar a corrente correspondente à ROI solicitada. Com o uso do FECC aprimorado, a quantidade de latência pode ser reduzida.

[0048] A Figura 2 ilustra uma interface de usuário 240 exemplificativa para gerar comandos de panoramização, inclinação, aproximação e foco (PTZF) e sinalizar os comandos de PTZF através de um protocolo de controle de câmera remota (FECC). A interface de usuário 240 pode estar em um equipamento de usuário (UE) local 220. Um primeiro usuário 210 do UE local 220 pode estar em videoconferência com um segundo usuário 230. O segundo usuário 230 pode estar usando um UE remoto (não mostrado na Figura 2) para realizar a videoconferência com o primeiro usuário 210. Portanto, o primeiro usuário 210 pode ver o segundo usuário 230 através de um aplicativo de videoconferência que está sendo executa no UE local 220. O primeiro usuário 210 pode selecionar uma região de interesse (ROI) 250 através da interface de usuário 240 no UE local 220. Por exemplo, o primeiro usuário 210 pode selecionar uma área da face do segundo usuário. Essa área que é selecionada pelo primeiro usuário 210 pode indicar a ROI 250. Com base na seleção da ROI 250, o UE local 220 pode gerar a sequência de comandos de PTZF. O UE local 220 pode enviar a sequência de comandos de PTZF para o UE remoto. O UE remoto pode identificar a ROI 250 com base na sequência de comandos de PTZF. O UE remoto pode apenas enviar vídeo codificado que inclui a ROI 250. Portanto, a interface de usuário 240 do UE local 220 pode exibir a ROI 250 em mais detalhes para o primeiro usuário 210.

[0049] A Figura 3 ilustra uma técnica para mapear uma região de interesse (ROI) exemplificativa definida pelo usuário 330 para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF). Uma interface de usuário 310 pode exibir um usuário remoto 320. A interface de usuário 310 pode ser associada a um equipamento de usuário (UE) local e o usuário remoto 320 pode ser associado a um UE remoto. Em um exemplo, um usuário local associado ao UE local pode estar em videoconferência com o usuário remoto 320 a 1080p e uma resolução negociada de 1920 x 1080. O usuário local do UE local pode desejar aplicar aproximação na face do usuário remoto. Em outras palavras, o usuário local do UE local pode desejar que a face do usuário remoto preencha uma porção aumentada da interface de usuário 310 e com mais detalhes (isto é, um nível de aproximação maior). Nesse caso, o usuário local pode selecionar uma região de interesse (ROI) 330 através da interface de usuário 310 no UE local. Por exemplo, o usuário local pode selecionar a ROI 330 para englobar a face do usuário remoto.

[0050] Conforme mostrado na Figura 3, a interface de usuário 310 pode ser dividida em um número selecionado de peças em uma direção X e em uma direção Y. A seleção de usuário da ROI 330 pode ser traduzida em uma sequência de comandos de PTZF que deve ser enviada para o UE local para o UE remoto. Em um exemplo, o comando de Z pode resultar em aproximação aproximadamente 90% centralizada em ambas as dimensões X e Y, o que pode deixar de lado aproximadamente 10% da imagem original das dimensões X e Y. O comando de P pode resultar em movimento para esquerda/direita por peças em torno de uma peça central 340, e um quarto de tamanho de peça x de uma etapa com cada comando de P. O comando de T pode resultar um movimento para cima/baixo pelas peças em torno da peça central 340, e um quarto de tamanho de peça y de uma etapa com cada comando de T.

[0051] Conforme mostrado na Figura 3, a ROI definida por usuário 330 pode ser associada a coordenadas X de (1080, 1560) e coordenadas Y de (540, 810). Um canto esquerdo inferior da interface de usuário 310 pode ser uma origem com coordenadas X e Y de (0,0). A fim de representar a ROI 330 com o uso da sequência de comandos de PTZF, pelo menos oito comandos de aproximação (conforme mostrado pela seta sólida na Figura 3) podem ser usados para obter a peça central 340. Os oito comandos de aproximação podem ser usados para obter a peça central 340 depois da aproximação com as coordenadas X e Y de X (720, 1200) e Y (405, 675), e a peça central correspondente 340 tem dimensões de 480 x 270. Em outras palavras, a peça central 340 tem um tamanho de peça X de 480 pixels e um tamanho de peça Y de 270 pixels. Adicionalmente, pelo menos dois comandos na direção ascendente e pelo menos três comandos na direção direita podem ser usados a fim de obter a ROI 330 (conforme ilustrado pela seta tracejada na Figura 3). Portanto, um total de 13 comandos de PTZF podem ser usados para descrever ou distinguir a ROI 330. Os comandos de PTZF podem ser enviados do UE local para o UE remoto. O UE remoto pode identificar a ROI 330 com base nos comandos de PTZF, e fornecer vídeo dentro da ROI 330 e consequentemente para o UE local.

[0052] A Figura 4 é um fluxograma exemplificativo que ilustra comunicações entre um equipamento de usuário (UE) remoto 402 e um UE local 404 para iniciar um recurso de aproximação em região de interesse (ROI) em um serviço de telefonia multimídia através de aplicativo de videoconferência com base em IMS (MTSI). Em um exemplo, o UE remoto 402 pode ser chamado de um cliente de envio e o UE local 404 pode ser chamado de um cliente de recebimento. O UE remoto 402 e o UE local 404 podem, cada um, executar um aplicativo de videoconferência que permite um usuário remoto associado ao UE remoto 402 se comunicar com um usuário local associado ao UE local 404.

[0053] A sinalização com base em protocolo de descrição de sessão (SDP) entre o UE remoto 402 e o UE local 404 pode permitir considerações de oferta/resposta na negociação de capacidade relacionada a mídias para o suporte de protocolo de controle de câmera remota (FECC) aprimorado. O suporte de protocolo de FECC aprimorado pode indicar uma habilidade do UE local 404 (ou receptor) de enviar uma sequência agrupada de comandos de panoramização, inclinação, aproximação e foco (PTZF) com o uso do protocolo de FECC H.281/H.224 em uma única mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP) e/ou em um único pacote de protocolo de transporte em tempo real (RTP) com o uso de mecanismos de extensão de cabeçalho de RTP. Adicionalmente, o suporte de protocolo de FECC aprimorado pode indicar uma habilidade do UE remoto 402 (ou emissor) para processar a sequência de comandos de PTZF, identificar uma região de interesse (ROI) com base nos comandos de PTZF, e codificar vídeo dentro da ROI, consequentemente.

[0054] O UE remoto 402 pode enviar uma mensagem de oferta de SDP para o UE local 404. A mensagem de oferta de SDP pode indicar que o UE remoto 404 suporta o protocolo de FECC aprimorado, conforme descrito anteriormente. O UE local 404 pode receber a mensagem de oferta de SDP do UE remoto 402, e em resposta, enviar uma mensagem de resposta de SDP que aceita a capacidade de protocolo de FECC aprimorada.

[0055] Em uma configuração, o UE remoto 402 pode enviar tamanhos de etapa para o UE local 404. Em outras palavras, os tamanhos de etapa podem ser incluídos na sinalização do UE remoto 404 e do UE local 404. Inicialmente, o UE local 404 não sabe os tamanhos de etapa que o UE remoto 402 usará no processamento de comandos de PTZF recebidos. Portanto, o UE remoto 402 pode enviar os tamanhos de etapa para o UE local 404. O UE remoto 402 pode enviar os tamanhos de etapa como atributos de extensão de cabeçalho de RTP dedicados. Os tamanhos de etapa podem indicar um número de pixels de translação para cima/baixo e para esquerda/direita que resulta de um determinado comando de P e T. Os tamanhos de etapa podem indicar também uma quantidade de aproximação que ocorre depois da transmissão de um comando de Z. Como resultado, o UE local 404 pode determine como os comandos de PTZF serão processados no UE remoto 402, e o UE local 404 pode consequentemente selecionar os comandos de PTZF.

[0056] O UE local 404 pode derivar uma sequência de comandos de PTZF com base nos tamanhos de etapa anteriormente recebidos do UE remoto 402. Os comandos de PTZF podem corresponder a uma região de interesse (ROI) definida por usuário. Em outras palavras, a ROI pode ser definida pelo usuário local do UE local 404. O UE local 404 pode sinalizar a sequência de comandos de PTZF para o UE remoto 402. Em uma configuração, a sequência de comandos de PTZF pode ser enviada do UE local 404 para o UE remoto 402 em uma única transmissão. Em outras palavras, os comandos de PTZF podem ser agrupados e enviados para o UE remoto 402 ao mesmo tempo. Por exemplo, a sequência de comandos de PTZF pode ser enviada em um único pacote de RTCP. Alternativamente, a sequência de comandos de PTZF pode ser enviada como uma extensão de cabeçalho de RTP em um único pacote de RTP. O UE local 404 pode comunicar a sequência de comandos de PTZF para o UE remoto 402 com o uso da extensão de cabeçalho de RTP para correntes de vídeo de direção inversa.

[0057] O UE remoto 402 pode receber a sequência de comandos de PTZF do UE local 404. O UE remoto 402 pode identificar a ROI com base na sequência de comandos de PTZF. Visto que os comandos de PTZF são agrupados na única transmissão, o UE remoto 402 pode rapidamente processar os comandos de PTZF e entregar a corrente correspondente para uma ROI desejada com baixa latência. O UE remoto 402 pode capturar vídeo que inclui apenas a ROI e exclui regiões fora da ROI. O UE remoto 402 pode codificar o vídeo que inclui apenas a ROI. O UE remoto 402 pode enviar o vídeo codificado para o UE local 404. Em um exemplo, o UE remoto 402 pode indicar também uma ROI transmitida real em uma extensão de cabeçalho de RTP para correntes de vídeo de direção direta. O UE local 404 pode receber o vídeo codificado que inclui a ROI e reproduzir o vídeo no UE local 404.

[0058] Quando os comandos de PTZF (por exemplo, informações de ROI) são sinalizados a partir do UE local 404 para o UE remoto 402 com o uso da extensão de cabeçalho de mensagem RTP, um cliente de MTSI que suporta o recurso de FECC aprimorado (conforme descrito anteriormente) pode oferecer FECC aprimorado em mensagens de SDP para todos os vídeos que contêm correntes de mídias. O FECC aprimorado pode ser oferecido incluindo-se o atributo a=extmap que indica o nome de recurso uniforme (URN) de FECC aprimorado sob o escopo de linha de mídias relevante. Por exemplo, o URN de FECC aprimorado pode ser estabelecido como: urn:3gpp:efecc. Um exemplo de uma linha de mídias que inclui esse URN é: a=extmap:7 urn:3gpp:efecc. No exemplo acima de uma linha de mídias, o número 7 pode ser colocado com qualquer número na faixa de 1 a 14.

[0059] Quando os comandos de PTZF (por exemplo, informações de ROI) são sinalizados a partir do UE local 404 para o UE remoto 402 com o uso da mensagem de RTCP, um cliente de MTSI que suporta o recurso de FECC aprimorado pode oferecer eFECC em mensagens de SDP para todo o vídeo que contém correntes de mídias. O recurso de FECC aprimorado pode ser oferecido incluindo-se o atributo a=rtcp-fb com um tipo de eFECC inovador sob o escopo de linha de mídias relevante. Por exemplo, o tipo de eFECC em conjunto com a técnica de retroalimentação de RTCP pode ser expresso com o seguinte parâmetro: 3gpp:efecc. Um tipo de carga curinga (“*”) pode ser usado para indicar que o FECC aprimorado de atributo de retroalimentação de RTCP se aplica a todos os tipos de carga. Se diversos tipos de retroalimentações de ROI forem suportados e/ou a mesma retroalimentação de ROI deve ser especificada para um subconjunto dos tipos de carga, então, diversas linhas de “a=rtcp-fb” podem ser usadas. Um uso exemplificativo desse atributo para sinalizar eFECC em relação a uma linha de mídias com base na técnica de retroalimentação de RTCP é: a=rtcp- fb:* 3gpp-efecc.

[0060] A técnica de retroalimentação de RTCP pode envolver a sinalização dos comandos de PTZF (por exemplo, informações de ROI) tanto no modo de retroalimentação imediata quanto de RTCP prévio. O tipo de retroalimentação de RTCP inovador para eFECC pode incluir: um nome de valor de 3gpp-efecc, um nome longo de Controle de Câmera Remota Aprimorado, e uma referência da Especificação Técnica (TS) 26.114 do Projeto de Parceria da Terceira Geração (3GPP).

[0061] A capacidade do FECC aprimorado pode ser suportada bidirecional ou unilateralmente dependendo de como os clientes negociam para suportar o recurso durante as negociações de capacidade de SDP. Para terminais com capacidade assimétrica (por exemplo, a capacidade para processar comandos de PTZF ou informações de ROI, mas não detectar/sinalizar informações de ROI), os atributos “sendonly” e “recvonly” podem ser usados. Os terminais são para expressar sua capacidade em cada direção de uma maneira que seja suficientemente clara, de modo que os sinais sejam enviados apenas em cada direção até a extensão em que ambos expressem informações úteis e possam ser processados pelo recipiente.

[0062] O recurso de FECC aprimorado pode incluir sinalização da ROI atual de um usuário de recebimento (que é associado ao UE remoto 402) em uma sequência de comandos de PTZF. A sinalização dos comandos de PTZF pode ser de acordo com o protocolo H.281/H.224. Os comandos de PTZF podem ser enviados para o UE remoto 402 (por exemplo, o emissor), de modo que o UE remoto 402 possa codificar e transmitir de modo ideal o vídeo capturado dentro da ROI. Quando FECC aprimorado é negociado de modo bem-sucedido, isso pode ser sinalizado pelo cliente de MTSI. A sinalização da sequência de comandos de PTZF pode ocorrem de uma maneira agrupada por uma única mensagem de RTCP ou um único pacote de RTP com o uso de extensões de cabeçalho de RTP.

[0063] Com o uso de mensagens de retroalimentação de RTCP, o UE local 404 (isto é, o terminal de recebimento) pode incluir a sequência de comandos de PTZF correspondente às informações de ROI atuais do usuário de recebimento na mensagem de retroalimentação de RTCP que está sendo transmitida para o UE remoto 402 (isto é, o terminal de envio). Com o uso de extensões de cabeçalho de RTP, o UE local 404 (isto é, o terminal de recebimento) pode incluir a sequência de comandos de PTZF correspondente às informações de ROI atuais do usuário de recebimento nos pacotes de RTP que estão sendo transmitidos para o UE remoto 402 (isto é, o terminal de envio). Esses pacotes de RTP podem carregar correntes de vídeo na direção inversa, o que pode ser usado para comunicações de vídeo bidirecionais em MTSI.

[0064] A Figura 5A ilustra uma mensagem de oferta de protocolo de descrição de sessão (SDP) exemplificativa. A mensagem de oferta de SDP pode ser comunicada a partir de um equipamento de usuário (UE) remoto para um UE local. A mensagem de oferta de SDP pode ser com base em uma técnica de extensão de cabeçalho de protocolo de transporte em tempo real (RTP). A mensagem de oferta de SDP pode indicar uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada no UE remoto. Em particular, a capacidade de protocolo de FECC aprimorado pode indicar a capacidade do UE remoto de processar uma sequência de comandos de panoramização, inclinação, aproximação e foco (PTZF) recebidos do UE local, identificar uma região de interesse (ROI) a partir da sequência de comandos de PTZF e codificar vídeo dentro da ROI, consequentemente. Como um exemplo, a mensagem de oferta de SDP pode incluir um atributo de “a=extmap” e um valor associado de “4 urn:3gpp:efecc”.

[0065] A Figura 5B ilustra uma mensagem de resposta de protocolo de descrição de sessão (SDP) exemplificativa. A mensagem de resposta de SDP pode ser comunicada de um equipamento de usuário (UE) local para um UE remoto. A mensagem de resposta de SDP pode ser com base em uma técnica de extensão de cabeçalho de protocolo de transporte em tempo real (RTP). A mensagem de resposta de SDP pode aceitar uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada do UE remoto. Como um exemplo, a mensagem de resposta de SDP pode incluir um atributo de “a=extmap” e um valor associado de “4 urn:3gpp:efecc”.

[0066] A Figura 6A ilustra uma mensagem de oferta de protocolo de descrição de sessão (SDP) exemplificativa. A mensagem de oferta de SDP pode ser comunicada a partir de um equipamento de usuário (UE) remoto para um UE local. A mensagem de oferta de SDP pode ser com base em uma técnica de retroalimentação de protocolo de controle de transporte em tempo real (RTCP). A mensagem de oferta de SDP pode indicar uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada no UE remoto. Em particular, a capacidade de protocolo de FECC aprimorado pode indicar a capacidade do UE remoto de processar uma sequência de comandos de panoramização, inclinação, aproximação e foco (PTZF) recebidos do UE local, identificar uma região de interesse (ROI) a partir da sequência de comandos de PTZF e codificar vídeo dentro da ROI, consequentemente. Como um exemplo, a mensagem de oferta de SDP pode incluir um atributo de “a=rtcp-fb” e um valor associado de “3gpp:efecc”.

[0067] A Figura 6B ilustra uma mensagem de resposta de protocolo de descrição de sessão (SDP) exemplificativa. A mensagem de resposta de SDP pode ser comunicada de um equipamento de usuário (UE) local para um UE remoto. A mensagem de resposta de SDP pode ser com base em uma técnica de retroalimentação de protocolo de controle de transporte em tempo real (RTCP). A mensagem de resposta de SDP pode aceitar uma capacidade de protocolo de controle de câmera remota (FECC) aprimorada do UE remoto. Como um exemplo, a mensagem de resposta de SDP pode incluir um atributo de “a=extmap” e um valor associado de “4 urn:3gpp:efecc”.

[0068] Outro exemplo fornece funcionalidade 700 de um equipamento de usuário (UE) local operável para realizar videoconferência com um UE remoto, conforme mostrado no diagrama de fluxo na Figura 7. A funcionalidade pode ser implantada como um método ou a funcionalidade pode ser executada como instruções em uma máquina, em que as instruções estão incluídas em pelo menos uma mídia legível por computador ou uma mídia de armazenamento legível por máquina não transitória. O UE local pode ter um ou mais processadores configurados para definir, no UE local, uma região de interesse (ROI) dentro de um campo de visão de uma câmera do UE remoto, como no bloco 710. O um ou mais processadores podem ser configurados para mapear a ROI para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF), como no bloco 720. O um ou mais processadores podem ser configurados para enviar o um ou mais comandos de PTZF do UE local para o UE remoto, em que o UE remoto é configurado para identificar a ROI com base no um ou mais comandos de PTZF, como no bloco 730. O um ou mais processadores pode ser configurado para receber vídeo codificado dentro da ROI do UE remoto, sendo que o vídeo codificado inclui regiões dentro da ROI e exclui regiões fora da ROI, sendo que o vídeo codificado inclui as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido para permitir que o vídeo codificado dentro da ROI seja renderizado e exibido no UE local, como no bloco 740.

[0069] Em uma configuração, um primeiro processador pode realizar as operações nos blocos 710 e 720. O primeiro processador pode ser um único processador, ou alternativamente, o primeiro processador pode ser compreendido por um ou mais processadores separados. Em uma configuração, um segundo processador pode realizar as operações nos blocos 730 e 740. Um exemplo do segundo processador é um processador de banda-base.

[0070] Em um exemplo, o um ou mais comandos de PTZF estão de acordo com um protocolo H.281/H.224 da União Internacional de Telecomunicações (ITU). Em outro exemplo, o um ou mais processadores são configurados para enviar o um ou mais comandos de PTZF para o UE remoto em uma única transmissão. Em ainda outro exemplo, a ROI é selecionada por um usuário que interage com o UE local. Adicionalmente, o um ou mais processadores são configurados para enviar o um ou mais comandos de PTZF para o UE remoto com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP).

[0071] Em um exemplo, o um ou mais processadores são configurados para: inserir o um ou mais comandos de PTZF em pelo menos uma extensão de cabeçalho de protocolo de transporte em tempo real (RTP); e enviar vídeo local capturado para o UE remoto, sendo que o vídeo local capturado inclui a extensão de cabeçalho de RTP com o um ou mais comandos de PTZF. Em outro exemplo, o um ou mais processadores são configurados adicionalmente para receber um ou mais tamanhos de etapa, do UE remoto, que são usados no UE remoto para processar o um ou mais comandos de PTZF enviados do UE local.

[0072] Em um exemplo, o um ou mais tamanhos de etapa são sinalizados como atributos de extensão de cabeçalho de protocolo de transporte em tempo real (RTP) dedicados. Em outro exemplo, o vídeo codificado é capturado com o uso de uma câmera fixa sem movimento do UE remoto. Em ainda outro exemplo, um ou mais comandos de PTZF são enviados para o UE remoto de acordo com um protocolo de controle de câmera remota (FECC). Adicionalmente, o um ou mais processadores são configurados adicionalmente para receber a mensagem de oferta de protocolo de descrição de sessão (SDP) do UE remoto que indica que o UE remoto suporta um protocolo de controle de câmera remota (FECC) aprimorado para receber o um ou mais comandos de PTZF.

[0073] Em um exemplo, o um ou mais processadores são configurados adicionalmente para enviar a mensagem de resposta de protocolo de descrição de sessão (SDP) com o reconhecimento de que o UE local suporta um protocolo de controle de câmera remota (FECC) aprimorado para enviar o um ou mais comandos de PTZF. Em outro exemplo, o um ou mais processadores são configurados para enviar o um ou mais comandos de PTZF para o UE remoto, em que o UE remoto é configurado para capturar vídeo dentro da ROI que corresponde ao um ou mais comandos de PTZF e apenas codifica o vídeo dentro da ROI. Em ainda outro exemplo, o um ou mais processadores são configurados adicionalmente para operar um aplicativo de videoconferência com o UE remoto que suporta um recurso de aproximação interativo com base em ROI.

[0074] Outro exemplo, ilustrado no diagrama de fluxo da Figura 8, fornece a funcionalidade 800 de pelo menos uma mídia de armazenamento legível por máquina não transitória que tem instruções inseridas na mesma para operar um aplicativo de videoconferência em um equipamento de usuário (UE) local que suporta um recurso de aproximação interativo. As instruções, quando executadas, podem levar o UE local a realizar identificação, com o uso de pelo menos um processador do UE local, uma região de interesse (ROI) definida por usuário dentro de um campo de visão de uma câmera do UE remoto, como no bloco 810. As instruções, quando executadas, podem levar o UE local a realizar mapeamento, com o uso do pelo menos um processador do UE local, da ROI para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF), como no bloco 820. As instruções, quando executadas, podem levar o UE local a realizar envio, com o uso do pelo menos um processador do UE local, do um ou mais comandos de PTZF do UE local para o UE remoto, em que o UE remoto é configurado para identificar a ROI com base no um ou mais comandos de PTZF, como no bloco 830. As instruções, quando executadas, podem levar o UE local a realizar recebimento, com o uso do pelo menos um processador do UE local, do vídeo codificado dentro da ROI do UE remoto, em que o vídeo codificado inclui regiões dentro da ROI e exclui regiões fora da ROI, sendo que o vídeo codificado inclui as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido, como no bloco 840. As instruções, quando executadas, podem levar o UE local a realizar fornecimento, com o uso do pelo menos um processador do UE local, do vídeo codificado dentro da ROI para renderizar e exibir no UE local, como no bloco 850.

[0075] Em um exemplo, o um ou mais comandos de PTZF estão de acordo com um protocolo H.281/H.224 da União Internacional de Telecomunicações (ITU). Em outro exemplo, o pelo menos um armazenamento legível por máquina não transitório pode compreender adicionalmente instruções que, quando executadas pelo ao menos um processador do UE local, levam o UE local a realizar envio do um ou mais comandos de PTZF para o UE remoto em uma única transmissão. Em ainda outro exemplo, o pelo menos um armazenamento legível por máquina não transitório pode compreender adicionalmente instruções que, quando executadas pelo ao menos um processador do UE local, levam o UE local a realizar envio do um ou mais comandos de PTZF para o UE remoto com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP).

[0076] Em um exemplo, o armazenamento legível por máquina não transitório pode compreender adicionalmente instruções que, quando executadas pelo ao menos um processador do UE local, levam o UE local a realizar: inserir o um ou mais comandos de PTZF em pelo menos uma extensão de cabeçalho de protocolo de transporte em tempo real (RTP); e enviar vídeo local capturado para o UE remoto, sendo que o vídeo local capturado inclui a extensão de cabeçalho de RTP com o um ou mais comandos de PTZF. Em outro exemplo, o armazenamento legível por máquina não transitório pode compreender adicionalmente instruções que, quando executadas pelo ao menos um processador do UE local, levam o UE local a realizar recebimento de um ou mais tamanhos de etapa, do UE remoto, que são usados no UE remoto para processar o um ou mais comandos de PTZF enviados do UE local, em que o um ou mais tamanhos de etapa são sinalizados como atributos de extensão de cabeçalho de protocolo de transporte em tempo real (RTP) dedicados. Adicionalmente, o um ou mais comandos de PTZF são enviados para o UE remoto de acordo com um protocolo de controle de câmera remota (FECC).

[0077] Outro exemplo fornece funcionalidade de um equipamento de usuário (UE) local 900 operável para realizar videoconferência com um UE remoto 950, conforme mostrado no diagrama de fluxo na Figura 9. O UE local 900 pode incluir um módulo de região de interesse (ROI) 910 configurado para identificar uma ROI definida por usuário dentro de um campo de visão de uma câmera do UE remoto 950. O UE local 900 pode incluir um módulo de mapeamento 920 configurado para mapear a ROI para um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF), sendo que o um ou mais comandos de PTZF são definidos de acordo com um protocolo H.281/H.224 da União Internacional de Telecomunicações (ITU). O UE local 900 pode incluir um módulo de comunicação 930 configurado para: enviar o um ou mais comandos de PTZF do UE local para o UE remoto 950 em uma única transmissão, em que o UE remoto é configurado para identificar a ROI com base no um ou mais comandos de PTZF; e receber vídeo codificado dentro da ROI do UE remoto, em que o vídeo codificado inclui regiões dentro da ROI e exclui regiões fora da ROI, sendo que o vídeo codificado inclui as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido. O UE local 900 pode incluir um módulo de exibição 940 configurado para fornecer o vídeo codificado dentro da ROI para renderizar e exibir no UE local.

[0078] Em um exemplo, o módulo de comunicação 930 pode ser configurado adicionalmente para: receber uma mensagem de oferta de protocolo de descrição de sessão (SDP) do UE remoto 950 que indica que o UE remoto suporta um protocolo de controle de câmera remota (FECC) aprimorado para receber o um ou mais comandos de PTZF; e enviar uma mensagem de resposta de protocolo de descrição de sessão (SDP) com o reconhecimento de que o UE local suporta um protocolo de controle de câmera remota (FECC) aprimorado para enviar o um ou mais comandos de PTZF.

[0079] Em um exemplo, o módulo de comunicação 930 pode ser configurado adicionalmente para enviar o um ou mais comandos de PTZF para o UE remoto 950, em que o UE remoto é configurado para capturar vídeo dentro da ROI que corresponde para o um ou mais comandos de PTZF e apenas codifica o vídeo dentro da ROI. Em outro exemplo, o módulo de comunicação 930 pode ser configurado adicionalmente para enviar o um ou mais comandos de PTZF para o UE remoto com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP).

[0080] Outro exemplo fornece funcionalidade 1000 de um equipamento de usuário (UE) remoto operável para realizar videoconferência com um UE local, conforme mostrado no diagrama de fluxo na Figura 10. A funcionalidade pode ser implantada como um método ou a funcionalidade pode ser executada como instruções em uma máquina, em que as instruções estão incluídas em pelo menos uma mídia legível por computador ou uma mídia de armazenamento legível por máquina não transitória. O UE remoto pode ter um ou mais processadores configurados para receber um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF) do UE local, como no bloco 1010. O um ou mais processadores podem ser configurado para identificar, no UE remoto, uma região de interesse (ROI) com base no um ou mais comandos de PTZF, sendo que a ROI está dentro de um campo de visão de uma câmera do UE remoto, como no bloco 1020. O um ou mais processadores podem ser configurado para gerar vídeo codificado dentro da ROI, em que o vídeo codificado inclui regiões dentro da ROI e exclui regiões fora da ROI, sendo que o vídeo codificado inclui as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido, como no bloco 1030. O um ou mais processadores podem ser configurados para enviar o vídeo codificado dentro da ROI para o UE local para permitir que o UE local renderize e exiba o vídeo codificado dentro da ROI, como no bloco 1040.

[0081] Em uma configuração, um primeiro processador pode realizar as operações nos blocos 1010, 1020 e 1030. O primeiro processador pode ser um único processador, ou alternativamente, o primeiro processador pode ser compreendido por um ou mais processadores separados. Em uma configuração, um segundo processador pode realizar a operação no bloco 1040. Um exemplo do segundo processador é um processador de banda-base.

[0082] Em um exemplo, o um ou mais comandos de PTZF estão de acordo com um protocolo H.281/H.224 da União Internacional de Telecomunicações (ITU). Em outro exemplo, o um ou mais processadores são configurados para receber o um ou mais comandos de PTZF do UE local em uma única transmissão. Em ainda outro exemplo, o um ou mais processadores são configurados para receber o um ou mais comandos de PTZF do UE local com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP). Adicionalmente, o um ou mais processadores são configurados adicionalmente para enviar um ou mais tamanhos de etapa para o UE local, em que os tamanhos de etapa são usados no UE remoto para processar o um ou mais comandos de PTZF, sendo que o um ou mais tamanhos de etapa são sinalizados como atributos de extensão de cabeçalho de protocolo de transporte em tempo real (RTP) dedicados.

[0083] A Figura 11 fornece uma ilustração exemplificadora do dispositivo sem fio, tal como um equipamento de usuário (UE), uma estação móvel (MS), um dispositivo móvel sem fio, um dispositivo de comunicação móvel, um computador do tipo tablet, um aparelho telefônico ou outro tipo de dispositivo sem fio. O dispositivo sem fio pode incluir uma ou mais antenas configuradas para se comunicarem com um nó ou estação de transmissão, tais como uma estação-base (BS), um Nó B evoluído (eNB), uma unidade de banda-base (BBU), uma cabeça de rádio remoto (RRH), um equipamento de rádio remoto (RRE), uma estação de relé (RS), um equipamento de rádio (RE), uma unidade de rádio remoto (RRU), um módulo de processamento central (CPM), ou outro tipo de ponto de acesso de rede de longa distância sem fio (WWAN). O dispositivo sem fio pode ser configurado para se comunicar com o uso de pelo menos um padrão de comunicação sem fio, incluindo LTE 3GPP, WiMAX, Acesso de Pacote de Alta Velocidade (HSPA), Bluetooth e Wi-Fi. O dispositivo sem fio pode se comunicar com o uso de antenas separadas para cada padrão de comunicação sem fio ou antenas compartilhadas para múltiplos padrões de comunicação sem fio. O dispositivo sem fio pode se comunicar em uma rede de área local sem fio (WLAN), uma rede de área pessoal sem fio (WPAN) e/ou uma WWAN.

[0084] A Figura 11 também fornece uma ilustração de um microfone e um ou mais alto-falantes que podem ser usados para entrada e saída de áudio do dispositivo sem fio. Uma tela de visor pode ser uma tela de visor de cristal líquido (LCD) ou outro tipo de tela de visor, tal como um visor de diodo emissor de luz orgânico (OLED). A tela de visor pode ser configurada como uma tela de toque. A tela sensível ao toque pode usar uma tecnologia capacitiva, resistiva ou outro tipo de tela sensível ao toque. Um processador de aplicativo e um processador gráfico podem ser acoplados à memória interna para fornecer capacidades de processamento e exibição. Uma porta de memória não volátil também pode ser usada para fornecer opções de entrada/saída de dados a um usuário. A porta de memória não volátil também pode ser usada para expandir as capacidades de memória do dispositivo sem fio. Um teclado pode ser integrado ao dispositivo sem fio ou conectado sem fio ao dispositivo sem fio para fornecer entrada de usuário adicional. Um teclado virtual também pode ser fornecido com o uso da tela sensível ao toque.

[0085] Várias técnicas ou determinados aspectos ou porções dos mesmos podem assumir a forma de código de programa (isto é, instruções) incorporados em mídia tangível, tais como disquetes, memória apenas de leitura de disco compacto (CD-ROMs), memória apenas de leitura de disco compacto, mídia de armazenamento legível por computador não transitória ou qualquer outra mídia de armazenamento legível por máquina em que, quando o código de programa é carregado em uma máquina e executado pela mesma, tal como um computador, a máquina se torna um aparelho para praticar as várias técnicas. O conjunto de circuitos pode incluir hardware, firmware, código de programa, código executável, instruções de computador e/ou software. Uma mídia de armazenamento legível por computador não transitória pode ser uma mídia de armazenamento legível por computador que não inclui sinal. No caso de execução de código de programa em computadores programáveis, o dispositivo de computação pode incluir um processador, uma mídia de armazenamento legível pelo processador (inclusive memória volátil e não volátil e/ou elementos de armazenamento), pelo menos um dispositivo de entrada e pelo menos um dispositivo de saída. A memória volátil e não volátil e/ou elementos de armazenamento pode ser uma memória de acesso aleatório (RAM), memória apenas de leitura programável apagável (EPROM), unidade flash, unidade óptica, disco rígido magnético, unidade de estado sólido ou outra mídia para armazenar dados eletrônicos. O nó e dispositivo sem fio também podem incluir um módulo de transceptor (isto é, transceptor), um módulo de contador (isto é, contador), um módulo de processamento (isto é, processador) e/ou um módulo de relógio (isto é, relógio) ou módulo temporizador (isto é, temporizador). Um ou mais programas que podem implantar ou utilizar as várias técnicas descritas no presente documento podem usar uma interface de programação de aplicativo (API), controles reutilizáveis e semelhantes. Tais programas podem ser implantados em uma linguagem de procedimentos de alto nível ou de programação orientada por objeto para se comunicar com um sistema de computador. Entretanto, o programa (ou programas) pode ser implantado em linguagem ou montagem de máquina, se desejado. De qualquer maneira, a linguagem pode ser uma linguagem compilada ou interpretada e combinada com implantações de hardware.

[0086] Conforme usado no presente documento, o termo processador pode incluir processadores de propósito geral, processadores especializados, tais como VLSI, FPGAs ou outros tipos de processadores especializados, assim como processadores de banda-base usados em transceptores para enviar, receber e processar comunicações sem fio.

[0087] Deve-se compreender que diversas das unidades funcionais descritas neste relatório descritivo foram identificadas como módulos, a fim de enfatizar mais particularmente sua independência de implantação. Por exemplo, um módulo pode ser implantado como um circuito de hardware que compreende circuitos de integração de larguíssima escala (VLSI) personalizada ou arranjos de porta, semicondutores de prateleira tais como chips lógicos, transistores ou outros componentes discretos. Um módulo também pode ser implantado em dispositivos de hardware programáveis, tais como arranjos de porta programável em campo, lógica de arranjo programável, dispositivos lógicos programáveis ou semelhantes.

[0088] Em um exemplo, múltiplos circuitos de hardware ou múltiplos processadores podem ser usados para implantar as unidades funcionais descritas nesse relatório descritivo. Por exemplo, um primeiro circuito de hardware ou um primeiro processador pode ser usado para realizar operações de processamento e um segundo circuito de hardware ou um segundo processador (por exemplo, um transceptor) pode ser usado para se comunicar com outras entidades. O primeiro circuito de hardware e o segundo circuito de hardware podem ser integrados em um único circuito de hardware, ou alternativamente, o primeiro circuito de hardware e o segundo circuito de hardware podem ser circuitos de hardware separados.

[0089] Os módulos também podem ser implantados em software para a execução através de vários tipos de processadores. Um módulo identificado de código executável pode, por exemplo, compreender um ou mais blocos físicos ou lógicos de instruções de computador, que podem, por exemplo, ser organizados como um objeto, procedimento ou função. Contudo, os códigos executáveis de um módulo identificado não precisam estar localizados fisicamente em conjunto, mas podem compreender instruções distintas armazenadas em locais diferentes que, quando unidas logicamente, compreendem o módulo e alcançam o propósito determinado para o módulo.

[0090] De fato, um módulo de código executável pode ser uma instrução única ou muitas instruções e pode até ser distribuído em diversos segmentos de código diferentes, dentre programas diferentes e através de diversos dispositivos de memória. De modo similar, os dados operacionais podem ser identificados e ilustrados no presente documento em módulos e podem ser incorporados em qualquer forma adequada e organizados em qualquer tipo adequado de estrutura de dados. Os dados operacionais podem ser coletados como um único conjunto de dados ou podem ser distribuídos em locais diferentes, inclusive em dispositivos de armazenamento diferentes, e podem existir, pelo menos parcialmente, apenas como sinais eletrônicos em um sistema ou uma rede. Os módulos podem ser passivos ou ativos, incluindo agentes operáveis para realizar funções desejadas.

[0091] Ao longo deste relatório descritivo é feita referência a “um exemplo” ou “exemplificativo”, que significa que um recurso, estrutura ou característica específico descrito em relação ao exemplo é incluído em pelo menos uma modalidade da presente invenção. Dessa forma, a ocorrência das frases “em um exemplo” ou da palavra “exemplificativo” em vários lugares ao longo deste relatório descritivo não se referem, necessariamente, todas à mesma modalidade.

[0092] Conforme usado no presente documento, uma pluralidade de itens, elementos estruturais, elementos de composição e/ou materiais pode ser apresentada em uma lista comum a título de conveniência. Entretanto, tais listas devem ser interpretadas como se cada membro da lista fosse individualmente identificado como um membro exclusivo e separado. Assim, nenhum membro individual de tal lista deve ser considerado como um equivalente de fato de qualquer outro membro da mesma lista somente com base em sua apresentação em um grupo comum sem indicações do contrário. Além disso, várias modalidades e exemplos da presente invenção podem ser citados no presente documento juntamente com alternativas para os vários componentes da mesma. Entende-se que tais modalidades, exemplos e alternativas não devem ser interpretados como equivalentes de fato uns dos outros, mas devem ser considerados como representações separadas e autônomas da presente invenção.

[0093] Além disso, os recursos, estruturas ou características descritas podem ser combinados de qualquer maneira adequada em uma ou mais modalidades. Na descrição a seguir, diversos detalhes específicos são fornecidos, tais como exemplos de gabaritos, distâncias, exemplos de rede, etc., para fornecer um entendimento completo das modalidades da invenção. Uma pessoa versada na técnica relevante reconhecerá, no entanto, que a invenção pode ser praticada sem um ou mais dos detalhes específicos, ou com outros métodos, componentes, gabaritos, etc. Em outros casos, estruturas, materiais ou operações bem conhecidos não são mostrados ou descritos em detalhes para evitar obscurecer aspectos da invenção.

[0094] Embora os exemplos precedentes sejam ilustrativos dos princípios da presente invenção em uma ou mais aplicações particulares, será evidente àqueles de habilidade comum na técnica que várias modificações na forma, uso e detalhes de implantação podem ser feitas sem o exercício de faculdade inventiva, e sem se afastar dos princípios e conceitos da invenção. Consequentemente, a invenção não se destina a ser limitada, exceto pelas reivindicações estabelecidas abaixo.

Claims (22)

1. Equipamento de usuário (UE) local operável para realizar videoconferência com um UE remoto, o UE local caracterizado por ter um ou mais processadores configurados para: receber um ou mais tamanhos de etapa, do UE remoto, que são usados no UE remoto para processar um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF) enviados do UE local, em que os um ou mais tamanhos de etapa são sinalizados como atributos de extensão de cabeçalho de protocolo de transporte em tempo real (RTP) dedicados, definir, no UE local, uma região de interesse (ROI) dentro de um campo de visão de uma câmera do UE remoto; mapear a ROI para um ou mais comandos (PTZF) baseado nos um ou mais tamanhos de etapa; enviar os um ou mais comandos de PTZF do UE local para o UE remoto, em que o UE remoto é configurado para identificar a ROI com base nos um ou mais comandos de PTZF; e receber vídeo codificado dentro da ROI a partir do UE remoto, sendo que o vídeo codificado inclui regiões dentro da ROI e exclui regiões fora da ROI, sendo que o vídeo codificado inclui as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido para permitir que o vídeo codificado dentro da ROI seja renderizado e exibido no UE local.

2. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais comandos de PTZF estão de acordo com um protocolo H.281/H.224 da União Internacional de Telecomunicações (ITU).

3. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais processadores são configurados para enviar o um ou mais comandos de PTZF para o UE remoto em uma única transmissão.

4. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que a ROI é selecionada por um usuário que interage com o UElocal.

5. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais processadores são configurados para enviar o um ou mais comandos de PTZF para o UE remoto com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP).

6. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais processadores são configurados para: inserir o um ou mais comandos de PTZF em pelo menos uma extensão de cabeçalho de protocolo de transporte em tempo real (RTP); e enviar vídeo local capturado para o UE remoto, sendo que o vídeo local capturado inclui a extensão de cabeçalho de RTP com o um ou mais comandos de PTZF.

7. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o vídeo codificado é capturado com o uso de uma câmera fixa sem movimento do UE remoto.

8. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que um ou mais comandos de PTZF são enviados para o UE remoto de acordo com um protocolo de controle de câmera remota (FECC).

9. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais processadores são configurados adicionalmente para receber uma mensagem de oferta de protocolo de descrição de sessão (SDP) do UE remoto que indica que o UE remoto suporta um protocolo de controle de câmera remota (FECC) aprimorado para receber o um ou mais comandos de PTZF.

10. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais processadores são configurados adicionalmente para enviar uma mensagem de resposta de protocolo de descrição de sessão (SDP) com o reconhecimento de que o UE local suporta um protocolo de controle de câmera remota (FECC) aprimorado para enviar o um ou mais comandos de PTZF.

11. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais processadores são configurados para enviar o um ou mais comandos de PTZF para o UE remoto, em que o UE remoto é configurado para capturar vídeo dentro da ROI que corresponde ao um ou mais comandos de PTZF e apenas codifica o vídeo dentro da ROI.

12. Equipamento de usuário (UE), de acordo com a reivindicação 1, caracterizado pelo fato de que o um ou mais processadores são configurados adicionalmente para operar um aplicativo de videoconferência com o UE remoto que suporta um recurso de aproximação interativo com base em ROI.

13. Mídia de armazenamento legível por má-quina não transitória, pelo menos uma, caracterizada por ter instruções inseridas na mesma para operar um aplicativo de videoconferência em um equipamento de usuário (UE) local que suporta um recurso de aproximação interativo, sendo que as instruções, quando executadas, levam o UE local a realizar o seguinte: receber um ou mais tamanhos de etapa, do UE remoto, que são usados no UE remoto para processar o um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF) enviados do UE local, em que os um ou mais tamanhos de etapa são sinalizados como atributos de extensão de cabeçalho de protocolo de transporte em tempo real (RTP) dedicados, identificar, com o uso de pelo menos um processador do UE local, uma região de interesse (ROI) definida por usuário dentro de um campo de visão de uma câmera do UE remoto; mapear, com o uso do pelo menos um processador do UE local, a ROI para um ou mais comandos (PTZF); baseado no um ou mais tamanhos de etapa enviar, com o uso do pelo menos um processador do UE local, o um ou mais comandos de PTZF do UE local para o UE remoto, em que o UE remoto é configurado para identificar a ROI com base no um ou mais comandos de PTZF; receber, com o uso do pelo menos um processador do UE local, vídeo codificado dentro da ROI do UE remoto, sendo que o vídeo codificado inclui regiões dentro da ROI e exclui regiões fora da ROI, sendo que o vídeo codificado inclui as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido; e fornecer, com o uso do pelo menos um processador do UE local, o vídeo codificado dentro da ROI para renderizar e exibir no UE local.

14. Mídia, de acordo com a reivindicação 13, caracterizada pelo fato de que o um ou mais comandos de PTZF estão de acordo com um protocolo H.281/H.224 da União Internacional de Telecomunicações (ITU).

15. Mídia, de acordo com a reivindicação 13, caracterizada pelo fato de que compreende adicionalmente instruções que, quando executadas pelo ao menos um processador do UE local, levam o UE local a realizar o seguinte: enviar o um ou mais comandos de PTZF para o UE remoto em uma única transmissão.

16. Mídia, de acordo com a reivindicação 13, caracterizada pelo fato de que compreende adicionalmente instruções que, quando executadas pelo ao menos um processador do UE local, levam o UE local a realizar o seguinte: enviar o um ou mais comandos de PTZF para o UE remoto com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP).

17. Mídia, de acordo com a reivindicação 13, caracterizada pelo fato de que compreende adicionalmente instruções que, quando executadas pelo ao menos um processador do UE local, levam o UE local a realizar o seguinte: inserir o um ou mais comandos de PTZF em pelo menos uma extensão de cabeçalho de protocolo de transporte em tempo real (RTP); e enviar vídeo local capturado para o UE remoto, sendo que o vídeo local capturado inclui a extensão de cabeçalho de RTP com o um ou mais comandos de PTZF.

18. Mídia, de acordo com a reivindicação 14, caracterizada pelo fato de que o um ou mais comandos de PTZF são enviados para o UE remoto de acordo com um protocolo de controle de câmera remota (FECC).

19. Equipamento de usuário (UE) remoto operável para realizar videoconferência com um UE local, sendo que o UE remoto é caracterizado pelo fato de que tem um ou mais processadores configurados para: receber um ou mais comandos de panoramização, inclinação, aproximação e foco (PTZF) do UE local; identificar, no UE remoto, uma região de interesse (ROI) com base no um ou mais comandos de PTZF, sendo que a ROI está dentro de um campo de visão de uma câmera do UE remoto; enviar um ou mais tamanhos de etapa para o UE local, os tamanhos de etapa sendo usados no UE remoto para processar um ou mais comandos PTZF, em que um ou mais tamanhos de etapa são sinalizados como extensão de cabeçalho de protocolo de transporte em tempo real (RTP) dedicado atributos; gerar vídeo codificado dentro da ROI, sendo que o vídeo codificado inclui regiões dentro da ROI e exclui regiões fora da ROI, sendo que o vídeo codificado inclui as regiões dentro da ROI em um nível de aproximação aumentado ao mesmo tempo que mantém substancialmente um nível de qualidade definido; e enviar o vídeo codificado dentro da ROI para o UE local para permitir que o UE local renderize e exiba o vídeo codificado dentro da ROI.

20. Equipamento de usuário (UE), de acordo com a reivindicação 19, caracterizado pelo fato de que o um ou mais comandos de PTZF estão de acordo com um protocolo H.281/H.224 da União Internacional de Telecomunicações (ITU).

21. Equipamento de usuário (UE), de acordo com a reivindicação 19, caracterizado pelo fato de que o um ou mais processadores são configurados para receber o um ou mais comandos de PTZF do UE local em uma única transmissão.

22. Equipamento de usuário (UE), de acordo com a reivindicação 19, caracterizado pelo fato de que o um ou mais processadores são configurados para receber o um ou mais comandos de PTZF do UE local com o uso de uma mensagem de retroalimentação de protocolo de controle de transporte em tempo real (RTCP).