Formatos de vídeo no WordPress: MOV, MP4 ou WebM (Adobe effects & web)

Um problema comum entre motion designers e editores de vídeo que começam a trabalhar com sites: “Fiz uma animação bonita no Adobe After Effects, renderizei em .mov (na melhor qualidade!), carreguei no WordPress e nada. Ecrã preto, erro, ou o ficheiro pesa 500 MB e demora uma eternidade a carregar.”

O ficheiro não está estragado. Foi feito para uma estação de edição, e um navegador não é uma estação de edição.

#Porque é que os ficheiros MOV não reproduzem no WordPress

O formato .mov (o contentor QuickTime) é o padrão no trabalho criativo, sobretudo em Mac. O .mov é um contentor, não um codec. O que o torna inutilizável na web é normalmente o que está lá dentro: ProRes ou fotogramas sem compressão.

Os tamanhos não são uma questão de opinião. A Apple publica-os. A 1920x1080 e 29,97 fps, o white paper do ProRes indica débitos alvo de 45 Mbps para 422 Proxy, 102 Mbps para 422 LT, 147 Mbps para 422, 220 Mbps para 422 HQ, 330 Mbps para 4444 e 495 Mbps para 4444 XQ. O apêndice do mesmo documento converte esses valores em gigabytes por hora: o 422 HQ dá 99 GB por hora, cerca de 1,65 GB por um único minuto de imagem. Um loop de hero de vinte segundos tirado diretamente do After Effects pode, portanto, ser maior do que todo o resto do site.

Depois, dentro do WordPress, correm mal duas coisas, por esta ordem.

O carregamento pode nem sequer terminar. A wp_max_upload_size() lê upload_max_filesize e post_max_size do PHP e devolve o menor dos dois. Em alojamento partilhado, estes valores ficam muitas vezes em predefinições modestas, e um POST de várias centenas de megabytes morre antes de a biblioteca de media chegar a vê-lo.

Se terminar, mesmo assim não reproduz. O WordPress aceita o ficheiro porque a wp_get_mime_types() contém 'mov|qt' => 'video/quicktime'. Mas a wp_get_video_extensions(), a função que decide o que o core considera uma fonte de vídeo reproduzível, devolve apenas mp4, m4v, webm, ogv e flv. O MOV não está nessa lista. Por isso, o anexo fica na biblioteca com aspeto de vídeo e comportamento de download.

Forçar o markup à mão também não resolve. O guia de contentores da MDN indica que o QuickTime só é suportado por versões antigas do Safari e por outros navegadores que suportavam o plugin QuickTime da Apple, marca todos os codecs da sua tabela QuickTime como não suportados no Firefox e refere que o framework QuickTime deixou de existir a partir do macOS 10.15 Catalina. O ProRes não aparece entre os codecs que o guia de codecs de vídeo da MDN documenta para navegadores.

#Porque é que o ProRes não serve para a web

O ProRes foi concebido para edição profissional, onde a prioridade é manter a qualidade máxima ao longo de várias rondas de correção de cor e recomposição. Cada fotograma é guardado com uma compressão ligeira, intra-frame, o que torna os ficheiros enormes, mas fáceis de percorrer e cortar em pós-produção.

A web tem outras prioridades. Os visitantes esperam que o vídeo comece em segundos. As ligações móveis têm largura de banda limitada. Os navegadores precisam de codecs pensados para uma descodificação eficiente, e a MDN di-lo no seu guia de codecs: nenhum codec sem perdas ou quase sem perdas está disponível de forma generalizada nos navegadores, porque um 1080p sem compressão com subamostragem 4:2:0 já exige pelo menos 1,5 Gbps.

#Exportar na qualidade máxima melhora o vídeo na web

Muitos designers assumem que mais qualidade significa melhor experiência. Um ficheiro master que demora minutos a chegar oferece uma experiência pior do que uma cópia comprimida que começa a reproduzir de imediato e que um espectador comum não consegue distinguir do master num ecrã de portátil.

#Que formato de vídeo o WordPress suporta

Dois formatos cobrem toda a web, e a escolha entre eles é menos dramática do que era quando este artigo foi escrito pela primeira vez.

#1. MP4 com H.264 (AVC)

A predefinição segura. O caniuse atribui ao H.264 em MP4 um suporte global de 97,26 por cento (dados verificados a 12 de outubro de 2026), recuando até ao Chrome 4 e ao Safari 3.2. Se publicar apenas um ficheiro, publique este.

