Rodar um vídeo 90° ou 180°: o indicador ou os píxeis

Duas operações que se parecem e nada têm a ver

Um ficheiro de vídeo pode ser rodado de duas maneiras. A primeira escreve uma pequena instrução no contentor — uma matriz de exibição, na família MP4 e QuickTime — que diz «mostra isto rodado 90 graus». Os píxeis não se mexem, a operação demora o tempo de reescrever umas dezenas de bytes, e é perfeitamente reversível. A segunda descodifica cada fotograma, desloca os píxeis e comprime-os de novo. Isso leva minutos em vez de milissegundos, custa uma geração de compressão com perdas, e não se desfaz.

O problema do indicador é que é apenas um conselho. Um leitor tem de ler o contentor, encontrar a matriz e aplicá-la, e nem todos o fazem. Os leitores web respeitam-no de forma desigual, alguns programas de edição importam os fotogramas em bruto e ignoram a instrução, certas caixas e televisores antigos nunca a aprenderam, e algumas ferramentas aplicam-na uma segunda vez por cima de um leitor que já o tinha feito — é assim que um clipe acaba de pernas para o ar. O indicador é instantâneo, sem perdas e por vezes desobedecido; a recodificação é lenta, com perdas e sempre obedecida. Não existe uma terceira via que seja as duas coisas.

Esta ferramenta escolheu a segunda via de propósito, e di-lo numa linha sob os seus controlos: a rotação é escrita na própria imagem, não num indicador que uns leitores ignoram e outros aplicam duas vezes, e é por isso que há recodificação. É uma descrição honesta do código. A tabela abaixo expõe o negócio por inteiro, para que decida se o quer antes de gastar os minutos.

O seu clipe de telemóvel deitado pode não precisar de ser rodado

É a razão mais frequente para chegar a uma ferramenta de rotação, e costuma ser o remédio errado. Um telemóvel grava com o seu sensor numa orientação fixa e escreve um indicador de rotação que descreve como o segurava. O ficheiro está portanto correto: os píxeis estão na horizontal, o indicador diz «quarto de volta», e qualquer aplicação que leia o indicador mostra o vídeo direito. Quando uma aplicação o mostra deitado, a culpada é essa aplicação, não o ficheiro.

A ferramenta não mostra o indicador existente, e essa é a sua funcionalidade em falta mais útil. Lê as dimensões do clipe a partir de um elemento de vídeo escondido na página, e os navegadores já reportam essas dimensões depois de aplicada a rotação — portanto um clipe vertical de telemóvel aparece como vertical, corretamente, sem nada que diga se é porque os píxeis são verticais ou porque um indicador o pediu. De dentro da ferramenta não consegue distinguir os dois. Faça a verificação fora: abra o clipe em dois leitores diferentes. Se um o mostra direito e o outro deitado, há um indicador, o ficheiro está bem, e recodificá-lo só lhe custará qualidade. Se todos o mostram deitado, os píxeis estão mesmo deitados e esta é a ferramenta certa.

Uma garantia se avançar na mesma. Esta versão do ffmpeg aplica o indicador de rotação existente antes do seu filtro, portanto a rotação que pede compõe-se com o indicador em vez de lutar contra ele: a saída é o que a pré-visualização mostrou, e depois já não leva indicador. Não vai obter um clipe rodado duas vezes. Terá simplesmente pago uma recodificação de que talvez não precisasse.

As caixas de espelho, a pré-visualização e o ficheiro

A ferramenta mostra uma pré-visualização em direto: o seu clipe a correr, rodado por CSS, para ver o enquadramento antes de confirmar. A ideia é boa e, durante um tempo, estava certa para todas as combinações menos quatro. A pré-visualização aplicava a transformação como rodar e depois escalar, e o CSS compõe isso da direita para a esquerda — o espelho vinha primeiro e a rotação depois. A cadeia de filtros faz o contrário: transpose primeiro, os espelhos acrescentados a seguir. Rodar e espelhar não comutam, portanto essas duas ordens não dão a mesma imagem, e um quarto de volta com exatamente uma caixa de espelho produzia um ficheiro a meia volta da pré-visualização. A pré-visualização escreve agora escalar e depois rodar, o que se compõe como rodar-e-depois-espelhar e coincide com a cadeia. O ficheiro foi sempre o correto; o que mentia era a imagem que dele se dava.

Passar as duas ordens pelo mesmo codificador resolve a questão. No mesmo clipe de teste, transpose=1,hflip e hflip,transpose=1 produziram dois fotogramas diferentes — número de bytes diferente, somas de verificação diferentes — enquanto correr duas vezes o mesmo comando deu uma saída idêntica byte a byte, portanto a diferença é real e não ruído do codificador. Marque os dois espelhos juntos e o desacordo desaparece: transpose=1,hflip,vflip e hflip,vflip,transpose=1 deram o mesmo fotograma, porque um par de espelhos é meia volta e meia volta comuta com tudo.

