Transloadit lança o Turbo Mode para codificar vídeos mais rápido
E se eu dissesse que existe uma forma ainda mais rápida de codificar seus vídeos? Se um sorriso já está se formando no seu rosto, prometo não decepcionar você com o que vem a seguir. Uma das novidades mais recentes que criamos aqui na Transloadit é o “Turbo Mode”. Esse novo recurso vai ajudar você a reduzir drasticamente o tempo de codificação de vídeo. Nas próximas seções, vamos passar por vários testes e resultados para mostrar tudo sobre ele.

Noções básicas
Antes de começarmos os testes, é importante que você se familiarize com o nosso Robot /http/import, que usaremos para importar os arquivos de vídeo originais. Existem muitas outras formas de enviar arquivos para a Transloadit, mas neste tutorial vamos importar arquivos disponíveis publicamente por meio de uma URL. O bloco de código abaixo mostra um exemplo de como usá-lo.
{
"imported": {
"robot": "/http/import",
"url": "https://file.com/video.mp4"
}
}
Em seguida, passaremos os arquivos importados para os nossos Robots de codificação de vídeo.
Antes de executar os exemplos, crie uma Credencial de Template do S3 chamada s3_cred
para o seu bucket de destino. As saídas de streaming adaptativo também precisam das
configurações de CORS necessárias
para reprodução no navegador a partir de outra origem.
Usaremos cinco arquivos de vídeo de tamanhos diferentes para testar o nosso Turbo Mode:
video-XS.mp4- 10 MB de tamanho.video-S.mp4- 34 MB de tamanho.video-M.mp4- 260 MB de tamanho.video-L.mp4- 1,2 GB de tamanho.video-XL.mp4- 6,4 GB de tamanho.
Bem, estes não são benchmarks científicos: sou eu executando a codificação três vezes para cada arquivo e calculando o tempo médio, mas isso deve dar uma noção básica do impacto do Turbo Mode em diferentes tamanhos de arquivo de vídeo.
Benchmark 1 - Comparação entre a codificação normal de WebM 720p e o Turbo Mode
Vamos dar uma olhada no Template abaixo:
{
"steps": {
"imported": {
"robot": "/http/import",
"url": "https://example.com/files/video.mp4"
},
"webm_720p_encoded": {
"use": "imported",
"robot": "/video/encode",
"result": true,
"ffmpeg_stack": "v7",
"preset": "webm",
"width": 1280,
"height": 720
},
"exported": {
"use": "webm_720p_encoded",
"robot": "/s3/store",
"credentials": "s3_cred"
}
}
}
No Template acima, primeiro usamos o Robot /http/import para importar um
arquivo e depois fazemos o Robot /video/encode codificar o vídeo com a predefinição webm,
antes de exportarmos os resultados para o Amazon S3.
Agora, teremos que executar esses testes novamente para cada um dos cinco arquivos de vídeo selecionados na seção Noções básicas. Depois disso, anotaremos as diferenças de tempo.
Estou usando o SDK de Node.js para criar Assemblies, mas você também poderia testar isso ao vivo no site da Transloadit, na sua conta, ou usar um dos nossos muitos outros SDKs.
Em seguida, repetimos o mesmo processo para a mesma URL, mas desta vez adicionando
turbo: true ao Step /video/encode, ativando assim
o Turbo Mode.
Para o Turbo Mode, o nosso Template ficaria assim:
{
"steps": {
"imported": {
"robot": "/http/import",
"url": "https://example.com/files/video-S.mp4"
},
"webm_720p_encoded": {
"use": "imported",
"robot": "/video/encode",
"result": true,
"ffmpeg_stack": "v7",
"preset": "webm",
"width": 1280,
"height": 720,
"turbo": true
},
"exported": {
"use": "webm_720p_encoded",
"robot": "/s3/store",
"credentials": "s3_cred"
}
}
}
Depois de executar os testes nesses dois cenários, chegamos ao seguinte quadro de resultados:
| Arquivo | Tamanho | Duração normal | Com Turbo Mode | Tempo economizado |
|---|---|---|---|---|
video-XS.mp4 | 10 MB | 00:01:14 | 00:00:49 | 33,78% |
video-S.mp4 | 34 MB | 00:01:13 | 00:00:45 | 38,36% |
video-M.mp4 | 260 MB | 00:01:51 | 00:00:41 | 63,06% |
video-L.mp4 | 1,2 GB | 00:29:41 | 00:04:01 | 86,47% |
video-XL.mp4 | 6,4 GB | 02:07:02 | 00:17:42 | 86,09% |
Como você pode ver, nos Jobs de codificação de vídeo comuns, estamos pulverizando os tempos de codificação em todos os casos. 😱🏎
Abaixo está um gráfico que explica melhor as nossas descobertas:

