Como funcionam as plataformas de Streaming de Vídeo? (por de baixo dos panos)

Como funcionam as plataformas de Streaming de Vídeo? (por de baixo dos panos)

No mundo da tecnologia, um dos grandes pesadelos de um projeto, está relacionado com o streaming de vídeos!

Pois a lógica de "streamar vídeos", não é tão simples como um CRUD, uma loja virtual, um e-commerce, um sistema de gestão e afins.

Ela envolve diversos procedimentos internos que vão desde a arquitetura do sistema, até a escolha da melhor linguagem de programação que oferece um stream mais performático e seguro.

E esse processo de definição, na maioria das vezes, costumam gerar grandes dores de cabeça! Principalmente se você for um desenvolvedor de primeira viagem.

Este artigo tem por objetivo te fornecer os conhecimentos necessários e técnicos, para que você possa ter uma ideia do que fazer para construir a sua própria plataforma de vídeos.

Mas antes, vamos começar nosso artigo com a seguinte pergunta:

Você realmente precisa streamar seus próprios vídeos em uma plataforma própria? 

Primeira coisa que você precisa entender: Criar uma plataforma própria de streaming de vídeos é CUSTOSO e CARO.

Segundo, esquece aquela ideia de que você pode hospedar seus vídeos dentro do seu próprio servidor, pois isso é um tiro no pé, principalmente se você estiver usando uma hospedagem compartilhada.

Projetos de Streaming de Vídeos envolvem servidores dedicados, isto é, servidores parrudos com um grande poder de processamento, principalmente aqueles que possuem uma quantidade gigantesca de transferência de dados (fuja daqueles servidores que dizem ter transferência ilimitada).

Inicialmente (estágio MVP) não há problema nenhum em hospedar seus próprios vídeos no mesmo servidor que também se encontram os arquivos do seu projeto (front-end e back-end), pois naquele primeiro momento você ainda não sabe se o negócio "vai dar certo" ou não.

Mas o que eu quero dizer com "vai dar certo ou não"?

Há um tempo atrás, um grande amigo me pediu uma ajuda para definir qual seria a melhor plataforma de hospedagem de vídeos, pois ele estava criando uma plataforma de educação online e queria lançar o seu primeiro curso gratuito.

Ele estava com dúvidas em relação a uma plataforma bastante conhecida que cobrava R$ 90,00 por mês, na qual dava as seguintes possibilidades:

Agora vamos fazer alguns cálculos...

O curso dele era dividido em 10 módulos, onde cada módulo contava apenas com uma única aula de pelo menos 15 minutos.

Uma aula de 15 minutos na qualidade FullHD (1080p), dependendo do cenário e a quantidade de imagens que estão sendo transmitidas alí dentro do vídeo, pode pesar entre 100MB a 1GB 😆

Para fechar a nossa conta, vamos supor que cada um dos vídeos dele pesassem 400MB. 400MB multiplicados pela quantidade de vídeos que é 10, temos um total de 4000MB (ou 4GB).

Inicialmente, 4GB equivalem a 1,33% do total de espaço daquele plano de R$ 90,00 (300GB), até aí tudo bem.

O ponto que você deve se atentar, não é a quantidade de armazenamento, mas sim a quantidade de banda disponível!

Como dito anteriormente, a quantidade máxima de banda daquele plano é de 500GB, e se você ultrapassar vai pagar R$ 0,20 a cada GB consumido.

Beleza, supondo que ele consiga 12 alunos e que cada um desses alunos assistam todos os vídeos do portal apenas uma única vez, teríamos o seguinte calculo:

QntDeBandaComsumida = QntTotalDeVideosEmGB  X  QntTotalDeAlunos. 

QntDeBandaComsumida = 4GB x 12 Alunos.

QntDeBandaComsumida = 48 GB.

48 GB de 500GB representam um consumo de 9,6% de banda consumida por mês. 

Legal, mas antes de continuarmos, você precisa entender que existem diferentes tipos de alunos, por exemplo:

Se a gente considerar que ele tenha apenas 12 alunos, o plano de R$ 90,00 vai atendê-lo muito bem. Mas, se entrarem 125 alunos de uma só vez, onde todos decidissem fazer as aulas (e nunca mais voltarem), o consumo dele chegaria no limite de 500GB.

