Criei um encoder de vídeo com FFmpeg e EffectTS (com deploy na AWS via Pulumi)

Este projeto aborda a criação de um encoder de vídeo complexo, impulsionado pela necessidade de otimizar custos e performance em plataformas de streaming. O objetivo é recriar do zero um algoritmo de encoding de vídeo, similar ao que plataformas como YouTube utilizam, porém com controle total sobre as configurações e, crucialmente, sem incorrer em custos exorbitantes. A motivação reside na busca por um controle granular sobre o processo de conversão de vídeo, permitindo ajustes finos para diferentes tipos de conteúdo e garantindo a melhor qualidade possível de forma econômica, especialmente para aplicações como um Serviço de Assinatura (SAS) pessoal.

O processo de encoding, ou transcoding, de vídeo é fundamental para a distribuição de conteúdo online. Ele envolve a conversão de um arquivo de vídeo em múltiplas resoluções e formatos, adaptados para diferentes dispositivos e qualidades de conexão. Tecnologias como HLS (HTTP Live Streaming) ou Dash permitem que o player ajuste a qualidade do vídeo em tempo real, proporcionando uma experiência de visualização fluida. A complexidade reside na escolha de codecs de áudio e vídeo, bitrates e configurações específicas para cada tipo de conteúdo, tornando o processo computacionalmente intensivo e custoso se não for otimizado.

O desafio principal foi recriar este algoritmo de encoding do zero, visando um deploy altamente performático e escalável na AWS. A prioridade era gerenciar os custos de forma eficaz, evitando despesas milionárias. O projeto visa oferecer controle total sobre os parâmetros de conversão, permitindo alcançar as melhores configurações possíveis. Isso inclui a divisão do vídeo em segmentos, a geração de thumbnails e a criação de playlists mestras para streaming adaptativo, tudo executado de maneira automatizada e econômica.

A arquitetura do sistema foi desenhada para ser desacoplada e escalável. O ponto de entrada é uma fila na AWS SQS (Simple Queue Service), onde os vídeos a serem processados são enfileirados. Um 'worker', que é um nó de processamento rodando em uma instância EC2, consome essas mensagens da fila. Após o encoding, os arquivos resultantes são enviados para o Cloudflare R2, um serviço de armazenamento de objetos. Para notificar o sistema principal sobre o progresso e o status do encoding, utiliza-se o AWS SNS (Simple Notification Service), que envia mensagens para webhooks.

O fluxo se inicia com o upload de um vídeo para a fila SQS. O worker processa o vídeo, convertendo-o para as resoluções definidas e dividindo-o em segmentos de 4 segundos. Cada segmento é então enviado para o Cloudflare R2. Paralelamente, o sistema gera thumbnails e uma master playlist (M3U8), que referencia todas as resoluções e seus respectivos arquivos. Conforme cada etapa é concluída, o progresso é notificado via SNS, permitindo o acompanhamento em tempo real, similar à experiência do YouTube.

A execução do script de encoding é demonstrada utilizando um input pré-definido. O processamento é otimizado através da concorrência. Em vez de processar cada resolução sequencialmente, o sistema processa e faz o upload de dois segmentos de vídeo simultaneamente (por exemplo, 240p e 480p), e depois os próximos (720p e 1080p). Essa abordagem visa maximizar o uso dos recursos de CPU e banda de upload, pois enquanto um segmento está sendo enviado para o storage, a CPU pode ser utilizada para processar o próximo.

A estratégia de processar duas resoluções em concorrência é crucial. Ela permite que a tarefa de upload de segmentos de uma resolução ocorra simultaneamente com o processamento da próxima. Isso significa que a largura de banda de upload e a CPU da máquina não ficam ociosas. Quando o upload de um segmento está em andamento, a CPU não utilizada pode começar a converter o próximo formato. Essa paralelização garante a utilização máxima dos recursos disponíveis, acelerando significativamente o tempo total de encoding.

O sistema emite logs de progresso detalhados, indicando a porcentagem de conclusão à medida que cada resolução e etapa são finalizadas. Ao final, uma mensagem de sucesso (100%) é enviada. Para uma observabilidade ainda maior, a aplicação implementa tracing. Ferramentas como Jaeger permitem visualizar cada etapa do código, incluindo a conversão de cada resolução e a geração de thumbnails, além do tempo exato que cada processo levou. Isso fornece um detalhamento granular essencial para otimizações futuras.

