Cortador de vídeo

Corte arquivos de vídeo ajustando o início e o fim. Modo rápido ou preciso.

Seus arquivos nunca saem do seu dispositivo

Arraste e solte um arquivo de vídeo aqui

ou clique para navegar · MP4, WebM, MOV, AVI, MKV (máx 2 GB)

Como funciona

  1. Carregue um arquivo de vídeo : selecione qualquer arquivo MP4, WebM, MOV ou AVI do seu dispositivo, nenhum envio a um servidor.
  2. Ajuste os pontos de corte : use as alças da timeline ou insira horas precisas de início e fim para definir o clipe a manter.
  3. Pré-visualize o corte : reproduza o segmento selecionado para confirmar o corte antes da exportação.
  4. Baixe o clipe : exporte o vídeo cortado diretamente no seu dispositivo no formato original.

Por que usar o cortador de vídeo ?

A maioria dos aplicativos de edição de vídeo exige instalação, assinatura ou envio a servidores na nuvem. Este cortador baseado em navegador processa o vídeo inteiramente no seu dispositivo via WebCodecs e FFmpeg.wasm, suas imagens nunca saem da sua máquina. É ideal para cortar rapidamente introduções e encerramentos, isolar clipes para redes sociais, remover segmentos indesejados de uma gravação e cortar antes de compartilhar. Sem perda de qualidade por reencodagem, a menos que você escolha um formato de saída diferente, e sem limite de tamanho além da memória disponível do seu dispositivo.

Formatos suportados

Cortar, aparar, dividir, e porque as palavras importam

Em linguagem casual «aparar», «cortar» e «dividir» são intercambiáveis. No instrumental de vídeo descrevem três operações diferentes. Um aparo remove conteúdo do início e/ou do fim e mantém tudo no meio. Um corte em terminologia editorial é a fronteira entre dois planos adjacentes numa montagem terminada. Uma divisão pega num clipe e divide-o em dois clipes num ponto escolhido. Do ponto de vista do utilizador, esta ferramenta realiza um aparo, define um início e um fim, e mantém o que está entre eles.

A questão interessante é como remove os bytes indesejados. Duas abordagens fundamentalmente diferentes produzem ficheiros diferentes.

Fast (stream copy) vs Precise (recodificação)

Stream copy, o modo «Fast», não olha para a imagem de todo. Abre o contentor, encontra os intervalos de bytes que correspondem à janela de tempo pedida, copia esses bytes literalmente para um novo contentor, corrige o índice e os timestamps, e escreve o resultado. Não há descodificação, não há recodificação, não há perda de qualidade. Numa máquina moderna um ficheiro H.264 de 500 MB pode ser aparado desta forma em bem menos de um segundo porque o trabalho é essencialmente E/S de ficheiro, não aritmética. O senão: a operação de cópia só pode começar e terminar em certos quadros, especificamente I-frames: e esses não são necessariamente onde apontou. Por isso o início do clipe resultante pode deslocar-se para a frente ou para trás entre zero e dez segundos, dependendo das definições do codec usadas quando o ficheiro foi originalmente codificado.

A recodificação, modo «Precise», descodifica toda a secção afetada de volta a pixels brutos, descarta os quadros antes do início pedido e depois do fim pedido, depois recodifica o resto. Isto produz um clipe que começa e termina exatamente no quadro escolhido (preciso ao quadro, em terminologia da indústria) ao custo de uma codificação completa. Uma codificação completa é centenas ou milhares de vezes mais lenta do que um stream copy e introduz uma geração de perda de compressão porque os codecs com perdas não são idempotentes: codificar, descodificar e recodificar a mesma imagem não lhe devolve exatamente a mesma imagem. A perda é pequena em taxas de bits altas mas não é zero, e acumula-se se o mesmo ficheiro for aparado repetidamente.

O caminho Fast é correto para 95% dos casos onde o utilizador remove intros, outros ou material aproximado no início e fim e não se importa se o corte está a meio segundo de onde apontou. O caminho Precise é a ferramenta certa quando o corte precisa de cair num quadro específico, um punchline, um efeito sonoro, uma marca de sincronização para uma edição a jusante.