É por essas nuânces que eu te digo que: Não tem como mensurar de forma definitiva a quantidade de consumo, pois cada aluno age de forma diferente! O que podemos ter são apenas expectativas.

Voltando agora a pergunta do "vai dar certo ou não", a verdade é que talvez a plataforma de educação, em um primeiro momento, não adquira muitas incrições de alunos, o que acarretaria no pagamento de R$ 90,00 á toa sem ninguem usando (eu chamo isso de jogar dinheiro fora).

Entretanto, como ele não sabe se o negócio vai dar certo ou não, é mais inteligente hospedar os vídeos dele no mesmo servidor onde está instalada a sua aplicação, de modo a diminuir os custos e "ficar a espreita".

"Ficar a espreita" no sentido do desenvolvimento do negócio, para identificar se vai valer a pena investir naquela plataforma de vídeos ou não.

Ou seja, enquanto ele ainda está nos primeiros meses e ainda não possui alunos, ele não vai ficar gastando R$ 90,00 á toa... mas a medida que mais alunos vão entrando e consumindo os vídeos... aí sim, é a hora de melhorar o negócio.

É claro, estou considerando que a plataforma de educação,ainda é uma empresa nova e que precisa de grandes investimentos para se tornar conhecida, por esse motivo é mais lógico tomar medidas para diminuir os riscos.

Agora, caso a empresa dele já fosse grande, ou já possuísse um aporte financeiro gigantesco, o melhor caminho mesmo seria hospedar seus vídeos em uma plataforma externa.

Para finalizar,  eu recomendei que ele hospedasse seus próprios vídeos no Youtube e configurasse eles para "não listado", dessa forma, somente os alunos com o link poderiam assistir suas aulas.

"Ah mais e a questão da segurança e bla bla bla... os alunos poderão compartilhar o link e bla bla bla...".

Mas o seu curso não é gratuito? Duvido muito que vão querer piratear algo que ja é gratuito, não é mesmo? 

Dito isto, voltamos a pergunta principal deste tópico: Você realmente precisa streamar seus próprios vídeos em uma plataforma própria?

Se seus vídeos forem gratuitos, você pode hospedá-los no Youtube e definí-los como "não listado", ou que sabem hospedá-los em seu próprio servidor (e ficar a esfreita).

Se seus vídeos forem pagos, a melhor alternativa é assinar um plano mensal em uma plataforma especializada no gerenciamento desses vídeos (Vimeo é um exemplo).

Geralmente quando queremos criar uma plataforma própria de streaming de vídeos, é quando nos encaixamos em um dos perfis abaixo:

Se você se enquadra em um ou mais perfis acima, vamos seguir aidante com este artigo 😉

Passo 1) Upload de Arquivos

Tudo começa com o upload, onde o seu usuário vai escolher o arquivo de vídeo que está hospedado no computador dele, selecioná-lo e enviá-lo para a nossa plataforma.

Aqui tem um pulo do gato que você pode fazer para aumentar a otimização do seu servidor: Antes de receber de forma direta o arquivo inteiro na sua aplicação back-end, porque não fazer com que o navegador do próprio usuário processe esse vídeo de forma a cortá-lo em pequenas partes. que serão enviadas ao servidor back-end? 

Dividir o vídeo em partes menores antes de enviá-lo pode reduzir a carga de tráfego na rede, o que é especialmente útil em conexões lentas ou limitadas.

Além disso, cortar em partes menores, se bem implementado, pode facilitar o escalonamento da aplicação ao distribuir o processamento entre clientes (navegadores) e servidor.

Entretanto, nem todos os navegadores possuem suporte nativamente a manipulação de vídeos dessa maneira.

Além disso, nós temos a complexidade da implementação, pois criar um sistema de manipulação de vídeos do lado do cliente, não é uma tarefa fácil.

Mas ainda assim, é melhor cortar o seu vídeo em pequenas partes e enviar de forma contínua ao nosso servidor, do que enviar tudo de uma vez em uma única requisição HTTP.

