​
​
Em primeira instância, o Skype foi estreado com codecs de voz desenvolvidos pela Global IP Solutions: iSAC (Internet Speech Audio Codec) e iLBC (Internet Low Bitrate Codec). A escolha entre estes baseia-se na largura de banda disponível. Como tal, é possível distinguir ambos tendo como critério o débito binário. Por um lado, o débito binário do iSAC é variável estando limitado entre os 10kb/s e 32kb/s. Por outro lado, no caso do iLBC, este valor é fixo para tramas com igual duração, correspondendo a 15.2kb/s para tramas de 20 ms e 13.33kb/s para tramas de 30 ms.
Posteriormente, surgiram os codecs G.729 e SVOPC (Sinusoidal Voice Over Packet Coder). O primeiro destinava-se preferencialmente para chamadas end-to-out, enquanto que em chamadas entre utilizadores do Skype era utilizada preferencialmente a o segundo protocolo. O SVOPC foi implementado inicialmente na versão 3.2 beta do Skype, tendo sido desenhado especialmente para canais de comunicação susceptíveis a perdas de pacotes. No entanto, a ineficiência do algoritmo em sistemas embutidos motivou a sua substituição pelo codec SILK em 2009.
O SILK não só possibilitou a extensão da aplicação para dispositivos, com limitações no seu desempenho, como reduziu significativamente a largura de banda utilizada, registando uma variação no débito binário entre 6kb/s até 40kbits/s. Várias técnicas como a DTX (Discontinuous Transmission), que permite reduzir o débito binário durante períodos de silêncio ou barulho de fundo, e o processamento de fala baseado em linear predictive coding (LPC) são características deste codec.
Por fim, da integração das funcionalidades do SILK com o codec Constrained Energy Lapped Transform (CELT), desenvolvido pela Xiph.Org Foundation e concebido no sentido de transmitir áudio com um delay mínimo, resultou o codec Opus . O Opus tem autoria da IEFT (Internet Engineering Task Force), tendo sido desenvolvido a pedido do Skype. Ora, a interoperabilidade deste standard é bastante vasta, sendo possível aplicá-lo a diversas aplicações de áudio. Este protocolo é escalável entre fala com baixo débito binário até música stereo de alta qualidade. Entre as principais features do codec utilizado podemos destacar:
​
-
Débitos binários desde 6 kb/s até 510 kb/s;
-
Frequências de amostragem desde 8 kHz até 48 kHz;
-
Frame sizes desde 2.5 ms até 60 ms;
-
Suporta mono e stereo;
-
Suporta até 255 (multistream frames);
-
Ajuste dinâmico do débito binário, largura de banda de áudio e frame size;
-
Robustez relativamente à perda de pacotes.​
​
​
Os codecs de vídeo implementados na aplicação surgiram, logicamente, quando a funcionalidade de videochamada foi disponibilizada em 2005. O VP7, desenvolvido pela On2 Technologies, Inc., foi o primeiro codec adoptado. À semelhança de esquemas de compressão actuais, o princípio de funcionamento do VP7 está assente na exploração da redundância temporal e espacial dos sinais, utilizando modelos probabilísticos sofisticados. Neste caso, são distinguidos dois tipos de tramas: intra (key) e inter. Estas são decompostas em blocos de pixéis quadrados de igual dimensão. No entanto, por um lado, como o a sua nomenclatura sugere, as tramas da categoria intra são descodificadas do modo independente em relação a qualquer outra trama na sequência, sendo responsáveis pelo acesso aleatório. Por outro lado, as frames da categoria inter são codificadas tendo como referência tramas antecedentes na sequência, incluindo a mais recente key frame. Por cada inserção deste tipo de frames é obtida informação de sobre o deslocamento de cada macrobloco de uma trama para outra, através de vectores de movimento. A análise tolerância e sensibilidade do sistema visual humano, relativamente diversas componentes na frequência, recorrendo à Discrete Cosine Transform (DCT), possibilita também optimizar o processo de quantização. Ora, isto implica que o codec é lossy.
Posteriormente, devido à implementação da funcionalidade de videoconferência, foi adoptado o codec VP8, desenvolvido novamente pela On2 Technologies, Inc., após a sua aquisição por parte da Google. Contudo, inicialmente, o codec era aplicado especificamente para este propósito tendo só, em 2011, substituído por completo o codec VP7. O princípio de funcionamento, neste caso, é em muitos aspectos semelhante ao descrito anteriormente oferecendo, no entanto, mecanismos que contribuem para a não só para a melhoria da eficiência de compressão e da protecção contra erros como também conduzem à diminuição da complexidade do descodificador e tempos de atraso.
De modo a possibilitar a realização de videochamadas em alta definição, tendo em conta a importância crescente de novas redes de acesso, surgiu a norma H.264/AVC, desenvolvida pelo ITU-T Video Coding Experts Group em conjunto com ISO/IEC JTC1 Moving Picture Experts Group (MPEG), com o objectivo de alcançar uma capacidade de compressão de cerca do dobro melhor solução previamente existente. A norma foi adoptada pelo Skype a partir da versão 7.0. Esta difere das normas anteriores, no sentido em que é implementada uma predição bidirecional que permite a codificação de transições ou diferenças de intensidade de modo mais eficiente. Quer isto dizer que, numa sequência de tramas, a predição parte de tramas temporalmente antecedentes e sucessoras sendo feita, neste caso, por tramas da categoria inter denominadas B. Adicionalmente, tramas denominadas P, efectuam a predição unidirecional baseada, portanto, em tramas antecedentes.
É importante referir que são definidos dos níveis conceptuais, já que o desempenho do sistema depende não só da codificação, mas também de uma boa integração e adaptação em diversas arquitecturas de rede e protocolos:
-
Camada de codificação de vídeo (VCL) – constituída pelos mecanismos de codificação e descodificação de vídeo;
-
Camada de adaptação à rede (NAL) – efectua a conversão do fluxo gerado para um determinado mecanismo de transporte ou armazenamento.
Codecs de Vídeo