A implementação de tracing é um diferencial importante. Cada efeito (função) no EffectTS gera um span, que é visível na ferramenta de tracing. Isso permite monitorar em tempo real quanto tempo leva cada conversão de resolução (ex: 240p, 480p, 720p, 1080p) e até mesmo a geração de thumbnails, que leva menos de um segundo. Essa granularidade na observabilidade é vital para identificar gargalos e otimizar o desempenho do processo de encoding.

O projeto faz uso extensivo do EffectTS, uma biblioteca que eleva o nível de segurança e robustez do TypeScript, inspirada em linguagens funcionais. Ele introduz recursos avançados para tratamento de erros, inversão de dependência e uma maneira estruturada de compor efeitos (funções). Isso garante que erros não tratados sejam capturados e que o fluxo de dados e dependências seja claro e gerenciável, prevenindo falhas inesperadas em produção.

O arquivo principal `worker.ts` inicia o processo. Ele consome mensagens da fila SQS, cada uma contendo a URL do vídeo a ser processado. Para armazenar dados temporariamente durante a execução, é utilizado um banco de dados em memória (`Map`), pois os workers são efêmeros, executando e sendo descartados após cada job, eliminando a necessidade de um banco de dados persistente como PostgreSQL para esta tarefa.

A função `encodeVideo` orquestra o processo. Ela utiliza o FFmpeg para converter o vídeo de entrada em múltiplos segmentos de 4 segundos. Esses segmentos são salvos em um diretório temporário. O EffectTS é usado para adicionar spans de tracing a cada etapa, facilitando a visualização do fluxo de execução e a identificação de gargalos de performance na conversão e geração de arquivos.

Um 'watcher' é implementado para monitorar a pasta de arquivos temporários. Toda vez que um novo segmento de vídeo é gerado, ele é automaticamente enviado para o Cloudflare R2. Após o upload de todos os segmentos, o FFmpeg é novamente empregado para gerar thumbnails e a master playlist (M3U8). Esta playlist contém referências para cada resolução e seus respectivos arquivos, além da informação de banda necessária para cada nível de qualidade, viabilizando o streaming adaptativo.

A implantação da infraestrutura na AWS é realizada através de Infraestrutura como Código (IaC), utilizando Pulumi. Esta abordagem permite definir e gerenciar recursos de nuvem usando código TypeScript, integrando-se perfeitamente com o ecossistema de desenvolvimento existente. O Pulumi orquestra a criação e configuração de todos os serviços necessários para o worker de encoding.

Os componentes essenciais da infraestrutura AWS configurados via Pulumi incluem: uma fila SQS para gerenciar os trabalhos de encoding (com um timeout de visibilidade de 20 minutos para garantir a repetição em caso de falha); um tópico SNS para enviar notificações de progresso e status para webhooks; e um repositório ECR (Elastic Container Registry) para armazenar as imagens Docker do worker, mantendo tudo dentro do ecossistema AWS.

O worker de encoding é empacotado em uma imagem Docker, que inclui a instalação do FFmpeg e a aplicação TypeScript. O deploy na AWS é feito através da criação de uma instância EC2 configurada para executar este contêiner Docker. A instância é configurada para utilizar todos os recursos disponíveis (CPU e memória), garantindo a máxima performance para a tarefa de encoding.

Para otimizar os custos, optou-se pelo uso de instâncias EC2 do tipo C8G.16xlarge, conhecidas por sua alta performance. Crucialmente, a precificação dessas instâncias é configurada para operar em modo 'Spot'. Instâncias Spot utilizam capacidade ociosa da AWS a preços significativamente mais baixos, sendo ideais para cargas de trabalho tolerantes a interrupções, como o nosso worker de encoding.

Para gerenciar a escalabilidade de forma automática, uma função AWS Lambda foi criada. Essa Lambda é executada a cada minuto e monitora o número de mensagens pendentes na fila SQS. Com base nessa contagem, ela ajusta dinamicamente o número de instâncias EC2 worker em execução, utilizando um grupo de Auto Scaling. Isso garante que recursos sejam provisionados apenas quando há trabalho a ser feito e desligados quando ociosos, otimizando custos.