Existem varios formatos de vídeos que o seu usuário poderá subir, como:

Cabe a você decidir quais formatos a sua plataforma irá aceitar, os mais comuns são os arquivos .mp4 e .mov, de resto, você vai precisar analisar a viabilidade de suporte desses outros formatos.

Passo 2) Processamento do vídeo

Quando o upload é realizado, é a hora do seu servidor tomar as devidas providências de armazenamento.

Pois bem, quando o arquivo de vídeo ele chega pela primeira vez no servidor, geralmente ele estará em uma resolução mais alta, como 1080p, 2K, 3K, 4K... 8K.

E quanto maior for a resolução, mais nitido fica a imagem e mais pesado fica o arquivo (é a lei da natureza rs).

O problema é que se você só armazenar esse arquivo e disponibilizar para os seus usuários assistirem do jeito que ele veio, você vai frustrar seus usuários pelos seguintes motivos:

Além disso, se você só disponibilizar seu arquivo de forma normal (via requisição HTTP), o navegador do cliente vai precisar fazer download do arquivo inteiro antes de dar o play. (Isso também é um problema de segurança, pois se o arquivo inteiro está sendo baixado, ele pode arrumar algum jeito de fazer download...)

Ou você acha que só o player dava conta do recado de ficar pegando pedacinho por pedacinho, a medida em que o usuário avança na reprodução do vídeo?

Agora junta tudo isso que eu falei e atrele ao fato dele ter uma internet lenta 😵‍💫

Para resolver este problema, existe uma funcionalidade chamada de transcoding (conversão de vídeo), que visa transformar o seu arquivo de vídeo em pequenas partes de forma segmentada.

Tal processo que é bastante utilizado por grandes plataformas de streaming, como Youtube, Vimeo, Netflix e etc.

Como funciona o processo de transcoding?

O processo de transcoding acontece quando temos um arquivo de alta qualidade e o convertemos em vários pequenos arquivos que possuem qualidades diferentes (resolução menor).

O que antes era um arquivo .mp4 ou .mov, acaba se tornando pequenos arquivos do tipo HLS (HTTP Live Streaming), MPEG-DASH ou outros arquivos voltados para a transmissão de vídeo adaptável.

Onde cada um desses pequenos arquivos podem ter apenas alguns segundos de vídeo, o que facilita o processo de download, além de tornar mais simples as funcionalidades de avançar, pausar e retroceder do seu vídeo.

Beleza, o que discutimos acima, foi o processo de envio (disponibilização) de um arquivo de vídeo do back-end para o player existente no navegador do usuário.

Mas antes da disponibilização, existe o processo de salvamento desse vídeo assim que ele chega no servidor após o upload.

Antes de salvar seu vídeo no armazenamento do servidor, assim que você o recebe, é inteligente pegar aquele arquivo gigantesco (que geralmente está em FullHD) e convertê-lo para qualidades inferiores. 

No Youtube por exemplo, nós podemos modificar a qualidade de um determinado vídeo:

Podemos modificá-lo para 1080p, 720p, 360p e 144p.

A ideia é pegar o vídeo que o seu usuário enviou, identificar a qualidade dele (pela resolução) e com isso converter este mesmo vídeo em qualidades (resoluções) menores, de modo a salvar tudo isso em arquivos separados.

No caso daquele vídeo do Youtube, é bem provável que o autor tenha o enviado em formato 1080p, e que por de baixo dos panos, a própria plataforma gerou os vídeos em formato 720p, 360p e 144p.

Isso significa dizer que nos servidores do Youtube, existem ao todo 4 vídeos similares mas com resoluções diferentes!

Se o vídeo tivesse suporte a 8k, ao todo teríamos 8 arquivos diferentes salvos no mesmo servidor (8k, 4k, 3k, 2k, 1080p, 720p, 360p e 144p).

Portanto, quando o vídeo do usuário chegar no seu servidor (back-end) mude a qualidade do vídeo e ofereça versões diferentes pensando na velocidade de conexão do usuário que vai consumir o vídeo

E como eu pego a velocidade de conexão dele? Bem, isso já é um outro assunto. Mas é possível de ser feito 🙂 

