Por que eu devo ler este artigo:Neste artigo veremos como fazer streaming com diferentes protocolos no Windows Phone 8. Será usado o Background Audio Agent com Download Progressivo para deixarmos o streaming em background. Além disso, um player de música será mostrado no final do artigo.

Com o crescimento de sites de música na internet, é cada vez mais comum termos aplicativos auxiliares para smartphones como Rdio, IdeasMusik, Sonora, Spotify e Palco MP3. Os grandes servidores de informação usam ferramentas para auxiliar na entrega do conteúdo como WOWZA, que tem limitações e protocolos específicos na hora do envio da informação.

Com a popularização dos smartphones e uma melhor banda de dados no Brasil, um novo serviço começou a despontar na internet: o serviço de música por demanda. Grandes empresas entraram no mercado, onde o usuário deixa de pagar por músicas individuais e paga por planos semanais, mensais ou anuais para escutar músicas à vontade na internet.

Os serviços disponibilizam catálogos atualizados e grandes acervos que podem deixar o player tocando meses sem repetir nenhuma música.

Nesse cenário iremos usar os serviços do IdeasMusik, o maior portal de conteúdo da América Latina, atualmente com atuação em 17 países e um acervo de milhões de músicas.

Para um player consumir streaming da internet devemos saber inicialmente se será uma transmissão ao vivo ou um consumidor de conteúdo. Também é necessário saber da necessidade de bufferizar essa informação, se pode ser armazenada pelo usuário, se terá algum DRM (Digital Rights Management) no arquivo e, principalmente, se minha plataforma de desenvolvimento suporta a tecnologia. Depois dessas validações poderemos escolher com mais segurança qual protocolo poderemos usar no aplicativo.

Para ajudar na escolha do protocolo ideal, primeiro devemos entender um pouco qual a diferença entre eles.

Em uma transmissão ao vivo, onde o consumo e descarte de pacotes de informação é constante e não há necessidade de grandes buffers para armazenar informação, devemos pensar em usar o RTSP (Real Time Streaming Protocol), que é um protocolo em nível de aplicação que controla a transferência de áudio e vídeo em tempo real, podendo ter um ou mais streams sincronizados - tendo como padrão o uso da porta 554. Uma analogia seria a ideia de transmissão atual de TV aberta, onde existe um broadcast enviando informação constante e o receptor decodifica essa informação e interpreta na tela, sem nenhum armazenamento de informação.

Conforme os pacotes vão chegando, vão sendo interpretados na TV e mesmo faltando pacotes na transmissão, a mesma não cai e continua transmitindo assim que os pacotes chegam.

O Smooth Streaming é uma extensão do IIS Media Service, que tenta prover uma transmissão de alta qualidade com o mínimo consumo de buffer e uma inicialização muito mais rápida, se aproximando ao máximo da ideia de Real Time Transmission. Por ser uma solução Microsoft, é pouco usada em outras plataformas e no próprio Windows Phone tem suas limitações - que veremos mais adiante.

No caso do Download Progressivo, o mais popular e comum na internet, na medida em que os pacotes são recebidos, os mesmos são bufferizados e quando têm informações suficientes, conseguem ser interpretados. Apesar da bufferização, o Download Progressivo tem uma resposta excelente e uma gama de aceitação maior ainda. Utilizaremos este protocolo para criação do nosso player.

Smooth Streaming, uma solução suave

A Microsoft usou pela primeira vez a solução de smooth streaming nas Olimpíadas de verão de 2008, com uma proposta de monitoramento dinâmico de banda de transmissão e alta performance na renderização de vídeo. Em resumo, quem tinha uma melhor conexão teria uma transmissão de alta qualidade (1080p) e quem tinha pouca banda ou um computador mais lento, receberia uma transmissão inferior, que equivalesse melhor com seu equipamento.

Com o smooth streaming, empresas encontraram a melhor forma de fazer transmissões Full HD na internet, pois se utiliza um conceito simples, porém poderoso de envio de pequenos fragmentos do streaming (cerca de dois segundos) que são validados por sua integridade antes de ser interpretados.

Conforme apresenta a Figura 1, o conteúdo gerado por uma transmissão de uma câmera de TV (ao vivo) está sendo enviado para o servidor IIS, em alguns casos podemos utilizar um servidor extra de cache de informações, antes de serem enviadas, criando uma redundância para ajudar na escolha dos tipos de banda conectadas.

Pequenos fragmentos do vídeo são enviados para o consumidor, conforme a qualidade da sua conexão. A qualidade do conteúdo é alterada sobre demanda em tempo de execução.

Figura 1. Esquema de Transmissão via Smooth Streaming.

Real Time Streaming Protocol

Como o próprio nome já diz, o RTSP foi projetado para uso de sistemas de comunicação e entretenimento para transmissões em tempo real e é usado para estabilizar e controlar sessões entre pontos. Dentre suas características, as principais são o total controle do buffer, melhor controle de pacotes de rede e uma rápida transferência de streaming. Por isso, é o mais utilizado para transferência de conteúdos ao vivo (entrevistas, shows, programas).

O RTSP é baseado no transporte via UDP, que suporta melhor a perda de pacotes durante a transmissão. Havendo uma perda de fluxo de pacotes a conexão é mantida. Caso você não consiga uma comunicação UDP e tenha que usar TCP, existe um caminho alternativo que seria o RTP que faz a comunicação TCP com pequeno delay pela bufferização, e é muito bem tratado nesse protocolo.

No caso do RTSP podemos observar na Figura 2 que não existe o monitoramento dinâmico de banda. As informações geradas por diversos provedores são enviadas para um servidor que vai ficar encarregado de entregar essa informação para o cliente através da internet.

Figura 2. Esquema de Transmissão via RTSP.

Download progressivo – Simples e eficiente

Existem controversas de quando realmente o download progressivo começou a ser utilizado. A Apple referencia o QuickTime com o termo Fast Start, como sendo a primeira aparição do download progressivo.

Essa revolução se deu de uma simples mudança nos metadados do arquivo que antes vinham no final e agora passarão a ser enviados no começo arquivo – assim o player tinha as informações necessárias para iniciar sua reprodução.

Mas podemos lembrar nos primórdios da internet ...

Quer ler esse conteúdo completo? Tenha acesso completo