O próximo boom da internet já está definido: Transmissões ao vivo. Independente do fim, uma interação mais cara-a-cara é cada vez mais exigido na internet.

Para empresas, essa necessidade traz um grande problema: Como fazer para ter o menor atraso possível?

RTMP: Era uma vez um Flash….

Para ter realmente baixa latência, se usava tecnologias tipo RTMP para transmissões online: O protocolo possui latência super baixa (até menos de 2s), porém exige uma tecnologia que já teve até o seu fim declarado: Flash. Por causa disso, e alguns outros detalhes – Como por exemplo dispositivos móveis não terem suporte – sua adoção hoje em dia é baixa.

HLS, MPEG-DASH, Smooth Streaming e sopa de letrinhas…

Em tecnologias mais novas, existem diversos formatos disponíveis. Independente do gosto pessoal e de alguns detalhes técnicos, ambos atingem basicamente o mesmo resultado: Universalidade (tocam em todos os dispositivos) e adaptabilidade.

O problema da maioria deles? Atraso!

Vamos a um exemplo real: Uma academia de presença nacional queria fazer uma aula ao vivo e todas as filiais deveriam participar ao mesmo tempo.

Então ela quer que os alunos do Brasil todo enxerguem os movimentos em menos de 6 segundos é possível? Na nossa experiência é sim! Mas depende de alguns fatores:

1) Entenda como funciona a tecnologia de transmissão

Muita gente acha que H.264 é só pá-pum, botou e tá funcionando, mas não é bem assim. De maneira bem bem beeem simplificada, uma transmissão em H.264 insere um key frame de vez em quando, que é basicamente uma imagem (JPG) inteira do vídeo que está sendo gravado. Os frames seguintes (lembra que os vídeos tem em média 30 Frames por segundo) só vão ter as informações do que ele é diferente do último key frame. Basicamente com isso é que ele compacta o vídeo sem grandes perdas.

Porém existem aqui 2 decisões fundamentais: De quanto em quanto tempo ele vai forçar inserir um keyframe novo, e como vai ser configurado algum tipo de detector de troca do cena.

Para uma transmissão usando HLS, por exemplo, que divide o vídeo a cada 5-10 segundos num arquivo isolado, isso pode ser um indicativo de dificuldade: Pensa que o arquivo pode começar sem keyframe, logo o player tem que esperar (atraso na reprodução) até que chegue um frame completo para ele ter referência do que pintar na tela. Se o keyframe estiver configurado para, digamos, 4 segundos, isso pode significar atraso extra de 4 segundos somente aí!

Ou seja: Habilite detecção de troca de cena, e peça para seu transcodificador iniciar cada arquivo de HLS ou DASH com um keyframe.

2) Configure seu player corretamente

Existem excelente players como JWPlayer, hlsplayer e vários outros que permitem seu conteúdo em HLS/MPEG-DASH seja tocado corretamente.

Fale com um fornecedor experiente e pergunte, no seu caso, qual o melhor player para uma transmissão do seu tipo. Desconfie de quem usa o mesmo player pra tudo, porque óbvio, não existe o melhor player para todos os cenários sempre.

Porém existem diversos ajustes para fazer no player, o mais importante pra nós é: Qual o tempo mínimo/máximo de atraso que será permitido antes de sinalizar problema?

Um cliente nosso teve esse exato problema: O player não suportava esse tipo de configuração, apenas “vinha pronto”, e nós víamos um problema: De SP, o atraso detectado era de 7 segundos. Do RS eram 11 e de Recife era 9! Depois de olhar com calma a situação, vimos que o player permitia bufferização entre 2 e 60 segundos! Ou seja, pra ele, atrasar 11 segundos era um excelente cenário. Pro nosso cliente, não era.

Qual o problema disso? O problema é que o player tem vários parâmetros de ajuste, porém um óbvio é dizer: Te esforça para fazer alguma coisa pra nunca atrasar mais que a minha meta! Óbvio que tem outros ajustes importantes, mas sem esse, não tem como conversar.

3) Escolha um CDN que tenha entrega rápida em todo o Brasil

Hoje em dia, muita gente diz ter entrega rápida no Brasil porque entrega rápido em SP, RJ e mais um outro lugar. Infelizmente se formos ver o tráfego do Brasil, os motivos até ficam claros:

Tráfego IX.br

Digamos que de uma média total de 2,15Tbps (ou 2.150Gbps de dados), quase 80% fica em SP!

Se todos os seus clientes estão em SP, ótimo, o problema é que muitos não estão, e aí começa a dificuldade.

There's no cloud

O que muitos CDNs fazem, é colocar um equipamento fisicamente em São Paulo e anunciar para o resto da internet que pode ir lá buscar o conteúdo.

Efeito borboleta na latência..

O problema disso, é, segundo nossas medições, 30ms a mais de RTT faz com que o player possa acrescentar até 3 segundos extras de latência pela flutuação da rede!

Mas como eu vou saber se o CDN que estou contratando é bom?

Uma dica seria entrar em uma ferramenta simples como essa: http://www.isptools.com.br/ping, selecionar “Múltiplas origens” e colocar o IP do teste.

O óbvio vai aparecer: SP vai ser ÓTIMO. Mas e na Paraíba? E no Pará? E em Recife? E no Acre? E em Manaus? Aí que começam as diferenças.

No nosso caso, além de sermos uma rede anycast otimizada para o Brasil, nós temos 9 anos de experiência desenvolvendo parcerias com provedores de internet no Brasil todo, além de posicionarmos nossos nodos pra entrega sempre onde os clientes dos nossos clientes estão, garantindo sempre uma latência mais baixa.

Por sinal, depois de feito tudo isso, nosso cliente conseguiu a latência que ele queria.