Armazenou e separou o vídeo do seu usuário em arquivos diferentes? Show, agora, sempre quando o usuário requisitar um vídeo na sua plataforma, primeiro identifique a velocidade de conexão dele, e após isso use a metodologia de transcoding para fornecer o vídeo para ele em pequenos segmentos 🤓

Tudo o que o transcoding faz, é pegar um daqueles arquivos salvos no armazenamento do servidor (1080p.mp4) cortar ele em pequenos segmentos (HSL), e ir enviado para o player do vídeo do navegador do usuário. É dessa forma que solucionamos aquele problema de segurança relacionado ao envio do vídeo de uma única vez.

No caso do formato HLS (HTTP Live Streaming), apesar dele levar o nome "live streaming", ele também pode ser usado para vídeos gravados e representa uma das melhores alternativas para servidores de streaming de vídeos.

É por conta do HSL que os vídeos que começam com uma qualidade mais baixa, vão ganhando qualidade de forma gradual, pois como a execução é por seguimento, se o sistema identificar que a internet do usuário "melhorou", ele mesmo pode carregar os segmentos de qualidade maiores, tudo isso sem interromper a reprodução do vídeo.

Incrível não?

É possível fazer transcoding in-loco quando o usuário faz a requisição do vídeo?

Sim, é possível. Por exemplo, em vez de você gerar diversos arquivos em diferentes qualidades, você pode manter armazenado somente do arquivo original (sem fazer essa conversão) e na hora em que o usuário requisitar o vídeo, o back-end abre o arquivo original e vai fazer as conversões (transcoding) para qualidades menores em tempo real 🤩

Só que tem um grande problema nisso, o fato de estarmos convertendo in-loco (tempo real), resultada em mais processamento por parte do servidor para um mesmo arquivo.

Enquanto na metodologia anterior, você faz essa conversão apenas uma vez que é somente quando o usuário faz o upload.

Portanto, apesar do transcoding in-loco ser totalmente possível, ele apresenta uma perda de performance gigantesca se comparado ao método proposto no tópico anterior.

Não faça transcoding in-loco 😶‍🌫️

Como lidar com a aceleração de vídeo? (1x, 1.5x, 2x...)

Quando deixamos que o player de vídeo realize a aceleração, pode ter certeza que isso vai exigir mais da sua conexão com a internet, uma vez que cada seguimento HLS, vai precisar ser baixado em tempo suficiente para manter a mesma velocidade de reprodução.

Como alternativa, você pode fazer a técnica do transcoding in-loco (tempo real) de forma a entregar o vídeo acelerado (ou mais lento) ou quem sabe realizar o transcoding somente no upload, ou pedir para que seu usuário envie um único arquivo de forma acelerada por padrão.

Realizando o transcoding uma única vez após o upload, você poderia não só ter o mesmo vídeo em qualidades diferentes, como também o mesmo vídeo em velocidades diferentes 🙃

Como última alternativa você poderia deixar que a aceleração seja administrada pelo próprio player de vídeo (sem precisar fazer nenhum tipo de transcoding por parte do servidor).

Mas atente-se que esse processo vai existir mais da sua conexão com a internet (ou a do seu usuário).

Como separar a arquitetura de um sistema que realiza streaming de vídeo?

A melhor forma de fazer isso é possuindo 4 servidores diferentes 

Servidor 1) É o servidor onde estará hospedado o front-end da sua aplicação.

Servidor 2) É o servidor onde estará hospedado o back-end da sua aplicação. (Este back-end não deverá realizar processamento de vídeos).

Servidor 3) É o servidor mais parrudo, que deverá conter a lógica de streaming de vídeo (ele quem faz o transcoding).

Servidor 4) É um servidor próprio para armazenamento de vídeos. (Como um AWS S3, por exemplo).

Lembrando que os servidor 3 deve se conectar diretamente com o servidor 4 (exclusivo para armazenar arquivos estáticos), trazer o vídeo necessário e disponibiliza-lo para o player do usuário.

Qual é a melhor linguagem de programação para se criar uma plataforma de streaming de vídeo?