Há duas definições que decidem se a exportação funciona de facto, e nenhuma delas se vê num leitor de pré-visualização.

Subamostragem de crominância. O ProRes 422 é, como o nome indica, 4:2:2, e a família 422 é de 10 bits. Entregue isso ao libx264 sem instruções e ele codifica um stream no perfil High 4:2:2, que os navegadores não descodificam. Verificámos isto com um ficheiro de teste ProRes 422 HQ: sem a opção de formato de píxel, o ffprobe reportou o resultado como High 4:2:2 com yuv422p10le. Force 8 bits 4:2:0 com -pix_fmt yuv420p.

Onde fica o índice. A documentação dos muxers do FFmpeg descreve o -movflags +faststart como uma opção que faz uma segunda passagem para mover o índice (o átomo moov) para o início do ficheiro, e indica que não está ativa por predefinição. Sem ela, o navegador não consegue iniciar a reprodução enquanto o ficheiro não tiver chegado por inteiro, que é exatamente o sintoma de “demora uma eternidade a carregar”.

Se exportar a partir do Adobe Media Encoder em vez da linha de comandos, escolha H.264 como formato, não QuickTime, e depois verifique as duas definições no resultado. A lista de formatos é a única coisa que importa; os nomes das predefinições mudam de versão para versão.

#Definições de exportação H.264 recomendadas

Para resultados previsíveis ao exportar para o WordPress:

• Resolução: 1920x1080 para vídeo de conteúdo, 1280x720 para clips secundários.
• Qualidade: CRF entre 23 e 28 no libx264, em vez de perseguir um débito fixo.
• Taxa de fotogramas: mantenha a taxa da fonte (normalmente 24, 25 ou 30 fps).
• Áudio: AAC a 128 a 192 kbps estéreo, ou nenhuma faixa de áudio se o clip for decorativo.
• Formato de píxel: yuv420p, verificado com ffprobe no ficheiro exportado.
• Perfil e nível: fixe-os com -profile:v high -level:v 4.0 para 1080p, para que o ficheiro corresponda à string codecs que declara no markup (mais sobre isso abaixo).

#2. WebM com VP9

Um formato aberto desenvolvido pela Google. A página do VP9 da Google afirma que o codec consegue reduzir o débito de vídeo em até 50% face a outros codecs conhecidos. Trate esse valor como um teto atingido em conteúdo difícil, não como um número que vai obter em todos os clips, mas a poupança num motion graphic plano é real.

O conselho desatualizado sobre este tema diz que o WebM é um formato do Chrome e do Firefox. Já não o é há anos. O caniuse regista suporte total de WebM no Safari para macOS a partir da versão 16 e no Safari para iOS a partir da 17.4, sendo que o Safari 14.1 a 15.6 já o reproduzia no macOS 11.3 Big Sur ou posterior. Isso coloca o suporte total em 96,05 por cento a nível global, pouco mais de um ponto atrás do H.264 em MP4.

#Suporte do codec AV1 nos navegadores

O AV1 está uma geração à frente e comprime melhor do que o VP9, mas a sua adoção está atrasada. O caniuse atribui-lhe 80,39 por cento de suporte total, subindo para 95,02 por cento só se contar o suporte parcial. O Safari é o caso parcial: no macOS e no iOS só descodifica AV1 em dispositivos com descodificador por hardware, como o iPhone 15 Pro ou um MacBook Pro com M3.

O guia de codecs de vídeo da MDN recomenda agora WebM com AV1 e Opus como primeira escolha para um site típico, e MP4 com AVC e AAC como segunda opção de compatibilidade alargada. Isso faz do AV1 um primeiro <source>, nunca o único. A codificação AV1 é também muito mais lenta do que a H.264 ou a VP9, por isso compensa em conteúdo que é codificado uma vez e reproduzido muitas vezes.

#Tag video HTML5 com fontes WebM e MP4

Se tiver de alojar o vídeo no seu servidor, por exemplo como fundo de hero, liste as fontes da melhor para a pior. O navegador usa a primeira que consegue descodificar e nunca olha para as restantes.

<video autoplay loop muted playsinline preload="none"
       poster="/media/hero-poster.avif"
       width="1920" height="1080">
  <source src="/media/hero.webm" type='video/webm; codecs="vp9, opus"'>
  <source src="/media/hero.mp4" type='video/mp4; codecs="avc1.640028, mp4a.40.2"'>
  O seu navegador não suporta vídeo.
