Planeta Globo.com

Essa semana o pessoal do Gmail introduziu a opção de chat com áudio e vídeo em seu serviço de e-mail, conforme anunciado aqui.

Como assim?

Como pode ser visto aqui, o serviço é baseado em padrões de internet, como o XMPP (comunicação), RTP (transporte em tempo real) e utiliza uma extensão do codec H.264/MPEG-4 AVC para codificação do vídeo, o SVC, provavelmente integrando a solução da Vidyo.

E o delivery do vídeo?

De início, imaginei em algo como o plugin realizando algum tipo de publicação dos streams via RTP/UDP num servidor de mídias (Flash Media Server, Red5, Wowza…) no Google, que por sua vez, faria o transporte dos streams para o cliente Flash Player na máquina do outro usuário, no caso do FMS via RTMP.

Ou, que o plugin ficasse esperando por requisições na máquina local (como num servidor HTTP) e enviasse o live stream mascarado em download progressivo.

Com relação ao mini vídeo que exibe a imagem da câmera local, a estória deveria ser a mesma: o plugin pegando os frames da câmera, criando o stream RTP/UDP e consumindo internamente este stream para exibição.

Pesquisando mais um pouco, vi que a 2a opção fazia mais sentindo. Isso porque a solução utiliza a implementação do Jingle contida na libjingle - desenvolvida pelo Google com foco em aplicações multimídia para múltiplos usuários - que gerencia desde as conexões de rede até a negociação das sessões (incluindo código relacionado à utilização de codecs e ao transporte dos streams) e a troca de dados:

“Jingle is an extension to the Jabber/XMPP protocol, to allow for peer-to-peer (p2p) signalling for multimedia interactions such as voice or video. It was designed by Google and the XMPP Standards Foundation. The multimedia content itself can be delivered using the Real-time Transport Protocol, with Interactive Connectivity Establishment (ICE) for NAT traversal.”

Dessa forma, como em qualquer aplicação peer-to-peer, a comunicação entre os usuários acontece diretamente entre suas máquinas através do referido plugin com a utilização desta lib, dispensando a necessidade de servidores controlando a mesma.

E o que mais?

O plugin ignora o fato de você permitir ou não o acesso à câmera, mas tudo bem.

O ponto fraco é o fato de o plugin ainda não estar disponível para Linux…

Essa semana o pessoal do Gmail introduziu a opção de chat com áudio e vídeo em seu serviço de e-mail, conforme anunciado aqui.

Como assim?

Como pode ser visto aqui, o serviço é baseado em padrões de internet, como o XMPP (comunicação), RTP (transporte em tempo real) e utiliza uma extensão do codec H.264/MPEG-4 AVC para codificação do vídeo, o SVC, provavelmente integrando a solução da Vidyo.

E o delivery do vídeo?

De início, imaginei em algo como o plugin realizando algum tipo de publicação dos streams via RTP/UDP num servidor de mídias (Flash Media Server, Red5, Wowza…) no Google, que por sua vez, faria o transporte dos streams para o cliente Flash Player na máquina do outro usuário, no caso do FMS via RTMP.

Ou, que o plugin ficasse esperando por requisições na máquina local (como num servidor HTTP) e enviasse o live stream mascarado em download progressivo.

Com relação ao mini vídeo que exibe a imagem da câmera local, a estória deveria ser a mesma: o plugin pegando os frames da câmera, criando o stream RTP/UDP e consumindo internamente este stream para exibição.

Pesquisando mais um pouco, vi que a 2a opção fazia mais sentindo. Isso porque a solução utiliza a implementação do Jingle contida na libjingle - desenvolvida pelo Google com foco em aplicações multimídia para múltiplos usuários - que gerencia desde as conexões de rede até a negociação das sessões (incluindo código relacionado à utilização de codecs e ao transporte dos streams) e a troca de dados:

“Jingle is an extension to the Jabber/XMPP protocol, to allow for peer-to-peer (p2p) signalling for multimedia interactions such as voice or video. It was designed by Google and the XMPP Standards Foundation. The multimedia content itself can be delivered using the Real-time Transport Protocol, with Interactive Connectivity Establishment (ICE) for NAT traversal.”

Dessa forma, como em qualquer aplicação peer-to-peer, a comunicação entre os usuários acontece diretamente entre suas máquinas através do referido plugin com a utilização desta lib, dispensando a necessidade de servidores controlando a mesma.

E o que mais?

O plugin ignora o fato de você permitir ou não o acesso à câmera, mas tudo bem.

O ponto fraco é o fato de o plugin ainda não estar disponível para Linux…