I-frames, P-frames, B-frames, e o GOP

Cada codec de vídeo moderno (H.264, H.265 (HEVC), VP9, AV1) comprime vídeo explorando o facto de que quadros consecutivos são quase a mesma imagem. Em vez de codificar cada quadro independentemente, o codec codifica uma pequena fração de quadros em pleno e o resto como diferenças face aos seus vizinhos. Os quadros completos são I-frames (intra-codificados). Os quadros de diferença vêm em duas variedades: P-frames (previstos apenas a partir de quadros anteriores) e B-frames (codificados bipreditivamente, podem referenciar quadros anteriores e posteriores). A sequência I, depois uma série de quadros P e B, depois outro I, chama-se Group of Pictures, ou GOP. Dentro de um GOP, nenhum quadro pode ser descodificado sem referência ao I-frame no início. Entre GOPs não há dependência: um leitor pode entrar no ficheiro em qualquer I-frame e começar a descodificar a partir daí.

É por isso que o aparo por stream copy está restringido aos limites de keyframes. Para começar um novo ficheiro num não-I-frame teria de descodificar o I-frame no início do GOP, depois descodificar cada quadro P e B até ao seu ponto escolhido, depois começar a escrever, que é exatamente o que o caminho Precise faz. Um ficheiro H.264 típico usa um comprimento de GOP de dois a quatro segundos. O libx264 do FFmpeg usa por defeito cerca de 250 quadros (~10 segundos a 25 fps, ~8,3 segundos a 30 fps). Os fornecedores de streaming encurtam isso para dois segundos para alinhar com os limites de segmento HLS e DASH. H.265 tolera GOPs mais longos mais eficientemente e é frequentemente configurado entre quatro e dez segundos. VP9 (libvpx) tem por defeito uma distância máxima de keyframe de 240 quadros. AV1 normalmente cai no intervalo de 2-6 segundos. A implicação prática: um utilizador a pedir um corte ao minuto 1 segundo 30 pode, dependendo do que o ficheiro foi originalmente codificado, acabar com um resultado de stream copy que começa em qualquer lugar entre minuto 1 segundo 24 e minuto 1 segundo 32.

Uma breve história do FFmpeg

FFmpeg foi iniciado a 20 de dezembro de 2000 por Fabrice Bellard, o cientista de computação francês que tinha previamente escrito o virtualizador QEMU e o compilador C TCC. Fez commit sob o pseudónimo Gérard Lantau. O nome vem de «FF» para fast forward e «mpeg» para a família de codecs que originalmente foi desenhado para tratar. A arquitetura desde o início separou a implementação de codec (libavcodec) do parsing de contentor (libavformat), por isso o FFmpeg foi tão facilmente estendido ao longo dos anos. Bellard entregou a manutenção a Michael Niedermayer em 2004. O projeto sobreviveu a um fork célebre em 2011 quando um grupo de programadores se separou num projeto chamado Libav devido a desentendimentos de governança; os dois projetos voltaram a fundir-se em espírito (se não formalmente) por volta de 2018, com a maioria das melhorias do Libav incorporadas no FFmpeg.

Hoje o FFmpeg é a infraestrutura silenciosa por baixo de uma enorme fração do vídeo do mundo, YouTube, Netflix, VLC, OBS Studio, Audacity, HandBrake, Plex e a maioria dos pipelines de transmissão profissional usam-no algures no seu stack. A versão estável atual a partir de 2026 está na série 8.x. A licença é dupla LGPL-2.1-or-later ou GPL-2.0-or-later dependendo de quais componentes opcionais estão ativados na compilação.

FFmpeg.wasm, FFmpeg no navegador

Em novembro de 2020 um engenheiro taiwanês chamado Jerome Wu: já conhecido pelo port Tesseract.js do motor OCR Tesseract, publicou o primeiro lançamento de FFmpeg.wasm, uma compilação WebAssembly do FFmpeg que corre inteiramente dentro do navegador. Anunciou o projeto a 4 de novembro de 2020. Por 2026 o projeto amadureceu significativamente, com o lançamento atual na série 0.12 e forks comunitários ativos. O pacote npm agora empacota o binário WebAssembly central, um wrapper JavaScript que trata do passagem de mensagens entre o thread principal e o worker thread que executa o WASM, e um sistema de ficheiros virtual que permite ao utilizador mover ficheiros para dentro e fora usando objetos Blob e File de JavaScript ordinários.