</video>

Cada atributo tem uma função específica:

• muted mais playsinline: os navegadores móveis recusam a reprodução automática sem ambos. Sem playsinline, o iOS passa o vídeo para ecrã inteiro no momento em que começa, o que destrói um loop de fundo.
• preload="none": nada é transferido até a reprodução ser pedida, por isso o poster assegura a primeira pintura. Use metadata se precisar da duração logo à partida, e auto quase nunca.
• poster: uma imagem estática em AVIF ou WebP pesa uma fração do vídeo e é o que o visitante vê de facto nos primeiros segundos.
• a parte codecs= da string type: permite ao navegador rejeitar uma fonte sem transferir um único byte dela.
• width e height: defina-os sempre para que o espaço fique reservado antes de o vídeo carregar, o que evita o Cumulative Layout Shift, uma das Core Web Vitals.

#Como escrever a string codecs para MP4 e WebM

Versões anteriores deste artigo declaravam avc1.42E01E para a fonte MP4. Essa string declara o perfil Baseline (42) no nível 3.0, enquanto o comando FFmpeg mais abaixo produz um ficheiro no perfil High. Uma string codecs que descreve um stream diferente daquele que publica é uma afirmação errada feita ao navegador.

O guia da MDN sobre o parâmetro codecs define a forma AVC como avc1.PPCCLL: dois dígitos hexadecimais para o perfil, dois para as flags de restrição e dois para o nível. O perfil High é 64 com restrições 00, e o nível 4.0 é 40 em decimal, 28 em hexadecimal. Assim, High no nível 4.0 é avc1.640028. O áudio AAC-LC em MP4 é mp4a.40.2. Para WebM, a MDN indica as formas curtas vp9, vp8, opus e vorbis.

Leia os valores reais do ficheiro exportado em vez de os adivinhar:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=profile,level,pix_fmt -of csv=p=0 web.mp4

No nosso teste, uma codificação 1080p com -preset slow e sem opção de nível devolveu High,50, nível 5.0, porque a predefinição slow usa mais fotogramas de referência do que o nível 4.0 permite nessa resolução. Com -profile:v high -level:v 4.0 devolveu High,40, que é o que avc1.640028 declara.

#Atributos do bloco Vídeo no editor de blocos

No editor de blocos não tem de escrever a tag à mão. O block.json do bloco Vídeo do core inclui autoplay, controls, loop, muted, playsInline, poster, preload, src e tracks como atributos, com preload predefinido como metadata, e o playsInline tem o seu próprio interruptor na barra lateral. O bloco Capa não tem esse atributo: o seu block.json não declara nenhuma chave playsInline, e o seu output de gravação fixa autoPlay, muted, loop e playsInline no vídeo de fundo, por isso um loop de vídeo num bloco Capa é sempre inline e não há interruptor para verificar. Nenhum dos blocos escreve um parâmetro codecs no markup.

#Como o shortcode video escolhe as fontes

O conteúdo clássico e muitos page builders continuam a passar pelo shortcode [video], que o core renderiza com wp_video_shortcode(). O código-fonte dessa função, em wp-includes/media.php, explica várias coisas que as pessoas reportam como bugs.

• Um MOV transforma-se num link. Quando src aponta para um ficheiro cuja extensão não está em wp_get_video_extensions(), a função devolve um simples link <a class="wp-embedded-video"> para o ficheiro em vez de um leitor.
• A ordem das fontes é fixa. Pode passar um atributo por extensão (mp4, m4v, webm, ogv, flv), e a função emite os elementos <source> pela ordem dessa lista. [video webm="a.webm" mp4="a.mp4"] coloca, portanto, o MP4 em primeiro lugar, e todos os navegadores que descodificam H.264 escolhem-no.
• O type não leva codecs. Cada <source> recebe um tipo MIME simples a partir de wp_check_filetype(), como video/mp4.
• Predefinições. preload é metadata, muted é false e o leitor tem 640x360, a menos que passe width e height; uma largura maior é reduzida ao $content_width do tema.
• Biblioteca do leitor. Por predefinição, o output é envolvido para o MediaElement.js; o filtro wp_video_shortcode_library altera isso.

Adicionar mov através do filtro wp_video_extensions faz com que o shortcode renderize um leitor para ele, mas não dá ao Chrome nem ao Firefox um descodificador, por isso a solução continua a ser recodificar.

