A entrega de conteúdo de vídeo pela Internet começou nos anos 90, com entrega e consumo de grandes quantidades de dados como o principal desafio. O Protocolo de transporte em tempo real (RTP) da IETF foi projetado para definir formatos de pacotes para conteúdo de áudio e vídeo junto com o gerenciamento de sessões de fluxo que permitia a entrega desses pacotes com custos indiretos muito baixos. O RTP funciona bem em redes IP gerenciadas. No entanto, na Internet de hoje, as redes gerenciadas foram substituídas pelas redes de entrega de conteúdo (CDN), muitas das quais não oferecem suporte ao streaming RTP. Além disso, pacotes RTP geralmente não são permitidos através de firewalls. Por fim, o streaming RTP exige que o servidor gerencie uma sessão de streaming separada para cada cliente, tornando as implantações em larga escala muito custosas em relação aos recursos.
1.1. Motivação
Com o aumento da largura de banda da Internet e o crescimento da mesma, o valor da entrega de dados de áudio ou vídeo em pacotes de tamanho muito pequenos diminuiu. Agora, o conteúdo multimídia pode ser entregue com muita eficiência em segmentos maiores usando HTTP. Esse tipo de streaming traz vários benefícios, que veremos mais a frente - na seção 4.1.
Por conta dessas razões, o streaming HTTP se tornou uma abordagem popular em aplicações comerciais. Por exemplo, plataformas de streaming como o HTTP Live Streaming (HLS) da Apple, o Smooth Streaming da Microsoft e o HTTP Dynamic Streaming da Adobe usam o fluxo HTTP como método fundamental de entrega. No entanto, cada implementação usa diferentes formatos e, portanto, para receber o conteúdo de cada servidor, um dispositivo deve suportar seu protocolo de cliente proprietário correspondente.
É importante destacar a relevância do consumo de vídeos na Internet. Segundo uma pesquisa realizada pela Sandvine,
quase 40% do tráfego mundial da Internet em dispositivos móveis é para o Youtube. Em segundo lugar, vem o Facebook com 8,4%. Observando que muitos conteúdos que antes só estavam na TV,
agora podem ser assistidos em qualquer dispositivo, através das plataformas OTT (Over the Top) por exemplo, como Netflix, Amazon Prime Video e Globoplay, observa-se que a tendência de crescimento é alta e
está afetando diversos setores da indústria, relacionados à Internet, como as empresas de telecomunicações. As formas, padrões e protocolos de distribuir esse conteúdo são de suma importância, pois
impactam diretamente na experiência do usuário.
2. Overview
2.1. Experiência do Usuário
As tecnologias de adaptive streaming permitem a melhor experiência de visualização de vídeo em streaming para uma ampla gama de dispositivos em um amplo conjunto de velocidades de conexão. Primeiro, elas produzem vários arquivos do mesmo arquivo de origem para distribuir aos espectadores que assistem em diferentes dispositivos com diferentes velocidades de conexão. Segundo, elas distribuem os arquivos de forma adaptável, alterando o fluxo fornecido para se adaptar às mudanças na taxa de transferência efetiva e nos ciclos de CPU disponíveis na estação de reprodução. E terceiro, todas operam de forma transparente para o usuário, de modo que o espectador clica em um botão e todas as trocas de fluxo ocorrem nos bastidores. O espectador até pode notar uma ligeira mudança na qualidade à medida que os fluxos mudam, mas nenhuma ação é necessária da parte dele.
Essas tecnologias permitem que os produtores ofereçam streamings de ótima qualidade na parte alta do espectro de largura de banda, porque também atendem à parte baixa. Sem elas, a maioria dos produtores distribuiria um único arquivo de qualidade mediana que aparentaria estar abaixo da média na configuração ideal de visualização ou criaria vários arquivos e forçaria o espectador a selecionar a configuração desejada.
2.2. ABR - Principais Termos
Os protocolos que se utilizam do ABR (Adaptive Bitrate Streaming), exploram a divisão do vídeo original em pedaços, chamados de segmentos, ou chunks que nada
mais são que arquivos com partes discretas do conteúdo original, que pode ter vídeo, áudio, legenda, sinalizações para inserção
comercial, metadados, etc. Esses segmentos, são baixados no cliente, alinhados e remontados de modo a reconstruir o arquivo original a ser reproduzido.
Uma sequência de segmentos caracteriza um profile. E partir de um mesmo conteúdo original, temos a possibilidade de realizar
a transmissão dos segmentos para a CDN, em diferentes profiles.
Um profile é caracterizado pelo tipo de codec de vídeo, áudio, resolução, dentre outras características de compressão de arquivos de mídia.
A escolha dessas características irá determinar o bitrate desse profile, que por sua vez irá impactar na qualidade desse
conteúdo e na banda que será necessária para o cliente realizar o download dos segmentos.
Como o nome sugere, uma transmissão adaptativa permite o cliente se adaptar às suas próprias condições de rede, selecionando os
segmentos do profile que mais se adequa à taxa de download disponível. Ex: Se o throughput disponível para o cliente é de 15Mbps, mas o profile mais alto tem um bitrate
de 20Mbps, não será possível assistir o conteúdo na melhor qualidade disponibilizada pela fornecedora do conteúdo, porém reduzindo
para um profile mais baixo, ainda sim será possível a reprodução, em uma qualidade inferior. Esse modelo permite a transmissão
tanto de conteúdos ao-vivo (Live), como on-demand (VoD).
Os diferentes profiles são disponibilizados para o cliente através de URLs, listadas em um arquivo chamado manifesto.
Em Julho de 2009, em busca de um padrão universal para a entrega de conteúdo de mídia de forma adaptativa, o MPEG (Motion Picture Experts Group) lançou uma RFP (Request for Purposal) no mercado, em busca de iniciar o desenvolvimento de um padrao de streaming HTTP.
O resultado desse desenvolvimento, em conjunto com diversas empresas e institutos de pesquisa foi o mpeg-DASH (ISO/IEC23009-1), que foi publicado em 2012, e teve diversas atualizações desde então. Como em outros formatos de
streaming adaptativo, os segmentos são armazenados em um servidor WEB e baixados pelos clientes, através de HTTP ou HTTPS. Importante não confundir o mpeg-DASH com um protocolo de transporte, já que o protocolo da camada de transporte que é utilizado é o TCP.
3.2. Funcionamento
Para entender o funcionamento do padrão, é preciso descrever o mpeg-DASH Media Presentation Description, ou MPD.
O MPD é um documento XML, que contem informações sobre todos os segmentos disponíveis para o conteúdo que o cliente está
tentando reproduzir. Isto é, realizando o parse no MPD, em seu nível mais baixo, será retornado uma URL com a
localização daquele dado no servidor HTTP de origem, de onde será feito o download.
Seguindo a arquitetura cliente-servidor, o player de vídeo do usuário (cliente) inicia o processo, solicitando ao servidor (ex: ponto de CDN fisicamente mais próximo)
o arquivo MPD. Após realizar o parse do MPD, o player executa algoritmos (no cliente!) para decidir (adaptativamente), qual profile e consequentemente qual segmento irá fazer o download.
Um período descreve uma parte do conteúdo, com início e fim. Seu tamanho pode variar, de acordo com o tipo de streaming (live, vod, etc). Se o conteúdo for vod, é mais provável que o período do segmento seja maior,
já se for um streaming live, o período tende a ser menor, já que os arquivos estão sendo produzidos on-the-fly, ao contrário do vod, que já estão armazenados
no banco de dados do servidor. Obs: Não confundir período (mais alta camada do MPD) com segmento (mais baixo nível do MPD).
Abaixo do nível de período, temos os adaptation sets, que contem uma ou mais componentes da mídia. O mais comum é ter um adaptation set para o vídeo,
e um para cada idioma de áudio disponível. Além disso, pode ser disponibilizado legenda e metadados.
As representações permitem diversas reproduções do mesmo conteúdo, com qualidades (profiles) diferentes, como foi citado na seção 2.2. Normalmente,
os players de streaming ABR iniciam a reprodução no profile mais baixo, de forma a reduzir o start-time. Além disso, ao longo da reprodução, é o player (cliente)
que monitora as métricas da conexão (variações de throughput), performance da CPU, A decisão é sempre do player, e não envolve
diretamente o padrão mpeg-DASH.
Como explicitado anteriormente, o mpeg-DASH é um dos protocolos que se localizam no universo de protocolos de streaming adaptativo. Isto é, permite a transferência de vídeo no modelo clássico cliente-servidor, de forma que a qualidade da experiência se adapte à qualidade da conexão de Internet do usuário, permitindo assim uma flexibilidade e maior disponibilidade para um maior número de assinantes/clientes.
4.1. Vantagens
O mpeg-DASH se diferencia dos seus concorrentes, principalmente pelo fato de que foi um protocolo que foi desenvolvido com a intenção de ser independente, não-proprietário. Ou seja, não foi criado unicamente por nenhuma marca como Apple ou Microsoft, mas desenvolvido em parcerias com mais de 10 empresas e ratificado pelo MPEG e pela ISO, objetivando se tornar um padrão internacional no ramo de transmissão de vídeo pela Internet, evitando que decisões comerciais unilaterais possam restringir a compatibilidade entre serviços, ou interoperabilidade de aplicações. Como o mpeg-DASH é baseado em requisições HTTP via TCP, seus pacotes trafegam na porta 80, evitando assim problemas com Firewall. Além disso, não é necessário possuir uma rede de servidores especiais. Servidores HTTP comuns processam o streaming. Uma outra vantagem é o fato de ser agnóstico aos codecs de áudio e vídeo, de forma que haja uma maior flexibilidade na compressão dessa mídia a ser transmitida. O formato do segmento também é flexível: em comparação com o HLS, que fixa o formato MPEG2-Transport Stream, o mpeg-DASH também possibilita o uso de segmentos ISO Base Media File Format (ISOBMFF).
Podemos citar ainda, outras características como: suporte a múltiplas CDNs/Caches com o mesmo arquivo manifesto, garantindo flexibilidade, escalabilidade e maior tolerância a falhas.
4.2. Desvantagens
Não é suportado nativamente pelo HTML5, sendo necessário habilitar uma extensão (MSE - Media Source Extension). O fato de ser
agnóstico aos codecs de áudio/vídeo também pode ser visto como uma desvantagem, visto que um conteúdo em um determinado codec
pode não ser suportado por um player específico. Clientes de streamings HTTP também necessitam ter um buffer local de um certo número de segmentos,
de forma a ter uma tolerância temporal a retransmissões TCP. Típicamente enquanto um segmento está sendo reproduzido, o outro está no cache e um terceiro
está sendo baixado. O uso de um buffer causa, necessariamente, latência, já que o segmento em reprodução já foi recebido há alguns segundos (no caso de streamings live).
5. Alternativas
5.1. HLS
Ferramenta criada pela Apple, o HLS (HTTP Live Streaming), corta o conteúdo do video em pedaços de 10 segundos e os entrega via HTTP. Assim como o mpeg-DASH, a qualidade na entrega é dinâmica, podendo mudar de acordo com a velocidade de Internet do usuário.
Ferramenta criada pela Microsoft, o Microsoft Smooth Streaming, permite streaming de mídia para o Silverlight e outros clientes por HTTP. Também fornece uma experiência de visualização de alta qualidade que se escala enormemente nas redes de distribuição de conteúdo, tornando realidade a experiência em mídia Full-HD.
5.3. RTMP
Protocolo criado pela Macromedia, o Real Time Messaging Protocol, foi implementado totalmente voltado para o Flash player. Ele é desenvolvido sobre TCP e por padrão ulitiza a porta 1935. A diferença principal entre RTMP e HTTP é que no RTMP, há um ponteiro direto do servidor de mídia para o flash player, e apenas os dados correspondentes a esse ponteiro são retidos pelo flash player. Não há armazenamento em buffer / dados no computador. Em HTTP, é criado um buffer estável, começando no ponto de reprodução.
Flexible Content Protection with Common Encryption (DRM)
Closed Captions / Subtitles
Efficent Ad Insertion
Fast Channel Switching
Protocol Support’s multiple CDNs in parallel
HTML5 Support
Support in HbbTV (version 1.5)
HEVC Ready (UHD/4K)
Agnostic to Video Codecs
Agnostic to Audio Codecs
ISO Base Media File Format Segments
MPEG-2 TS Segments
Segment Format Extensions beyond MPEG
Support for multiplexed (Audio + Video) Content
Support for non-multiplexed (separate Audio, Video) Content
Definition of Quality Metrics
Client Logging & Reporting
Client Failover
Remove and add Quality Levels during Streaming
Multiple Video Views
Efficient Trick Modes
6. Aplicações com utilização do mpeg-DASH/Compatibilidades
Grandes players do mercado participaram do projeto, porém a barreira comercial ainda é um grande entrave para a utilização do mpeg-DASH. Um dos grandes exemplos que podemos citar é em relação à Apple, que é proprietária do HLS, e restringe a reprodução de conteúdo em seus dispositivos à esse protocolo.
Ainda sim, podemos citar o Youtube e a Netflix como grandes utilizadores do mpeg-DASH, ainda que seus servidores variem o padrão/protocolo streaming, de acordo com o device.
Em toda a cadeia de produção, o mpeg-DASH é suportado por grandes empresas. Alguns exemplos: AWS, Wowza, Akamai, Azure, Bitmovin, CenturyLink e Tata Communications.
7. Conclusão
O mpeg-DASH é um padrão que chegou depois de outros grandes protocolos, criados por grandes empresas, como a Apple. Seu rival
principal, o HLS, leva vantagem por ter chegado primeiro ao mercado. Porém, ainda sim está sendo adotado por diversas
empresas de distribuição de conteúdo. Embora não seja adotado nativamente pelo HTML5, existem scripts JS que realizam essa integração.
R: Permitir a entrega de conteúdo de mídia, através da Internet, de forma adaptativa.
Como o DASH se diferencia em relação ao HLS, no que diz respeito ao formato do segmento?
R: O DASH permite a utilização de ISOBMFF, ao contrário do HLS que restringe o formato (MPEG2-Transport Stream)
Qual o protocolo de rede utilizado para a transmissão dos segmentos DASH?
R: HTTP
E qual a principal vantagem da utilização do protocolo de rede acima?
R: Ser firewall/friendly, já que o HTTP e a porta 80 normalmente são abertos em quase todos os firewalls, para
tráfego comum da Internet.
Qual o formato (extensão) do MPD? E qual a sua utilidade?
R: XML. O MPD é o arquivo responsável por informar ao cliente, a URL dos segmentos disponíveis para download.
Este trabalho foi totalmente produzido pelos autores que declaram não terem violado os direitos autorais de terceiros, sejam eles pessoas físicas ou jurídicas. Havendo textos, tabelas e figuras transcritos de obras de terceiros com direitos autorais protegidos ou de domínio público tal como idéias e conceitos de terceiros, mesmo que sejam encontrados na Internet, os mesmos estão com os devidos créditos aos autores originais e estão incluídas apenas com o intuito de deixar o trabalho autocontido. O(s) autor(es) tem(êm) ciência dos Artigos 297 a 299 do Código Penal Brasileiro e também que o uso do artifício de copiar/colar texto de outras fontes e outras formas de plágio é um ato ilícito, condenável e passível de punição severa. No contexto da Universidade a punição não precisa se restringir à reprovação na disciplina e pode gerar um processo disciplinar que pode levar o(s) aluno(s) à suspensão;