Na prática, as dezasseis combinações de botões coincidem agora com a pré-visualização, e o desvio em duas passagens que este artigo recomendava — rodar primeiro, descarregar e voltar a passar o ficheiro só com o espelho — deixou de ser preciso. Se encontrar alguma combinação em que o ficheiro não corresponda ao que viu, vale a pena assinalar: seria uma falha nova, não esta.

O que acontece ao som, e porque é que o ficheiro cresce

O som nunca é copiado tal e qual. Se o mantiver, é recodificado em AAC a 192 kbit/s, ou em Opus ao mesmo débito se a origem for WebM; se o retirar, os argumentos de áudio passam a -an, que elimina a faixa em vez de a silenciar. Recodificar um áudio que já era com perdas é uma segunda geração, e embora 192 kbit/s seja generoso o bastante para quase ninguém dar por isso, não é nada de desprezar. Se o som importa e a imagem não tem de ser perfeita, pondere extrair o áudio primeiro e voltar a pô-lo depois.

A imagem é codificada com libx264 na predefinição ultrafast e CRF 23. Ultrafast é a mais rápida das onze predefinições de velocidade e a menos eficiente: salta a maior parte da análise que permite gastar menos bits com a mesma qualidade, o que é o compromisso certo para uma única linha de execução do navegador e o errado para o tamanho do ficheiro. No clipe de teste, um ficheiro 1080x1920 de 6 segundos com 493 466 bytes voltou com 513 371 bytes depois de uma rotação de 90 graus. Nada foi acrescentado ao vídeo; simplesmente foram precisos mais bits para guardar pior a mesma imagem. Espere o mesmo perfil nos seus clipes: rodar não é um passo de compressão, e tratá-lo como tal vai desiludi-lo.

Perguntas frequentes

Um quarto de volta à esquerda é pior do que um à direita?

Não. São a mesma operação com um parâmetro diferente: transpose=1 no sentido dos ponteiros, transpose=2 no contrário. Ambas deslocam cada píxel exatamente uma vez, custam o mesmo tempo e provocam a mesma e única recodificação. O botão de 180 graus também não é pior, apesar de ser feito com dois espelhos em vez de duas rotações — correr hflip,vflip e transpose=1,transpose=1 sobre o mesmo fotograma deu uma saída idêntica byte a byte, portanto o atalho é exato além de rápido.

Porque é que o meu ficheiro rodado saiu maior do que o original?

Porque foi recodificado, e os ajustes do codificador privilegiam a velocidade sobre o tamanho. A ferramenta usa libx264 com a predefinição ultrafast, que faz muito pouca da análise que uma predefinição mais lenta usa para meter a mesma imagem em menos bits, com um alvo de qualidade constante de CRF 23. Se o original foi comprimido por um codificador paciente — o chip de um telemóvel, ou um editor a exportar a noite toda — então uma segunda passagem apressada com qualidade parecida precisa mesmo de mais espaço. Mediu-se um aumento de 4 % no clipe de teste; uma origem bem comprimida pode crescer mais. Nada correu mal; está a ver o custo de uma recodificação, que é o preço da via compatível com tudo.

O meu vídeo está direito no telemóvel e deitado no computador. Que faço?

Essa é a assinatura de um indicador de rotação respeitado por um programa e ignorado por outro, o que significa que o ficheiro não está estragado. Se o único programa que se engana é um que quase não usa, deixe o ficheiro em paz. Se tem de estar certo em todo o lado — porque o vai carregar, enviar a alguém ou importar num editor que ignora indicadores — então recodifique-o aqui, aceitando uma geração de perda em troca de um ficheiro sem nada para interpretar mal. Não recodifique um ficheiro que já está correto onde lhe importa.

A ferramenta pode rodar um clipe duas vezes por acidente?

Não para a rotação em si. A versão do ffmpeg por trás da ferramenta aplica qualquer indicador de rotação existente antes do seu filtro e não escreve nenhum na saída: um quarto de volta pedido num clipe com indicador dá um quarto de volta no total, não dois. A pré-visualização também coincide com o ficheiro: compunha a transformação CSS na ordem inversa à da cadeia de filtros, o que deixava um quarto de volta combinado com exatamente um espelho a meia volta do que tinha aprovado, e isso foi corrigido do lado da pré-visualização, não do lado da saída.

Posso rodar aqui sem recodificar?

Não. A ferramenta tem um só caminho e passa pelo codificador; não há modo de «só indicador» nem opção de cópia de fluxo. É uma escolha deliberada e não um descuido — uma rotação por indicador é a operação com mais probabilidades de produzir um ficheiro que parece arranjado na máquina onde o arranjou e está errado na máquina a que o envia, mau resultado para uma ferramenta cujos utilizadores em geral não podem verificar. Se quer especificamente a via dos metadados, precisa de uma ferramenta de linha de comandos ou de um editor de contentor. Se quer um ficheiro certo em todo o lado sem pensar nisso, é este.