Benchmark 2 - Comparação entre a codificação normal de HLS e o Turbo Mode
Agora vamos dar uma olhada no seguinte Template:
{
"steps": {
"imported": {
"robot": "/http/import",
"url": "https://example.com/files/video-S.mp4"
},
"360p_hls_encoded": {
"use": "imported",
"robot": "/video/encode",
"ffmpeg_stack": "v7",
"preset": "hls-360p"
},
"hls_bundled": {
"use": {
"steps": ["360p_hls_encoded"],
"bundle_steps": true
},
"robot": "/video/adaptive",
"ffmpeg_stack": "v7",
"playlist_name": "my_playlist.m3u8",
"technique": "hls"
},
"exported": {
"use": "hls_bundled",
"robot": "/s3/store",
"path": "${file.meta.relative_path}/${file.name}",
"credentials": "s3_cred"
}
}
}
No Template acima, assim como quando codificamos para o formato webm, usamos
o Robot /http/import para importar um arquivo e depois fazemos o
Robot /video/encode codificá-lo para preparar segmentos para o Robot /video/adaptive.
Em seguida, exportamos todos os resultados para o Amazon S3.
E, novamente, teremos que executar o teste para todos os nossos cinco arquivos.
Em seguida, vamos repetir o mesmo processo para todos os vídeos, mas desta vez um dos nossos
Steps contém turbo: true:
{
"steps": {
"imported": {
"robot": "/http/import",
"url": "https://example.com/files/video-S.mp4"
},
"360p_hls_encoded": {
"use": "imported",
"robot": "/video/encode",
"ffmpeg_stack": "v7",
"turbo": true,
"preset": "hls-360p"
},
"hls_bundled": {
"use": {
"steps": ["360p_hls_encoded"],
"bundle_steps": true
},
"robot": "/video/adaptive",
"ffmpeg_stack": "v7",
"playlist_name": "my_playlist.m3u8",
"technique": "hls"
},
"exported": {
"use": "hls_bundled",
"robot": "/s3/store",
"path": "${file.meta.relative_path}/${file.name}",
"credentials": "s3_cred"
}
}
}
Agora o quadro de resultados traz alguns dados interessantes:
| Arquivo | Tamanho | Duração normal | Com Turbo Mode | Tempo economizado |
|---|---|---|---|---|
video-XS.mp4 | 10 MB | 00:00:19 | 00:00:25 | -31,58% |
video-S.mp4 | 34 MB | 00:00:21 | 00:00:28 | -33,33% |
video-M.mp4 | 260 MB | 00:00:45 | 00:00:40 | 11,11% |
video-L.mp4 | 1,2 GB | 00:04:43 | 00:04:05 | 13,43% |
video-XL.mp4 | 6,4 GB | 00:32:12 | 00:23:01 | 28,52% |
Como você pode ver, no primeiro arquivo, que tinha 10 MB, houve um aumento de 31,58% no tempo de codificação. Isso acontece porque o arquivo era pequeno demais para ser dividido em partes e, por isso, arcamos com a sobrecarga adicional imposta pelo Turbo Mode sem nenhum benefício.
Da mesma forma, no segundo arquivo, de 34 MB, tivemos um aumento de 33,33% no tempo de codificação. Curiosamente, porém, o arquivo de 260 MB teve um ganho de cerca de 11,11% no tempo de codificação. E, como esperado, no quarto e no quinto arquivos, os tempos de codificação também melhoraram 13,43% e 28,52%, respectivamente.
Portanto, fica claro que, quanto maior o arquivo, mais velocidade ganhamos ao codificar para HTTP Live Streaming (HLS).
Este gráfico explica melhor as descobertas:

