Nota para revisão: este é um projeto pessoal/interno, sem link público para demonstração. O texto abaixo é técnico, descrevendo a arquitetura real do sistema — não há métricas de negócio (visualizações, receita, número de canais geridos) documentadas para citar aqui. Se você tiver esses números e quiser divulgá-los, me avisa que eu encaixo na seção de Resultados.
Problema
Cortar os melhores momentos de vídeos longos (lives, podcasts, streams) para publicar como shorts e clips é um trabalho repetitivo: assistir o vídeo inteiro, identificar os trechos com potencial, cortar, gerar título e descrição, e publicar respeitando os limites de cada plataforma. Feito manualmente, esse processo não escala — quanto mais canais e mais vídeos por dia, mais tempo humano é consumido em uma tarefa que é, na maior parte, decisão de padrão (o que é um bom trecho) e trabalho mecânico (cortar, formatar, publicar).
O objetivo era eliminar a intervenção manual do processo inteiro: do momento em que um vídeo novo aparece em um canal monitorado até a publicação do clip, sem um humano assistindo, cortando ou escrevendo a legenda.
Solução
Desenvolvi um pipeline que monitora canais do YouTube via RSS, baixa os vídeos novos, transcreve o áudio, usa um LLM para identificar os melhores trechos e gerar metadados (título, descrição, tags), corta e pós-processa o vídeo com FFmpeg, e publica respeitando cota diária por canal e um sistema round-robin entre canais monitorados.
O sistema é dividido em dois serviços independentes, cada um com sua responsabilidade:
- Um daemon em Python que cuida de todo o pipeline de mídia: monitoramento por RSS, download dos vídeos, transcrição de áudio com Whisper (rodando via Groq, pela velocidade de inferência), seleção de trechos e geração de título/descrição/tags via Claude, corte e pós-produção com FFmpeg, e publicação nas plataformas de destino.
- Um painel administrativo em Laravel com Filament, onde é possível acompanhar o que o pipeline está fazendo, revisar canais monitorados, cota de publicação e histórico de clips gerados.
Arquitetura
Os dois serviços rodam em containers Docker separados e se comunicam por uma API interna autenticada — o daemon Python não tem acesso direto ao banco do painel, e o painel não executa nenhuma etapa do pipeline de mídia diretamente. Essa separação foi deliberada: o daemon é o worker que processa vídeo (CPU e I/O pesados, roda continuamente), e o Laravel é a camada de gestão e visibilidade (baixo tráfego, interface administrativa). Separar os dois evita que um problema de performance no processamento de vídeo afete a disponibilidade do painel, e vice-versa.
Redis entra em três pontos: deduplicação (evitar processar o mesmo vídeo duas vezes, importante porque o monitoramento por RSS pode gerar eventos repetidos), controle de cota diária por canal, e cache de metadados que não precisam ser recalculados a cada execução.
A escolha de dividir transcrição (Whisper via Groq) e geração de metadados (Claude) em dois modelos diferentes reflete o que cada um faz melhor e mais barato: Groq é usado pela velocidade de inferência na transcrição de áudio, que é a etapa mais repetida do pipeline (roda para cada vídeo novo), enquanto o Claude entra na etapa de decisão — selecionar o trecho mais interessante e escrever título/descrição/tags que façam sentido para o algoritmo de recomendação de cada plataforma, uma tarefa que se beneficia mais de qualidade de raciocínio do que de velocidade bruta.
A publicação respeita cota diária e faz round-robin entre os canais monitorados, para não sobrecarregar um canal específico nem violar limites de publicação das plataformas.
Decisões de design
Um ponto que vale destacar é a escolha de não construir um único monólito fazendo tudo. Dado que o daemon Python roda continuamente processando fila de vídeos (workload previsível, mas potencialmente pesado em CPU por causa de FFmpeg) e o painel Laravel é acessado esporadicamente para acompanhamento humano, misturar os dois no mesmo processo ou na mesma aplicação criaria acoplamento desnecessário: um pico de processamento de vídeo não deveria deixar o painel lento, e uma consulta pesada no painel não deveria atrasar a fila de publicação.
A API interna autenticada entre os dois serviços também define uma fronteira clara de responsabilidade: o Laravel nunca decide o que cortar ou quando publicar, apenas expõe e recebe dados sobre o que o daemon já decidiu e executou. Isso mantém a lógica de decisão (o que é "melhor momento", como formatar título e descrição) centralizada no lugar onde ela é usada, em vez de espalhada entre dois sistemas.
A round-robin entre canais também é uma decisão deliberada de design: sem ela, o pipeline tenderia a esgotar a cota de publicação nos canais com mais vídeos novos primeiro, deixando canais com cadência menor de atualização sempre por último na fila. O round-robin garante distribuição mais equilibrada de atenção do sistema entre os canais monitorados, independente do volume de conteúdo novo de cada um.
Stack
Python (daemon de processamento), Laravel + Filament (painel administrativo), MySQL (persistência do painel), Redis (deduplicação, cota, cache), Docker (isolamento e deploy dos dois serviços), FFmpeg (corte e pós-produção de vídeo), Whisper via Groq (transcrição), Claude (seleção de trechos e geração de metadados).
Interface do Sistema