A função Lambda implementa uma lógica de auto-scaling. Ao verificar a fila SQS, ela determina se o número de jobs exige a criação de novas instâncias worker ou o encerramento das existentes. Essa escalabilidade automática, configurada entre um mínimo e um máximo de instâncias, assegura que o sistema lide eficientemente com picos de demanda sem provisionamento excessivo, mantendo a performance e o controle de custos.

Durante a demonstração ao vivo, um vídeo foi manualmente adicionado à fila SQS. A Lambda de scaling detectou a nova tarefa e iniciou o provisionamento de uma instância EC2 Spot. No entanto, surgiram problemas iniciais: um erro de conexão SSH, possivelmente devido a uma AMI incorreta que incluía o agente SS indesejado, e falta de espaço em disco na instância EC2 padrão. Para solucionar, foi configurado um volume EBS de 30 GB e ajustada a configuração da AMI para uma imagem mais adequada, garantindo a correta inicialização do Docker e da aplicação.

Os desafios encontrados durante a demonstração, como falhas na conexão SSH e restrições de espaço em disco, foram superados através de ajustes na configuração da instância EC2. A utilização de uma AMI mínima e a adição de um volume EBS (Elastic Block Storage) resolveram a falta de espaço. Posterior criação de uma AMI customizada com Docker pré-instalado visa acelerar ainda mais o tempo de inicialização dos workers. Com as correções, o sistema de scaling e a execução do worker foram verificados com sucesso.

Com as correções implementadas, a demonstração prosseguiu com sucesso. A instância EC2 foi provisionada e o container do encoder iniciado. Notificações de progresso via webhook foram recebidas em tempo real, mostrando o avanço do processamento das diferentes resoluções (240p, 480p, 720p, 1080p), com o sistema atingindo 20%, 40% de progresso à medida que cada etapa era concluída. Este fluxo demonstra a efetividade da arquitetura e das otimizações aplicadas.

Ao final do processamento, o sistema calcula o custo exato para a conversão de cada vídeo. Utilizando os metadados da instância e o histórico de preços Spot, foi possível determinar que o processamento de um vídeo de 3 GB, que resultou em cerca de 1 GB de dados de saída distribuídos em múltiplas resoluções, custou aproximadamente 11 centavos de dólar na AWS. Isso se traduz em cerca de 50 centavos por hora de vídeo processado, um custo bastante acessível e absorvível.

O custo de processamento de vídeo foi drasticamente reduzido graças ao uso de instâncias Spot e à escalabilidade automática. O exemplo de um vídeo de 3 GB convertido para aproximadamente 900 MB, com todas as resoluções e segmentos gerados, teve um custo de apenas 11 centavos. Essa métrica demonstra a viabilidade econômica da solução, permitindo que o serviço seja oferecido de forma competitiva. Os arquivos resultantes, incluindo os milhares de segmentos, foram armazenados com sucesso no Cloudflare R2.

Se você é um dev ruim, cara, o teu código com IA vai ficar ruim, não tem como, porque quanto mais específico tu for e direcionar a IA, ela vai conseguir ter resultados melhores. Se tu for uma pessoa que traz problemas para IA de uma maneira muito aberta, ela vai te dar resultados muito genéricos e que são muito ruins, muitas vezes pouco performáticos.

A experiência de desenvolver este projeto em duas semanas ressalta a importância de enfrentar desafios técnicos. O uso de ferramentas de IA como Cursor e Cloud Code demonstra um caminho para aumentar a produtividade. Contudo, a qualidade final do código e a eficácia das decisões técnicas permanecem intrinsecamente ligadas às bases e ao conhecimento aprofundado do desenvolvedor. Uma compreensão sólida dos fundamentos é essencial para direcionar a IA de forma eficaz e evitar a geração de soluções genéricas e pouco performáticas.

Este projeto, resultado de semanas de trabalho incansável, ilustra como é possível criar soluções de processamento de vídeo complexas e eficientes na nuvem. O aprendizado contínuo e a busca por desafios técnicos são fundamentais. O convite é aberto para que a audiência compartilhe suas opiniões sobre o projeto, a IA no desenvolvimento e sugestões para futuros conteúdos mais detalhados, como sobre o EffectTS.