#Tipos MIME do servidor para MP4 e WebM

Um ficheiro pode estar perfeitamente codificado e mesmo assim ser servido com o Content-Type errado. Verifique o cabeçalho da resposta no separador Rede do navegador. O ficheiro mime.types predefinido do nginx já associa mp4 a video/mp4, webm a video/webm e mov a video/quicktime. No Apache, se o cabeçalho vier como text/plain ou application/octet-stream, adicione a associação no .htaccess:

AddType video/mp4 .mp4
AddType video/webm .webm

#Otimização do tamanho dos ficheiros de vídeo

O tamanho do ficheiro conta para a experiência do utilizador e para o SEO. Um vídeo que demora demasiado a carregar aumenta a taxa de rejeição e prejudica as Core Web Vitals.

Não existe uma tabela universal de tamanhos alvo: o mesmo segundo de imagem pesa de forma muito diferente num plano estático e numa panorâmica com grão. Fixe a qualidade com CRF, meça o ficheiro resultante e decida com base nesse número.

#Ferramentas gratuitas de compressão

1. HandBrake: gratuito e open source. A sua lista de funcionalidades indica AV1, H.265, H.264, MPEG-4, MPEG-2, VP8 e VP9 como codificadores de vídeo, com MP4, MKV e WebM como contentores.
2. FFmpeg: a ferramenta de linha de comandos por trás da maioria das outras, e a usada em todos os exemplos deste artigo.
3. Shutter Encoder: uma interface gráfica sobre o FFmpeg, mais fácil para começar.

#Como comprimir vídeo com FFmpeg

# MOV para MP4 web (H.264, perfil High, nível 4.0)
ffmpeg -i input.mov -c:v libx264 -preset slow -crf 23 \
  -profile:v high -level:v 4.0 -pix_fmt yuv420p \
  -c:a aac -b:a 128k -movflags +faststart output.mp4

# MOV para WebM com VP9 e Opus
ffmpeg -i input.mov -c:v libvpx-vp9 -crf 33 -b:v 0 -row-mt 1 \
  -pix_fmt yuv420p -c:a libopus -b:a 96k output.webm

# Versão 720p para dispositivos móveis
ffmpeg -i input.mov -vf scale=1280:720 -c:v libx264 -preset slow -crf 23 \
  -pix_fmt yuv420p -movflags +faststart output-mobile.mp4

O valor -crf controla a qualidade: valores mais baixos significam mais qualidade e um ficheiro maior. Para a web, um CRF de 23 a 28 para H.264 ou de 30 a 35 para VP9 é um intervalo sensato a partir do qual começar a medir.

Verifique a exportação em vez de assumir, porque a falta de +faststart não dá qualquer aviso:

grep -abo -m2 -e moov -e mdat output.mp4

Isto mostra o offset em bytes do primeiro moov e do primeiro mdat. O offset do moov deve ser o menor. No nosso ficheiro de teste sem a opção, o mdat vinha primeiro, no byte 44, e o moov ficava no fim do ficheiro; com a opção, o moov estava no byte 36.

#Como publicar vídeo com transparência (canal alfa)

O VP9 em WebM transporta um canal alfa se codificar para yuva420p. O guia de codecs da MDN indica o VP9 em todas as versões atuais do Chrome, Edge, Firefox, Opera e Safari, com a nota de que o Safari não suporta transparência alfa nesse codec; o caniuse tem a mesma nota para WebM no Safari. O caminho da Apple é HEVC com alfa, que documenta no seu HEVC Video with Alpha Interoperability Profile. Se uma composição do After Effects precisar de um canal alfa real na web, vai publicar dois ficheiros e uma alternativa em cor sólida.

#Vídeo alojado no próprio servidor ou YouTube e Vimeo

Alojar o vídeo no seu servidor dá-lhe um ficheiro, com um débito, entregue por download HTTP progressivo. Não há uma escada adaptativa. O WordPress gera versões redimensionadas das imagens no momento do carregamento e não faz nada equivalente para vídeo, porque o core não inclui nenhum transcodificador. Um visitante com uma ligação móvel fraca recebe o seu ficheiro 1080p ou não recebe nada, e fica parado enquanto o buffer enche.

Por isso, a regra tem a ver com o que o vídeo é, não com o seu tamanho.

#Quando alojar vídeo no seu próprio servidor