Benchmark 3 - Comparação entre a codificação normal de MPEG-DASH e o Turbo Mode
Para o nosso teste final, vamos dar uma olhada neste Template:
{
"steps": {
"imported": {
"robot": "/http/import",
"url": "https://example.com/files/video-S.mp4"
},
"360p_dash_encoded": {
"use": "imported",
"robot": "/video/encode",
"ffmpeg_stack": "v7",
"preset": "dash-360p-video"
},
"dash_bundled": {
"use": {
"steps": ["360p_dash_encoded"],
"bundle_steps": true
},
"robot": "/video/adaptive",
"ffmpeg_stack": "v7",
"playlist_name": "my_playlist.mpd",
"technique": "dash"
},
"exported": {
"use": "dash_bundled",
"robot": "/s3/store",
"path": "${file.meta.relative_path}/${file.name}",
"credentials": "s3_cred"
}
}
}
Em comparação com o Template anterior para HLS, bastou usar o dash-360p-video preset no
Step /video/encode e trocar o technique usado pelo Robot
/video/adaptive para dash.
Novamente, para os testes com Turbo Mode, basta adicionar turbo: true ao Step /video/encode.
Depois de executar todos os testes, obtemos os seguintes resultados:
| Arquivo | Tamanho | Duração normal | Com Turbo Mode | Tempo economizado |
|---|---|---|---|---|
video-XS.mp4 | 10 MB | 00:00:15 | 00:00:19 | -26,67% |
video-S.mp4 | 34 MB | 00:00:16 | 00:00:20 | -25% |
video-M.mp4 | 260 MB | 00:00:43 | 00:00:40 | 6,98% |
video-L.mp4 | 1,2 GB | 00:02:59 | 00:02:04 | 30,73% |
video-XL.mp4 | 6,4 GB | 00:22:29 | 00:12:51 | 42,85% |
Como esperado (porque HLS e DASH são tecnologias muito semelhantes), estamos vendo uma perda de velocidade em arquivos menores. Só a partir da marca de ~200 MB começamos a ver um aumento de velocidade.
O gráfico abaixo explica melhor essas descobertas:

Conclusão dos benchmarks
Os vários testes acima demonstraram quanto tempo você pode economizar usando o Turbo Mode. Nos
Steps /video/encode que não são a entrada de um Step adaptativo,
estamos vendo aumentos de velocidade em todos os casos. Quando você usa tecnologias de streaming
adaptativo, porém, é prudente levar em consideração o tamanho dos arquivos.
Isso está alinhado com a forma como o Turbo Mode foi construído internamente. Nossa equipe de API desenvolveu um algoritmo personalizado que se integra ao FFmpeg, permitindo distribuir a carga de trabalho de um único Job de codificação de vídeo entre muitas máquinas. Orquestrar a paralelização em si leva algum tempo, mas, em arquivos maiores, essa sobrecarga compensa bem o investimento.
Se você não tiver como saber o tamanho dos arquivos com antecedência, pode usar o nosso Robot /file/filter para direcionar o tráfego para um Step com o Turbo Mode ativado, dependendo do tamanho do arquivo.
Preços
Muita pesquisa e desenvolvimento foram necessários para criar o Turbo Mode, mas estamos oferecendo essa melhoria a todos os clientes sem custo adicional (as tarifas normais continuam valendo). Esperamos que seus usuários aproveitem o aumento de velocidade ao fazer upload de suas mídias.
Próximos passos
Atualização (setembro de 2026): o roadmap abaixo descreve nossos planos de 2018. O parâmetro
turboatual aceitatrueoufalsee temfalsecomo padrão;"auto"não é suportado.
Na nossa próxima iteração, vamos introduzir um modo turbo: 'auto' que ativa automaticamente o Turbo Mode
quando esperarmos economia de tempo, depois de coletarmos mais dados. Ele continuará sendo opcional
(opt-in) até acumular meio petabyte de uso em produção; nesse ponto, se estivermos confiantes o
suficiente, tornaremos turbo: 'auto' o padrão e permitiremos a desativação (opt-out) via turbo: false.
Enquanto isso, convidamos todos os nossos clientes a experimentar turbo: true em cargas de trabalho que
não sejam críticas para o negócio e não exijam resultados impecáveis. Dúvidas, comentários e
preocupações são muito bem-vindos pela nossa página de suporte.
