Contexto e necessidade de mercado

Com o desenvolvimento de codificadores de áudio e vídeo de alta eficiência, tornou-se possível a distribuição deste tipo de conteúdos a débitos compatíveis com a Internet. Depois de um breve fulgor com o aparecimento do streaming, ele restringiu-se praticamente apenas a rádios online. Apenas com a massificação da banda larga se assistiu à adopção generalizada de streaming de vídeo, dando origem a sites como YouTube.

A forma usual de transmissão na Internet é uma forma de unicasting: o servidor envia uma stream a cada cliente, criando um fluxo de dados "um para um". Se, por exemplo, se trata de um canal de televisão em directo, a stream é idêntica para todos os clientes, o que significa que o servidor está a gastar largura de banda para enviar o que, efectivamente, são os mesmos dados a todos os clientes.

Arquitectura unicast

Para acabar com este desperdício de recursos, desenvolveu-se o multicasting: neste sistema o servidor apenas envia uma stream, e são os routers da rede que fazem replicação as vezes necessárias para "atingir" cada cliente, criando-se um fluxo "um para muitos" (note-se que este conceito é precisamente o da televisão tradicional). Evita-se, assim, a redundância e desperdício de largura de banda. Todavia, devido à dimensão da Internet, a implementação de multicasting implica bastante complexidade e, por isso, e apesar de ser um tema em contínua discussão, não está disponível na Internet em geral.

Portanto, não havendo multicasting, rapidamente se começou a chegar à conclusão que os custos de largura de banda (com unicasting) para grandes audiências tornam o streaming de vídeo bastante caro, e os custos aumentam com o aumento dos espectadores. Desta maneira, apenas os fornecedores com capacidade económica suficiente se podem dar ao luxo de fazerem streaming aos seus conteúdos, sobretudo conteúdos televisivos.
Devido à rápida popularidade que a Internet permite, isto tem também o efeito de que até uma stream mais “obscura” se arrisca a necessitar de grande largura de banda caso, por alguma razão, fique conhecida subitamente –  efeito de “flash crowds”, que acontecem sobretudo em sites de notícias – o que tem implicações, não só a nível de custos, como de infra-estrutura.

O previsível aumento da utilização do streaming trouxe, assim, um "bandwidth crunch", onde os fornecedores de conteúdos são cada vez mais penalizados pela popularidade dos mesmos.

Surge, assim, a necessidade de um sistema que se aproxime do multicasting, retirando parte do esforço do(s) servidor(es) e partilhando-o com os restantes intervenientes na rede. Uma vez que esta não tem essa funcionalidade, a alternativa óbvia é passá-lo para as extremidades dela: os clientes.

Esse sistema de partilha já existe, na forma das muito populares redes Peer-to-Peer ("P2P") que, inclusivamente, são usadas sobretudo para distribuição de conteúdos multimédia. Porque não, então, aplicar este conceito também ao streaming dos mesmos?

(voltar ao topo)

Problemas do paradigma P2P aplicado a streaming

Os usuais sistemas de P2P usam-se para transferência de ficheiros. Nesta aplicação não há prazos temporais, nem problemas de sequência ou congestão – as diversas partes do ficheiro podem chegar em qualquer ordem, e podem demorar o tempo que for necessário.
Em streaming, contudo, põe-se o problema de que os dados têm de ser recebidos atempadamente (e com metas temporais muito exigentes) e na sequência correcta (ou com apenas pequenos desvios). Isto exige que cada peer tenha um controlo muito rigoroso sobre que parte dos dados tem e que partes pode obter dos seus vizinhos.

Um problema que surge, sobretudo quando se trata de vídeo, é que a maior parte dos peers poderá ter débito de upload menor que o ritmo binário da stream – isto significa que apenas os peers com débitos mais altos podem contribuir para a distribuição, o que, em parte, nega a vantagem do P2P. A forma de contornar este problema é dividir a stream em várias partes, de modo a que até peers com débitos de upload mais baixos possam contribuir. Esta divisão pode ser feita de várias maneiras, por exemplo várias "substreams" que podem ser criadas através da, ainda experimental, MDC do áudio/vídeo, ou usando FEC (por exemplo, no Octoshape); outra maneira é a divisão em blocos sequenciais, como fazem os derivados do BitTorrent.

