Streamline: o processamento de vídeo precisa sobreviver à requisição que o iniciou

A Cloudflare publicou Streamline, um playground e uma implementação aberta de processamento de vídeo com Stream, Workers, Durable Objects e Containers.[16] O Media Engine executa num Container, com controlador HTTP em Go e FFmpeg como processador atual, enquanto Worker e Durable Object participam do controle e da prévia.[16] É uma referência de arquitetura, não apenas uma opção pronta de transcodificação.

O que muda para quem desenvolve

A aplicação pode desconectar e retornar enquanto a sessão continua até uma parada explícita ou duração máxima, e o desenho mantém atividade suficiente para evitar a suspensão do container no meio do processamento.[16] Minha leitura é que o trabalho longo precisa ter identidade e ciclo de vida próprios, separados da conexão que o iniciou.

Esse princípio é útil para exportações, relatórios e outras tarefas demoradas: a interface deve consultar e controlar a execução, não ser a única responsável por mantê-la viva. Recomendo estados explícitos, responsável pela sessão e limites que encerrem trabalho abandonado.

O modelo privado descrito vincula a sessão ao usuário e admite somente uma sessão ativa; o playground público utiliza controles por usuário e limites globais de admissão e concorrência.[16] Os dois desenhos não devem ser confundidos ao transformar uma referência em produto multiusuário.

Como aplicar

Proponho uma avaliação com vídeo próprio e curto. Inicie uma sessão, acompanhe a prévia, desconecte a interface e retorne para consultar o estado. Verifique parada explícita, encerramento por limite e liberação de recursos. Registre o comportamento observado, sem assumir que reconectar significa criar outro trabalho.

Numa implantação de teste multiusuário, inclua duas identidades sintéticas. Tente consultar e encerrar a sessão da primeira com a segunda. O resultado esperado deve ser definido na política da aplicação antes do teste. Acrescente um limite de concorrência pequeno e confira como novas solicitações são recusadas.

O projeto mantém chaves de entrada e saída do Stream em segredos ou configurações sem devolvê-las ao navegador.[16] Preserve essa separação ao adaptar a referência: a interface deve receber identificadores de destinos autorizados, não credenciais brutas de publicação.

Cuidados e limites

A versão atual processa mídia na CPU do Container; aceleração de hardware, WebRTC e outras primitivas aparecem como direções futuras.[16] Não prometa qualidade ou simultaneidade sem medir a carga desejada.

O desenvolvimento local usa Docker e conexão direta, sem Durable Object e sem os controles de acesso da implantação remota.[16] Funcionar localmente não valida a segurança do serviço publicado.

O rollout descrito inclui um bypass temporário e restrito que deve ser substituído por autenticação de serviço após a validação inicial.[16] Uma exceção de implantação não deve virar política permanente. O ganho arquitetural é separar controle, execução e segredos; o custo é operar e testar essas fronteiras de forma explícita.

Fonte

[16] Fonte: Cloudflare Blog