• Vídeo de fundo: animações curtas e sem som por trás do título de um hero.
• Vídeo privado: conteúdo que não pode estar numa plataforma pública.
• Requisitos de marca: quando o leitor tem de ser totalmente seu, sem logótipos de terceiros.
• Peso da página: em clips muito curtos, um embed do YouTube arrasta consigo um leitor de terceiros e os respetivos cookies para algo mais próximo de uma imagem de fundo em movimento.

#Quando usar YouTube ou Vimeo

• Qualquer vídeo com som com mais de cerca de 30 segundos que o visitante veio ver: uma entrevista, um tutorial, a apresentação de um caso de estudo.
• Conteúdo educativo ou de marketing que beneficia da pesquisa do YouTube.
• Vídeo que quer ver partilhado nas redes sociais.
• Sites com largura de banda limitada, onde o streaming adaptativo faz diferença.

A largura de banda é a outra metade desta decisão. Um loop de 10 MB numa página com cinquenta mil visualizações por mês dá meio terabyte de tráfego de saída, e num alojamento de entrada isso obriga a uma conversa com o seu fornecedor.

#Como o Google indexa vídeo alojado no próprio servidor

As boas práticas de SEO para vídeo da Google acrescentam um terceiro ângulo à questão do formato, e esse ângulo não coincide com o dos navegadores.

O Google consegue processar MOV, os navegadores não o conseguem reproduzir. A lista de tipos de ficheiro de vídeo suportados pela Google inclui MOV, MP4, M4V, WebM, OGV e outros. Isso torna um MOV indexável em princípio e, ainda assim, inútil para o visitante, por isso não é argumento para o publicar.

Só uma página de visualização recebe o conjunto completo de funcionalidades de vídeo. A Google define página de visualização como aquela cujo objetivo principal é mostrar um único vídeo. Um artigo de blog que analisa um vídeo incorporado, ou uma página de produto com um vídeo 360, não é explicitamente uma página de visualização; essas páginas podem mesmo assim aparecer como resultados de texto e no Google Imagens com um selo de vídeo. Um loop de hero decorativo nunca será um resultado de vídeo, e não precisa de ser.

O poster serve também de miniatura. Se usar o elemento <video>, o Google lê o atributo poster como a miniatura preferida. Os formatos de miniatura suportados são BMP, GIF, JPEG, PNG, WebP, SVG e AVIF, com pelo menos 60x30 píxeis, num URL estável que o Googlebot tenha permissão para obter.

Não esconda o vídeo atrás de uma interação. A Google pede que os vídeos não dependam de deslizar, clicar ou escrever para carregar, e que um vídeo injetado por JavaScript apareça no HTML renderizado mostrado pela ferramenta de Inspeção de URL. Isso conta para o padrão de carregamento diferido descrito abaixo: aceitável para um loop decorativo, arriscado para um vídeo que quer ver indexado.

Dados estruturados. A documentação de VideoObject indica três propriedades obrigatórias: name, thumbnailUrl e uploadDate (ISO 8601, com fuso horário). O contentUrl deve apontar para o próprio ficheiro de vídeo e é o preferido; o embedUrl aponta para um leitor e é a alternativa quando o URL do ficheiro não está disponível. Para um MP4 alojado no próprio servidor, o contentUrl é simplesmente o URL do ficheiro em wp-content/uploads.

#Como tornar o vídeo responsivo no WordPress

O WordPress não adapta sozinho o vídeo alojado no próprio servidor aos tamanhos de ecrã, por isso essa parte tem de ser escrita por si.

#CSS para vídeo responsivo

/* Contentor responsivo para vídeo */
.video-container {
    position: relative;
    width: 100%;
    padding-bottom: 56.25%; /* proporção 16:9 */
    height: 0;
    overflow: hidden;
}

.video-container video,
.video-container iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

#Servir resoluções diferentes consoante o dispositivo

<video autoplay loop muted playsinline>
  <!-- Móvel: 720p -->
  <source
    src="video-720p.webm"
    type="video/webm"
    media="(max-width: 768px)"
  >
  <!-- Desktop: 1080p -->
  <source src="video-1080p.webm" type="video/webm">
  <source src="video-1080p.mp4" type="video/mp4">
</video>

O atributo media num <source> de vídeo é uma funcionalidade antiga com uma lacuna a meio: segundo os dados de compatibilidade da MDN, o Firefox 53 a 119 só o respeitava dentro de <picture>, e o suporte para <audio> e <video> regressou no Firefox 120.

#Como tornar o vídeo acessível no WordPress