O projeto tem um requisito notório que apanha cada programador que tenta implementá-lo pela primeira vez. O FFmpeg.wasm usa SharedArrayBuffer, a API JavaScript para partilhar memória entre o thread principal e worker threads. Depois das vulnerabilidades CPU Spectre e Meltdown serem divulgadas em 2018, os navegadores apertaram as condições: a página tem de ser servida com dois cabeçalhos HTTP específicos, Cross-Origin-Opener-Policy: same-origin e Cross-Origin-Embedder-Policy: require-corp, e cada recurso cross-origin na página tem de optar por CORS ou vir da mesma origem. Sem esses cabeçalhos, SharedArrayBuffer é undefined e o FFmpeg.wasm não inicializará. O Chrome aplica isto estritamente; Firefox e Edge seguem o Chrome; Safari juntou-se a partir da versão 15.2.

Formatos de contentor

Um contentor é a envoltura do ficheiro. Não codifica a imagem; empacota imagens e áudio codificados junto com temporização e metadados.

APIs de vídeo do navegador, o que está realmente disponível

O elemento HTML5 <video> tornou-se Recomendação W3C a 28 de outubro de 2014, após cerca de uma década de desenvolvimento. Antes do HTML5, incorporar vídeo significava Adobe Flash ou Microsoft Silverlight. O elemento por si só não tem API de edição, não há método video.trim(start, end), nem video.cut(), nem forma incorporada de extrair um segmento. Para fazer algo além de play, pause e seek, o programador tem de recorrer a uma API de nível mais baixo ou compilar o FFmpeg na página.

Media Source Extensions (MSE) é uma especificação W3C que permite ao JavaScript construir o fluxo de bytes que alimenta o elemento <video>. Alcançou Candidate Recommendation em 2014; usado em produção pelo YouTube já em setembro de 2013 e pela Netflix a partir de junho de 2014. O seu caso de uso primário é streaming adaptativo (não expõe quadros descodificados, por isso não pode realizar uma recodificação sozinho. WebCodecs é a alternativa de nível mais baixo) expõe diretamente ao JavaScript as implementações de codec de vídeo e áudio incorporadas do navegador, com interfaces VideoDecoder e VideoEncoder. WebCodecs lançou oficialmente no Chrome 94 a 21 de setembro de 2021 após um origin trial no Chrome 93, e desde então chegou ao Firefox e Safari. O estado da arte atual é que as ferramentas usem WebCodecs quando disponível e o codec suportado, e caiam para FFmpeg.wasm caso contrário. Esta ferramenta usa ambos.

Limites de comprimento de plataformas sociais, porque as pessoas abrem trimmers

Uma grande parte da procura por aparo baseado em navegador vem de preparar vídeos para upload em plataformas sociais, cada uma com o seu próprio comprimento máximo:

Estes números mudam constantemente à medida que as plataformas iteram, mas o padrão geral de «a plataforma X rejeitará o seu upload se exceder Y minutos» é durável, e é uma das razões mais comuns pelas quais um utilizador final abre um trimmer em primeiro lugar.

Quando um editor de secretária é a melhor ferramenta

Para utilizadores para quem um trimmer de navegador é insuficiente, o ecossistema profissional gira em torno de algumas aplicações de secretária estabelecidas. Apple ProRes é uma família de codecs intermédios introduzida pela Apple em abril de 2007 juntamente com o Final Cut Studio 2, desenhada para edição, não entrega. Final Cut Pro, originalmente lançado em 1999 pela Macromedia e adquirido pela Apple um ano depois, foi reconstruído e relançado como Final Cut Pro X a 21 de junho de 2011; apenas macOS e o editor padrão em grande parte do mundo do documentário e da transmissão. DaVinci Resolve, originalmente um sistema de gradação de cor topo de gama, foi adquirido pela Blackmagic Design em 2009 e progressivamente reconstruído numa suite completa de edição/pós áudio/efeitos visuais/gradação, disponível para macOS, Windows e Linux, com uma versão base gratuita que mudou substancialmente a economia do mercado de edição. Adobe Premiere Pro é o terceiro grande jogador e domina grande parte da indústria do cinema e da TV. Nenhum destes é apropriado para o utilizador que quer remover os primeiros dez segundos de um clipe gravado por telemóvel antes de publicar no TikTok, que é exatamente a lacuna que um trimmer de navegador preenche.

