O streaming adaptativo sobre HTTP (HTTP Adaptive Streaming – HAS) é, inquestionavelmente, a forma dominante de streaming de mídia na internet. Este artigo, originalmente publicado no blog da Mux, é um misto de revisão e discussão técnica, no qual você vai compreender as implementações HAS e como todas elas abordam o mesmo conjunto de problemas e os resolvem da mesma maneira.
Em meados dos anos 2000, o streaming de mídia na internet estava claramente em ascensão. Em 2002, o MLB.com transmitiu seu primeiro jogo de beisebol para um público de 30.000 pessoas e, em apenas alguns anos, a Major League Baseball Advanced Media (MLBAM) estava ajudando a CBS a transmitir o torneio de basquete da NCAA de 2005. Da mesma forma, em meados de 2006, o YouTube estava tendo uma média de 100 milhões de visualizações por dia e era um dos sites com crescimento mais rápido na web.
Em outras palavras, a prática de assistir a vídeos na internet (geralmente chamados de OTT ou “Over the Top”) estava crescendo rapidamente e não dava sinais de diminuir tão cedo. E enquanto esses e outros exemplos mostravam sucesso técnico e até financeiro, o rápido crescimento também expôs alguns problemas reais sobre a capacidade das tecnologias existentes para acompanhar a mudança.
Os problemas
Muitos elementos começaram a pressionar a criação de novas soluções para o streaming OTT (incluindo, por exemplo, considerações de segurança). Entretanto, havia três problemas distintos, mas inter-relacionados, que pareciam especialmente grandes.
Custo
O streaming de mídia na internet era caro. Dada a quantidade de dados compactados em vídeo, em comparação com outros tipos de conteúdo, não é de surpreender que armazenar, processar e enviar esses dados custem muito dinheiro. No entanto, com base no modo como a tecnologia subjacente funcionava, era muito difícil tornar mais econômicas essas diferentes peças móveis.
Além disso, padrões existentes como o RTMP dependiam de servidores e clientes altamente especializados, o que significava que as pessoas precisavam construir, implantar, melhorar e manter esses servidores especializados (e pagar pelas equipes especializadas para fazer o trabalho ) ou para pagar por soluções licenciadas caras e prontas para uso, como o Adobe Media Server (que ainda precisava de pessoas para construí-las, implantá-las, aprimorá-las e mantê-las).
Escala (muito grande para ter sucesso)
A forma como as tecnologias existentes eram dimensionadas representava um dos principais motivos para o custo. Em essência, o dimensionamento era um problema porque as tecnologias subjacentes não previam quantas pessoas estariam assistindo TV na Internet, potencialmente em todo o mundo.
O RTMP e protocolos semelhantes eram inerentemente e profundamente baseados em sessão e em processos stateful (executados com base no contexto das transações anteriores, como e-mails e serviços bancários online) entre cliente e servidor. Por causa disso, as soluções mais comuns para escalar eram semelhantes a qualquer arquitetura stateful .
Você pode criar servidores mais robustos que possam lidar com a carga, mas apenas até certo ponto. Você poderia ativar vários servidores redundantes que poderiam ser agrupados para solicitações, o que era complexo na melhor das hipóteses e não realisticamente possível na pior das hipóteses para conteúdo de mídia ao vivo.
Nenhuma dessas soluções foi especialmente boa e também aumentou o custo. Infelizmente, não havia muitas alternativas com os padrões de streaming de mídia existentes.
Alcance
A internet estava mudando rapidamente. As redes domésticas e os roteadores WiFi já haviam começado a se tornar comuns, o que significava que os problemas de ponte entre redes públicas e privadas estavam se tornando comuns. A segurança da rede estava finalmente começando a ser levada a sério, o que ocasionou o surgimento de firewalls nesses roteadores pessoais e computadores domésticos, pois os problemas de portas e protocolos bloqueados viraram corriqueiros. Ambos apresentaram problemas com as tecnologias de mídia de streaming existentes, como RTMP.
Além disso, mais pessoas em mais lugares estavam obtendo conexões de internet, mas a infraestrutura para internet de alta velocidade não era nem de longe tão difundida. Somente nos Estados Unidos, no início de 2005, apenas 30% dos americanos na Internet tinham algum tipo de conexão de banda larga, muitos dos quais estavam na comparativamente muito mais lenta ADSL (Asymmetric Digital Subscriber Line – linha de assinante digital assimétrica) da época, que culminou entre 1,5-9mbps nas condições mais ideais.
Isso era um problema para coisas como RTMP porque não foi projetado para “adaptar” o tamanho do conteúdo codificado e transmitido com base nas condições de um cliente/player muito específico. Em vez disso, havia apenas “uma versão” da mídia. Isso também significava que lidar com várias legendas ou dublagens de áudio era complexo quando solucionável e, é claro, afetava fortemente o custo e as preocupações de escala.
Finalmente, mais tipos de dispositivos foram “conectados” e mais ambientes foram usados para reprodução de vídeo. Embora essa época seja anterior ao mundo atual dos smartphones, dos tablets modernos e da “Internet das Coisas”, as pessoas ainda tentavam assistir a vídeos online usando coisas como seus telefones habilitados para WAP (Wireless Application Protocol) com resultados não satisfatórios.
A salvação: streaming adaptativo sobre HTTP
Havia um consenso crescente de que as tecnologias predominantes para streaming de mídia não iriam funcionar e provavelmente precisariam ser repensadas (quase) totalmente. Houve uma concentração no RTMP, que era especialmente popular, mas, em sua raiz, todos os padrões e implementações dominantes se assemelhavam amplamente e resultavam nos mesmos conjuntos de problemas (e muitos deles, embora não todos, estão voltando em protocolos de “tempo real” como o WebRTC).
Além disso, dado o volume de pessoas e de dinheiro envolvidos na resolução dos problemas, havia pressão de mercado suficiente para provocar grandes mudanças rapidamente.
E elas aconteceram. No final de 2008, apenas alguns anos após o crescimento explosivo mencionado anteriormente, a Microsoft anunciou suporte pronto para produção para um novo padrão de mídia de streaming adaptável baseado em HTTP no IIS, chamado (Microsoft) Smooth Streaming (MSS).
Em pouco mais de 2 anos, o HTTP Live Streaming (HLS) da Apple, o HTTP Dynamic Streaming (HDS) da Adobe e o Motion Picture Expert’s Group (MPEG) Dynamic Adaptive Streaming over HTTP (DASH) foram lançados. Embora existam muitas diferenças entre esses padrões, todos são surpreendentemente semelhantes em seus principais detalhes de implementação.
Detalhes de implementação do streaming adaptativo sobre HTTP
Cada um destes protocolos usou um ou mais arquivos de texto para descrever aspectos relevantes do conteúdo de mídia como um todo. Eles geralmente são chamados de arquivos de manifesto (ou arquivos de lista de reprodução, no caso de HLS) e seriam a primeira coisa que um cliente/player solicitaria de um servidor de mídia.
Diferentes tipos de conteúdo de mídia relacionados podem ser descritos nos manifestos. Talvez o exemplo mais prevalente (embora não o único) seja o fornecimento de diferentes interpretações (também chamadas de representações) do mesmo conteúdo de áudio ou vídeo que um cliente/player pode escolher com base, por exemplo, nas condições da rede.
Todo o conteúdo de mídia foi disponibilizado como uma série de segmentos, ou pequenas fatias de tempo da mídia, que poderiam ser solicitadas individualmente, armazenadas em buffer e reproduzidas pelo cliente/player.
Cada um deles usava solicitações HTTP GET como protocolo e método primários para interação cliente/servidor, tanto para os manifestos quanto para os segmentos de mídia.
É hora de pontuarmos algumas perguntas fundamentais, cujas respostas facilitarão o entendimento do streaming adaptativo sobre HTTP:
- Por que todas as soluções funcionaram basicamente da mesma maneira, pelo menos nos detalhes principais?
- Por que cada uma dessas instituições grandes e bem financiadas acabou implementando versões diferentes da “mesma coisa” (isso inclui o DASH, que, embora lançado sob o ISO/IEC, teve muitas empresas grandes apoiando-o, e até mesmo pequenas)?
- Por que esses detalhes de implementação compartilhados eram a solução certa, especialmente quando havia compensações claras e óbvias (sobrecarga e velocidade de entrega de pacotes sendo as mais evidentes) em comparação com o que veio antes?
No restante deste artigo, vamos nos aprofundar no último ponto: por que o HTTP acabou sendo o padrão de fato para o HAS, já que todos os outros 3 são construídos sobre o que foi possível mudar para o HTTP.
Por que HTTP?
Na época, o HTTP pode não ter sido uma escolha óbvia. Como protocolo, era radicalmente diferente de coisas como RTMP. Para dar apenas um exemplo, não havia nada que se parecesse remotamente com um “stream” em HTTP em 2008, muito menos qualquer coisa que fosse projetada especificamente para ajudar com streaming de mídia.
Não apenas isso: na época, a grande maioria da “mídia” que o HTTP estava entregando aos clientes eram arquivos de imagem em páginas da web. Embora o HTML5 (que introduziria as tags <audio/> e <video/> ao HTML) estivesse co-evoluindo e certamente entrando no radar das pessoas, seu primeiro esboço não veio à tona até meados de 2007, e seu rascunho de trabalho é anterior ao MSS por apenas alguns meses.
Mas as pessoas rapidamente perceberam que as diferenças nos protocolos eram, na verdade, uma força (como uma substituição fundamental), e não uma fraqueza.
Funcionalidade do streaming adaptativo sobre HTTP
Em 1997, o HTTP/1.1 foi lançado e, em 1999, atualizado. A essa altura, havia muitos recursos que ajudaram nos problemas mencionados anteriormente, desde que a solução pudesse aproveitá-los. Conexões reutilizáveis para solicitações de clientes e pipelining (permitindo que várias solicitações fossem feitas antes que qualquer uma delas fosse concluída) significavam que o HTTP estava ficando mais eficiente.
O cache HTTP cresceu consideravelmente, incluindo mecanismos de controle mais robustos, o que significava que tanto os clientes quanto os servidores podiam ser muito mais inteligentes sobre quando enviar dados e quando não precisavam, e o faziam de forma que as pessoas não precisassem resolver esse problema em um “nível superior”.
Isso foi em parte construído sobre o conjunto em evolução de cabeçalhos de solicitação e resposta formalizadas e bem definidas, outra abstração que também incluía a ideia de “tipos de conteúdo” para definir contratos e expectativas claras sobre “o tipo de dados” que eram solicitados e/ou fornecidos.
Isso também incluiu a formalização de coisas como o cabeçalho de autorização, que, junto com a formalização do HTTPS em 2000 e a evolução de seu protocolo criptográfico subjacente (atingindo oficialmente o TLS 1.2 apenas alguns meses antes do lançamento do MSS), forneceu pelo menos alguma tranquilidade para a mais flagrante das preocupações de segurança e roubo de conteúdo.
Alguns recursos já existentes não seriam aproveitados até muito mais tarde (requisições de intervalo para facilitar o armazenamento de um único arquivo de mídia e apenas solicitar “os bits relevantes”). Surgiram outros que ajudaram (HTTP/2 PUSH para busca rápida em extensões de baixa latência para protocolos HAS, por exemplo).
Maturidade do streaming adaptativo sobre HTTP
A maior parte da funcionalidade descrita acima foi o resultado de uma década abordando e aprimorando questões genéricas que não eram mais apenas sobre HTML e páginas da web. Além disso, não havia razão para pensar que essas melhorias ou esse foco iriam parar tão cedo.
Mas não foi apenas o protocolo em si que amadureceu. Padrões e arquiteturas estavam evoluindo em torno do HTTP. Roy Fielding terminou sua dissertação de doutorado lançando as bases para REST em 2000, e estava rapidamente se tornando a maneira como os clientes conversavam com servidores para todos os tipos de casos de uso, inclusive para uploads e downloads de dados binários (tornando protocolos mais especializados como FTP e Gopher menos comuns).
Uma das principais razões para isso foi que, mesmo que a maioria dos servidores ainda fosse stateful, o REST (sobre HTTP) não precisava ser, o que significava que poderia escalar verticalmente e horizontalmente com muito mais facilidade e com muito menos sobrecarga de recursos do que conexões stateful, baseadas em sessão.
A infraestrutura para aproveitar esses detalhes de protocolo também amadureceu. Neste ponto, as soluções de balanceamento de carga eram especialmente bem conhecidas para HTTP, funcionando particularmente bem com – principalmente ou totalmente – arquiteturas de servidor RESTful stateless ou semelhantes o REST, que era uma solução muito mais clara, simples e barata para os tipos de complexidades de dimensionamento mencionadas acima.
Mas não foram apenas as soluções de servidor on-prem (“no local”) que cresceram. A primeira oferta comercial de CDN da Akamai foi lançada em 1999, quase uma década antes, e ela e outras CDNs usaram esse tempo para criar arquiteturas de distribuição mais inteligentes e eficientes (usando HTTP) para alcance global, independentemente de onde o conteúdo veio originalmente. E embora houvesse otimizações adicionais que acabariam evoluindo especificamente para a mídia, os fundamentos eram novamente soluções genéricas para problemas genéricos.
Onipresença do streaming adaptativo sobre HTTP
Tanto porque a web estava crescendo rapidamente quanto porque o HTTP já havia evoluído (e continuaria a evoluir) para algo muito mais amplo do que simplesmente “OBTER páginas da web e seu conteúdo relacionado”, também era um dos protocolos mais prováveis para existir na maioria dos dispositivos e entre clientes e servidores. Para o bem ou (e?) para o mal, o HTTP mostrava sinais claros de dominar grande parte da Internet, assim como o JavaScript atualmente mostra sinais de dominar grande parte do espaço de desenvolvimento (também para o bem e para o mal).
O número de servidores HTTP disponíveis era enorme em comparação com os servidores de streaming de mídia “tradicionais”. Além disso, existiam em vários idiomas e incluíam muitas opções gratuitas. Isso também significava que eles poderiam ser “construídos em cima”, atualizados e aprimorados para qualquer caso de uso.
Isso simplesmente não estava disponível para servidores RTMP. Ferramentas, tutoriais, estruturas de teste e muitos outros recursos de apoio estavam amplamente disponíveis. Isso também significava que os engenheiros que tinham uma compreensão sólida e profunda do HTTP poderiam ser atualizados e aplicar esse conhecimento básico ao HAS, ao contrário de protocolos como o RTMP, que eram muito mais específicos do domínio em um nível profundo.
E esse mesmo tipo de onipresença estava acontecendo no client-side (“lado do cliente”). O bordão mais comum para os telefones habilitados para WAP foi: “isso deve funcionar apenas com HTTP e HTML regulares”, e foi isso que acabou acontecendo com o advento de smartphones como o iPhone e o Android.
Para sistemas operacionais, APIs centradas em rede e os ambientes de desenvolvimento que correspondiam a eles, se houvesse algum esforço para tornar o suporte ao protocolo de “camada de aplicativo” fácil e conveniente, o HTTP estaria em uma lista curta, se não no topo dela.
Conclusão
Qualquer um dos protocolos acima sozinho já ajudaria com as várias preocupações de custo, escala e alcance, mas juntos eles reforçaram um ao outro, praticamente garantindo que os benefícios de funcionalidade, maturidade e onipresença se perpetuassem – e o fizeram de uma forma quase totalmente independente de seu uso para streaming de mídia.
Como este artigo foi escrito mais de uma década depois do mais recente padrão HAS, sem dúvida há um pouco de viés de retrospectiva nele, pois vimos na prática que todas as afirmações feitas aqui são verdadeiras.
Como você tem aproveitado o streaming de vídeos no seu negócio?
Caso você esteja precisando profissionalizar a hospedagem e a distribuição dos seus vídeos, saiba que a K2. oferece soluções tanto para transmissões ao vivo quanto para conteúdo sob demanda.
Quer entender como elas funcionam? Deixe um comentário abaixo ou entre em contato conosco para esclarecermos suas dúvidas ou para agendarmos demonstrações gratuitas das plataformas!