Sendo bem sincero, apesar das novas linguagens e ambientes de desenvolvimento como Javascript, Typescript, NodeJS... possuírem algumas bibliotecas bastante poderosas.

O mais recomendável é que você escolha linguagens de baixo nível que estão intimamente mais próximas do hardware, como: Java, C#, C++, C, Rust...

Motivo? Performance!

Recapitulando o conteúdo

Para recapitular o conteúdo que aprendemos aqui, o processo de streaming de vídeo funciona da seguinte forma.

Processo de Upload)

1) O usuário faz o upload de um arquivo gigante em 1080p.

2) A aplicação do front-end (que é executada do lado do navegador) faz um pré-processamento desse vídeo de modo a enviar em partes para o servidor.

3) O servidor vai recebendo as partes desse vídeo, e no final junta tudo isso em um único arquivo.

4) Com o arquivo original em mãos, o servidor salva ele em uma pasta que está relacionada a conta daquele usuário (banco de dados do servidor 2 salva a URL do arquivo que está no servidor 4).

5) Em seguida o servidor pega aquele arquivo (por de baixo dos panos) e faz o transcoding de modo a gerar diversos outros arquivos com qualidades e velocidades de reprodução diferentes, por exemplo:

E vai salvando cada um desses arquivos dentro do servidor 4, não se esquecendo de fazer as devidas referencias no banco de dados instalado no servidor 2.

Disponibilizando um vídeo)

1) O usuário aperta no play do vídeo.

2) O Player de vídeo faz uma requisição ao servidor 3 enviando o ID daquele vídeo, que por sua vez realiza todo aquele processo de transcoding com o vídeo que está salvo no servidor 4, e vai enviando ao player de vídeo pedaço por pedaço.

Lembrando que o back-end existente no servidor 3, usa o protocolo HSL para fazer transcoding e enviar cada segmento do vídeo para o player.

Como fica a questão da segurança da aplicação?

Deixo aqui algumas dicas de como você pode melhorar a segurança na hora em que estiver disponibilizando seus vídeos para um usuário.

Implemente um sistema robusto de autenticação e autorização para controlar quem pode acessar e modificar os blobs.

Use uma autenticação forte, como tokens de acesso ou certificados, e atribua permissões de forma granular baseadas em funções ou usuários específicos.

Utilize criptografia adequada para proteger os dados sensíveis nos blobs durante o armazenamento e a transmissão. Isso pode incluir criptografia AES para dados em repouso e SSL/TLS para dados em trânsito.

Implemente controles de acesso rigorosos para garantir que apenas usuários autorizados possam visualizar, modificar ou excluir blobs. Considere usar ACLs (Access Control Lists) para definir políticas de acesso granulares.

Gerencie de forma segura as chaves de criptografia e tokens de acesso utilizados para proteger e acessar os blobs. Utilize serviços de gerenciamento de chaves (KMS) para armazenamento seguro e rotação regular de chaves.

É importante ressaçtar que os vídeos que contêm referências ao termo "blob" geralmente se referem a vídeos armazenados como Binary Large Objects (blobs) em um sistema de armazenamento, como em bancos de dados ou serviços de armazenamento em nuvem.

Apesar disso tudo, nada impede do usuário gravar seu conteúdo usando algum plugin de vídeo download do chrome, ou usar aplicações como Camtasia ou OBS Studio para gravar a tela do desktop.

Conheça a biblioteca de streaming de vídeo da Micilini

Há alguns anos atrás, eu me aventurei na criação de uma plataforma capaz de streamar vídeos.

E com isso lancei uma solução simples baseada em PHP (Laravel) capaz de realizar streaming de vídeo: https://packagist.org/packages/micilini/video-stream

É importante ressaltar que a biblioteca não faz uso de métodos de segurança, e muito menos transcoding ou conversão para arquivos menores.

Mas vale a pena dar uma olhada para entender um pouco como ela funciona.

Conclusão

Neste artigo você aprendeu um pouco mais a fundo sobre o funcionamento de uma plataforma de streaming de vídeos.

Agora cabe a você desenvolver todas as teorias ditas acima e colocá-las em prática na sua própria aplicação 🎥🎬