Porque «sem upload» importa aqui especificamente

A propriedade mais importante de um trimmer de vídeo baseado em navegador é que o ficheiro não sai da máquina do utilizador. Os dados de vídeo são carregados de uma entrada File diretamente para a memória JavaScript, processados por WebAssembly dentro do processo do navegador, e o resultado é oferecido como download. Sem upload, sem terceiro que possa ler o ficheiro, sem fatura cloud que escale com o número de utilizadores, sem política de retenção de dados a escrever ou auditar. Para conteúdo sensível (reuniões gravadas, material pessoal, qualquer coisa que não pudesse ser carregada para um terceiro por razões legais ou contratuais) essa é a única arquitetura que faz sentido.

A desvantagem é que o utilizador paga o custo de computação. Um trimmer que corre numa quinta de servidores pode recodificar um clipe 4K em alguns segundos porque tem acesso a hardware de codificação GPU; a mesma operação em FFmpeg.wasm a correr em software num CPU de portátil pode levar um ou dois minutos. O caminho Fast (stream copy) contorna isto em grande parte ao evitar a codificação completamente, por isso é o padrão correto para quase todos os casos de uso de aparo casual. O caminho Precise (recodificação) é o padrão correto apenas quando o utilizador explicitamente precisa de precisão ao quadro ao custo de esperar.

Mais perguntas

Porque é que o meu aparo Fast começa mais cedo ou mais tarde do que pedi?

Porque o modo Fast (stream copy) só pode começar num keyframe (I-frame), e o keyframe mais próximo antes do seu início pedido pode estar até um GOP completo antes, entre 2 e 10 segundos dependendo de como a fonte foi codificada. Se precisa do corte num quadro específico, mude para o modo Precise, que recodifica e cai exatamente no quadro escolhido ao custo de uma espera mais longa e uma pequena geração de perda de compressão.

Porque é que o áudio está fora de sincronização depois do meu aparo Fast?

Geralmente porque o ponto de corte caiu dentro de um GOP de vídeo e o quadro de áudio nesse timestamp não se alinha com um keyframe de vídeo. O modo Fast desloca o início do vídeo para o keyframe mais próximo mas pode carregar os timestamps de áudio inalterados, produzindo um desfasamento. A correção padrão do FFmpeg é a bandeira -avoid_negative_ts make_zero, que rebaseia todos os timestamps para que o primeiro seja zero. Se a sincronização é crítica, o modo Precise reamostra o áudio para alinhar com o novo início e evita esta classe de problema.

Posso exportar para um formato diferente da entrada?

Para conversão de formato, a ferramenta Video Converter está construída para isso e expõe mais opções. O trimmer está otimizado para o caso mesmo-codec, mesmo-contentor (o modo Fast preserva inteiramente a codificação original) ou para recodificação para um pequeno conjunto de saídas amigáveis à web no modo Precise. Recodificação custa sempre tempo de CPU e uma geração de perda de qualidade; se só precisa de mudar o contentor sem recodificar a imagem, um equivalente ffmpeg -c copy é a ferramenta certa.

Porque é que a entrada AVI funciona mas a saída AVI não?

AVI antecede a maioria das funcionalidades modernas de codec (B-frames são desajeitados, sincronização de áudio é frágil acima de 4 GB, o formato de índice é limitado), e o instrumental moderno geralmente trata-o como formato de entrada legado apenas. As entradas em AVI lêem-se bem; as saídas por defeito são MP4 ou WebM, que são as famílias ISOBMFF/Matroska ativamente mantidas e reproduzem em cada navegador e leitor moderno.

Ferramentas relacionadas

Conversor de vídeo Criador de GIF Vídeo → texto Cortador de áudio