A outra principal questão prende-se com a topologia da rede overlay.
A forma mais simples é a de uma árvore, em que a raiz é o servidor original do conteúdo, e com peers em cada nó. Cada peer recebe a stream do nó pai e envia-a para os filhos. O inconveniente desta forma é que cada peer fica dependente dos seus ascendentes; qualquer falha ou congestionamento dos nós perto da raiz poderá, assim, afectar um grande número de peers. Para lidar com este problema usam-se várias técnicas, por exemplo, existirem árvores redundantes e cada peer ligar-se a várias em paralelo; haver gestão centralizada da topologia, etc. Exemplos de sistemas que usam este tipo de topologia são o PeerCast e o FreeCast.
A outra forma de topologia é em grelha, em que cada peer se liga a outros, sem haver hierarquia. Isto exige um sistema mais complexo, tanto em termos de programação, como em termos do que cada peer tem de fazer para gestão da rede – exige que troquem entre si, não só a stream propriamente dita, mas também informações exactas sobre as suas capacidades e que partes do espaço de dados têm. Devido ao carácter da Internet e dos próprios peers, esta informação pode não ser fiável, portanto os sistemas têm de ser capazes de se adaptar a imprevistos – embora isto também aconteça com a topologia árvore, nessa apenas se tem de lidar com o pai, enquanto que na grelha se tem de lidar com vários peers. Este tipo de topologia também pode ser gerida centralmente.

Arquitectura P2PTV em grelha (Abacast)

Praticamente todos os sistemas mais recentes usam a topologia em grelha para transferências de dados, devido à sua maior robustez - uma vez que os peers são PCs, não existem problemas em usar algoritmos mais complexos. Os serviços que têm gestão centralizada normalmente usam uma rede secundária apenas para a gestão e controlo, com topologia em árvore.

Isto leva-nos, finalmente, ao problema do que fazer em caso de falhas na rede. Na maior parte dos sistemas, os peers recorrem ao servidor original em ultimo recurso, caso não consigam adquirir os dados atempadamente de outros peers. Todos os sistemas têm um imprescindível buffer, que assegura que existem sempre dados suficientes para continuar a reprodução ininterrupta enquando o cliente tenta encontrar e receber os dados. Neste caso aplica-se o inevitável compromisso de qualquer sistema de streaming: maior buffer dá maior robustez, mas também aumenta o atraso.

(voltar ao topo)

Sistemas existentes

Os sistemas existentes podem dividir-se em dois grupos: comerciais e livres.

Por seu lado, os sistemas comerciais podem ser simples prestadores de serviços a um broadcaster, funcionando de forma semelhante a uma CDN (o cliente é o broadcaster), ou então algo análogo a um prestador de serviço de televisão convencional (o cliente é o espectador).
No primeiro caso, o objectivo do serviço é complementar, ou até substituir, uma CDN.
O fornecedor do serviço recebe os conteúdos e distribui-os pela rede P2P. Isto pode ser feito de muitas formas, desde um simples “add-on” por software no servidor do broadcaster, até a hardware e ligações específicas à Internet.
O espectador apenas tem de instalar um pequeno programa cliente (há alguns sistemas que são simples o suficiente para permitir a criação de clientes em Flash ou applets Java, e nesses casos nem é necessária instalação), e aceder à stream, tipicamente por browser Web ou media player. O programa cliente encarrega-se de fazer as ligações ao servidor e outros clientes na rede, fazendo o download da stream à medida que for necessário, bem como fazendo o upload para outros clientes – tudo isto de forma transparente ao espectador.

Os sistemas livres permitem a qualquer utilizador ser um broadcaster, apenas com algum software e um PC com capacidade de captura de vídeo. Os mais actual é o acima mencionado FreeCast.
Existe uma excepção à regra, que é o sistema da TVUnetworks, que também permite a qualquer um ser broadcaster gratuitamente, todavia o sistema é comercial e depende de publicidade no interface.

Os sistemas podem, também, dividir-se em relação à entrega dos conteúdos: linear ou não linear. Entrega linear refere-se a sistemas semelhantes à televisão e rádio convencionais, em que os conteúdos são produzidos e “consumidos” na mesma altura, em tempo real. Entrega não linear refere-se a sistemas “on-demand”, em que os conteúdos existem armazenados algures apenas são transmitidos quando alguém estiver interessado no seu “consumo”.
Repare-se que esta última é a forma de funcionamento dos sistemas P2P tradicionais, em que os conteúdos existem em um ou mais nós na rede, que por sua vez os enviam aos eventuais interessados. De facto, muitos dos sistemas apelidados (talvez erroneamente) de P2PTV, não são mais do que sistemas P2P normais, apenas com mecanismos de procura, indexação e reprodução de música e vídeo incluídos (Tribler, Miro, OMN...)

(voltar ao topo)