O vídeo acessível é obrigatório para o setor público europeu ao abrigo da Diretiva de Acessibilidade da Web e, fora dele, torna simplesmente o conteúdo compreensível para mais pessoas. Os critérios de sucesso relevantes das WCAG 2.2 são curtos e concretos:

• 1.2.2 Legendas (pré-gravadas), nível A: legendas para todo o áudio pré-gravado em media sincronizada.
• 1.2.5 Audiodescrição (pré-gravada), nível AA: uma audiodescrição para conteúdo de vídeo pré-gravado.
• 1.4.2 Controlo de áudio, nível A: qualquer áudio que toque automaticamente durante mais de 3 segundos precisa de uma forma de o pausar ou parar, ou de um controlo de volume independente do volume do sistema.
• 2.2.2 Pausar, parar, ocultar, nível A: conteúdo em movimento que começa automaticamente, dura mais de cinco segundos e é apresentado ao lado de outro conteúdo precisa de uma forma de o pausar, parar ou ocultar.

É este último que os loops de hero violam. Um vídeo de fundo sem som, com loop e sem controlos, corre para sempre, por isso precisa de um botão de pausa visível ou deve parar ao fim de alguns segundos.

#Como adicionar legendas com o elemento track

As legendas num vídeo alojado no próprio servidor são um ficheiro WebVTT referenciado por um elemento <track>. O caniuse coloca o suporte de WebVTT em 97,26 por cento, o mesmo que o próprio elemento <video>.

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track kind="captions" src="captions.vtt" srclang="pt" label="Português" default>
  <track kind="descriptions" src="descriptions.vtt" srclang="pt" label="Audiodescrição">
</video>

Um ficheiro WebVTT mínimo tem este aspeto:

WEBVTT

00:00:00.000 --> 00:00:04.000
Bem-vindo a este vídeo.

00:00:04.000 --> 00:00:08.000
[Música suave em fundo]

O bloco Vídeo do core guarda o mesmo no seu atributo tracks, por isso as legendas adicionadas no editor acabam como elementos <track> no markup guardado.

#Lista mínima de acessibilidade para vídeo

1. Legendas fechadas: para utilizadores surdos ou com deficiência auditiva, como ficheiro WebVTT num elemento <track>.
2. Audiodescrição: para utilizadores cegos, descrevendo o que só é visível.
3. Controlos por teclado: o leitor tem de ser utilizável sem rato.
4. Alternativa em texto: o poster ou a miniatura precisa de uma descrição com significado quando transmite informação.
5. Sem reprodução automática com som: um vídeo com som nunca deve começar sozinho.

#Como diferir o carregamento de um vídeo alojado no próprio servidor

O tratamento de loading="lazy" do core do WordPress aplica-se a imagens e iframes, não ao elemento <video>, que não suporta esse atributo. Para um vídeo alojado no próprio servidor, o que adia a transferência é preload="none" em conjunto com um poster. Se precisar de mais, carregue a fonte a partir de JavaScript com um IntersectionObserver quando o elemento entra no viewport, tendo em conta a nota da Google acima para qualquer vídeo que queira ver indexado.

#Como converter MOV para MP4 para o WordPress

1. Edite e faça o master no After Effects ou no Premiere com .mov e ProRes. Essa parte nunca esteve errada.
2. Exporte para a web como H.264 em MP4, forçando -pix_fmt yuv420p, -movflags +faststart e um perfil e nível que depois declara em codecs.
3. Confirme a exportação: moov num offset em bytes inferior ao de mdat, e ffprobe a reportar yuv420p e High,40, não yuv422p10le.
4. Acrescente uma cópia WebM com VP9 e liste-a antes do MP4 no elemento <video>. Acrescente AV1 acima de ambos se estiver a tentar poupar as últimas centenas de kilobytes.
5. Dê ao elemento uma imagem de poster e preload="none", mantenha muted e playsinline em qualquer loop com reprodução automática e acrescente um controlo de pausa se ele durar mais de cinco segundos.
6. Defina sempre width e height para evitar mudanças de layout.
7. Se o clip tem som e é suposto alguém sentar-se a vê-lo, coloque-o no YouTube ou no Vimeo e incorpore-o.

Se isto fizer parte de um projeto que mantemos, configuramos o passo de codificação uma única vez no pipeline de deploy, para que ninguém tenha de se lembrar das opções. Isso faz parte dos nossos serviços de desenvolvimento WordPress.