Reprodução de vídeo na Web: práticas recomendadas de entrega de vídeo (parte 2)

Em meu post anterior, examinei as tendências de vídeo na web hoje, usando dados do HTTP Archive. Descobri que muitos sites veiculam o mesmo conteúdo de vídeo em dispositivos móveis e desktops e que muitos fluxos de vídeo estão sendo entregues com taxas de bits muito altas para serem reproduzidas em conexões de velocidade 3G. Também descobrimos que os sites podem baixar vídeos automaticamente para dispositivos móveis – prejudicando os planos de dados do cliente, a duração da bateria, para vídeos que podem nunca ser reproduzidos.

TL;DR : Neste post, analisamos técnicas para otimizar a velocidade e a entrega de vídeo para seus clientes e fornecemos uma lista de 9 práticas recomendadas para ajudá-lo a entregar seus recursos de vídeo.

Métricas de reprodução de vídeo

Existem 3 principais métricas de reprodução de vídeo em uso hoje:

1. Tempo de inicialização do vídeo
2. Paralisação de vídeo
3. Qualidade de vídeo

Como os arquivos de vídeo são grandes, otimizar o vídeo para ser o menor possível levará a uma entrega de vídeo mais rápida, acelerando o início do vídeo, diminuindo o número de paradas e minimizando o efeito da qualidade do vídeo entregue. É claro que precisamos equilibrar a velocidade de inicialização e a paralisação com a terceira métrica de qualidade (e vídeos de maior qualidade geralmente usam mais dados).

Inicialização de vídeo

Quando um usuário pressiona o play em um vídeo, ele espera poder assistir ao vídeo rapidamente. De acordo com a Conviva (líder em análise de métricas de vídeo), no primeiro trimestre de 2018, 14% dos vídeos nunca começaram a ser reproduzidos (ou seja, 2,4 bilhões de reproduções de vídeo) depois que o usuário pressionou o play.

2,3% dos vídeos (solicitações de vídeo de 400 milhões) não foram reproduzidos depois que o usuário pressionou o botão de reprodução. 11,54% (jogos 2B) foram abandonados pelo usuário após pressionar play. Vamos tentar detalhar o que pode estar causando esses problemas.

Falha na reprodução de vídeo

A falha na reprodução de vídeo foi responsável por 2,3% de todas as reproduções de vídeo. O que poderia levar a isso? Nos dados do HTTP Archive, vemos 0,3% de todas as solicitações de vídeo resultando em uma resposta HTTP 4xx ou 5xx — portanto, alguma porcentagem falha devido a URLs inválidos ou configurações incorretas do servidor. Outro problema potencial (que não é observado nos dados do HTTP Archive) são os vídeos bloqueados por geolocalização (bloqueados com base na localização do visualizador e no licenciamento do provedor para exibir o vídeo nessa localidade).

Abandono de reprodução de vídeo

O relatório da Conviva afirma que 11,5% de todas as reproduções de vídeo seriam reproduzidas, mas que o cliente abandonou a reprodução antes que o vídeo começasse a ser reproduzido. O problema aqui é que o vídeo não está sendo entregue ao cliente com rapidez suficiente e ele desiste. Existem muitos estudos na web móvel onde longos atrasos causam abandono de páginas da web, e parece que o mesmo efeito ocorre com a reprodução de vídeo.

Pesquisas da Akamai mostram que os espectadores esperam 2 segundos, mas para cada segundo subsequente, 5,8% dos espectadores abandonam o vídeo.

Então, o que leva a problemas de reprodução de vídeo? Em geral, arquivos maiores demoram mais para serem baixados, por isso atrasam a reprodução. Vejamos algumas maneiras de acelerar a reprodução de vídeos. Para reduzir o número de vídeos abandonados na inicialização, devemos 'reduzir' esses arquivos da melhor forma possível, para que eles sejam baixados (e comecem a reprodução) rapidamente.

MP4: Pré-carregamento de vídeo

Para garantir uma reprodução rápida na web, uma opção é pré-carregar o vídeo no dispositivo com antecedência. Dessa forma, quando seu cliente clicar em 'reproduzir' o vídeo já está baixado, e a reprodução será rápida. HTML oferece um atributo de pré-carregamento com 3 opções possíveis: auto , metadata e none .

preload = auto

Quando seu vídeo é entregue com preload="auto" , o navegador baixa o arquivo de vídeo inteiro e o armazena localmente. Isso permite uma grande melhoria no desempenho da inicialização do vídeo, pois o vídeo está disponível localmente no dispositivo e nenhuma interferência na rede retardará a inicialização.

No entanto, preload="auto" só deve ser usado se houver uma alta probabilidade de que o vídeo seja visualizado. Se o vídeo estiver simplesmente residente em sua página da Web e for baixado a cada vez, isso adicionará uma grande penalidade de dados para seus usuários móveis, além de aumentar seus custos de servidor/CDN para entregar o vídeo inteiro a todos os seus usuários.

Este site possui uma seção intitulada “Galeria de Vídeos” com vários vídeos. Cada vídeo nesta seção tem pré-carregamento definido como auto , e podemos visualizar seu download na cascata WebPageTest como linhas horizontais verdes:

Existe uma seção chamada “Galeria de Vídeos”, e os arquivos dessa pequena seção do site representam 14,6M (83%) do download da página. As chances de um (de muitos) vídeos serem reproduzidos são provavelmente muito baixas e, portanto, utilizar preload="auto" apenas gera muito tráfego de dados para o site.

Nesse caso, é improvável que um desses vídeos seja visualizado, mas todos são baixados completamente, adicionando 14,8 MB de conteúdo ao site móvel (83% do conteúdo da página). Para vídeos com alta probabilidade de reprodução (talvez >90% das visualizações de página resultem em reprodução de vídeo) — pré-carregar o vídeo inteiro é uma boa ideia. Mas para vídeos que provavelmente não serão reproduzidos, preload="auto" só causará uma quantidade extra de conteúdo por meio de seus servidores e dispositivos móveis (e desktop) de seu cliente.

preload="metadata"

Quando o atributo preload="metadata" é usado, um segmento inicial do vídeo é baixado. Isso permite que o player saiba o tamanho da janela de vídeo e talvez tenha um ou dois segundos de vídeo baixado para reprodução imediata. O navegador simplesmente faz um 206 (pedido parcial) do conteúdo do vídeo. Ao armazenar um pequeno pedaço de dados de vídeo no dispositivo, o tempo de inicialização do vídeo é reduzido, sem um grande impacto na quantidade de dados transferidos.

No Chrome, os metadados são a opção padrão se nenhum atributo for escolhido.

Nota : Isso ainda pode levar a uma grande quantidade de vídeo a ser baixada, se o vídeo for grande.

Por exemplo, em um site para celular com um vídeo definido em preload="metadata" , vemos apenas uma solicitação de vídeo:

E a solicitação é um download parcial, mas ainda resulta em 2,7 MB de vídeo a ser baixado porque o vídeo completo é 1080p, 150s de comprimento e 97 MB (falaremos sobre a otimização do tamanho do vídeo nas próximas seções).

Portanto, recomendo que preload="metadata" ainda seja usado apenas quando houver uma probabilidade bastante alta de que o vídeo seja visualizado por seus usuários ou se o vídeo for pequeno.

preload="none"

A opção de download mais econômica para vídeos, pois nenhum arquivo de vídeo é baixado quando a página é carregada. Isso pode causar um atraso na reprodução, mas resultará em um carregamento de página inicial mais rápido Para sites com muitos vídeos em uma única página, pode fazer sentido adicionar um pôster à janela do vídeo e não baixar nenhum vídeo até que seja expressamente solicitado pelo usuário final. Todos os vídeos do YouTube incorporados em sites nunca baixam nenhum conteúdo de vídeo até que o botão de reprodução seja pressionado, basicamente se comportando como se preload="none" .

Prática recomendada de pré-carregamento : use apenas preload="auto" se houver uma alta probabilidade de que o vídeo seja assistido. Em geral, o uso de preload="metadata" fornece um bom equilíbrio no uso de dados versus tempo de inicialização, mas deve ser monitorado quanto ao uso excessivo de dados.

Dicas de reprodução de vídeo MP4

Agora que o vídeo foi iniciado, como podemos garantir que a reprodução do vídeo possa ser otimizada para não travar e continuar reproduzindo. Novamente, o truque é garantir que o vídeo seja o menor possível.

Vejamos alguns truques para otimizar o tamanho dos downloads de vídeo. Existem várias dimensões de vídeo que podem ser otimizadas para reduzir o tamanho do vídeo:

Áudio

Os arquivos de vídeo são divididos em diferentes “streams” – o mais comum é o stream de vídeo. O segundo fluxo mais comum é a faixa de áudio que sincroniza com o vídeo. Em alguns aplicativos de reprodução de vídeo, o fluxo de áudio é fornecido separadamente; isso permite que diferentes idiomas sejam entregues de maneira perfeita.

Se o seu vídeo for reproduzido de forma silenciosa (como um GIF em loop ou um vídeo em segundo plano), remover o fluxo de áudio do vídeo é uma maneira rápida e fácil de reduzir o tamanho do arquivo. Em um exemplo de vídeo de fundo, o arquivo completo tinha 5,3 MB, mas a faixa de áudio (que nunca é ouvida) tinha quase 300 KB (5% do arquivo) Com a simples eliminação do áudio, o arquivo será entregue rapidamente sem desperdício bytes.

42% dos arquivos MP4 encontrados no HTTP Archive não possuem fluxo de áudio.

Prática recomendada : remova as faixas de áudio dos vídeos reproduzidos silenciosamente.

Codificação de vídeo

Ao codificar um vídeo, existem opções para reduzir a qualidade do vídeo (número de pixels por quadro ou quadros por segundo). Reduzir um vídeo de alta qualidade para torná-lo adequado para a web é fácil de fazer e geralmente não afeta a qualidade entregue aos usuários finais. Este artigo não é longo o suficiente para uma discussão aprofundada de todas as várias técnicas de compressão disponíveis para vídeo. Nos codificadores x264 e x265 , existe um termo chamado ator C onstant R ate F (CRF). O uso de um CRF de 23-28 geralmente oferece uma boa compensação de compactação/qualidade e é um ótimo começo no domínio da compactação de vídeo

Tamanho do vídeo

O tamanho do vídeo pode ser afetado por muitas dimensões: comprimento, largura e altura (você provavelmente também pode incluir áudio aqui).

Duração do vídeo

A duração do vídeo geralmente não é um recurso que um desenvolvedor da Web pode ajustar. Se o vídeo for reproduzido por três minutos, ele será reproduzido por três minutos. Nos casos em que o vídeo é excepcionalmente longo, ferramentas como preload="none" ou streaming do vídeo podem permitir que uma quantidade menor de dados seja baixada inicialmente para reduzir o tempo de carregamento da página.

Dimensões do vídeo

18% de todos os vídeos encontrados no HTTP Archive são idênticos em dispositivos móveis e computadores. Quem já trabalhou com web design responsivo sabe como otimizar imagens para diferentes viewports pode reduzir drasticamente o tempo de carregamento, já que o tamanho das imagens é muito menor para telas menores.

O mesmo vale para o vídeo. Um site com um vídeo de fundo de 30 MB 2560×1226 terá dificuldade em baixar o vídeo no celular (provavelmente no desktop também!). O redimensionamento do vídeo diminui drasticamente o tamanho dos arquivos e pode até permitir que três ou quatro vídeos de fundo diferentes sejam exibidos:

Agora, infelizmente, os navegadores não suportam consultas de mídia para vídeo em HTML, o que significa que isso simplesmente não funciona:

 <video preload="auto" autoplay muted controls source src="large.mp4" </video>

Portanto, precisaremos criar um pequeno wrapper JS para entregar os vídeos que queremos em diferentes tamanhos de tela. Mas antes de irmos para lá…

Baixando o vídeo, mas ocultando-o da visualização

Outro retrocesso para a web responsiva inicial é baixar imagens em tamanho real, mas escondê-las em dispositivos móveis. Seus clientes recebem todo o atraso para baixar as imagens grandes (e acessar o plano de dados móveis e o consumo extra de bateria etc.) e nenhum benefício de realmente ver a imagem. Isso ocorre com bastante frequência com vídeo no celular. Assim, enquanto escrevemos nosso roteiro, podemos garantir que telas menores nunca solicitem o vídeo que não aparecerá em primeiro lugar.

Vídeos com qualidade de retina

Você pode ter vídeos diferentes para diferentes densidades de tela do dispositivo. Isso pode levar a mais tempo para baixar os vídeos para seus clientes móveis. Você pode querer evitar que vídeos retina em dispositivos de tela menor ou em dispositivos com largura de banda de rede limitada, voltem a vídeos de qualidade padrão para esses dispositivos. Ferramentas como a API de informações de rede podem fornecer a taxa de transferência da rede e ajudá-lo a decidir qual qualidade de vídeo você gostaria de oferecer ao seu cliente.

Download de diferentes tipos de vídeo com base no tamanho do dispositivo e na qualidade da rede

Acabamos de abordar algumas maneiras de otimizar a exibição de filmes em telas menores e também observamos a incapacidade da tag de vídeo de escolher entre os tipos de vídeo, então aqui está um snippet JS rápido que usará a largura da tela para:

• Não entregar vídeo em telas abaixo de 500px;
• Entregue pequenos vídeos para telas 500-1400;
• Entregue um vídeo de tamanho maior para todos os outros dispositivos.

 <html><body> <div> </div> <div></div> <script> //get screen width and pixel ratio var width = screen.width; var dpr = window.devicePixelRatio; //initialise 2 videos — //“small” is 960 pixels wide (2.6 MB), large is 1920 pixels wide (10 MB) var smallVideo="https://res.cloudinary.com/dougsillars/video/upload/w_960/v1534228645/30s4kbbb_oblsgc.mp4"; var bigVideo = "https://res.cloudinary.com/dougsillars/video/upload/w_1920/v1534228645/30s4kbbb_oblsgc.mp4"; //TODO add logic on adding retina videos if (width<500){ console.log("this is a very small screen, no video will be requested"); } else if (width< 1400){ console.log("let's call this mobile sized"); var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +smallVideo +"\"/\>"; console.log(videoTag); document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a small video."; } else{ var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +bigVideo +"\"/\>"; document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a big video."; } </script> </html></body>

Este script divide as telas do usuário em três opções:

1. Abaixo de 500 pixels, nenhum vídeo é exibido.
2. Entre 500 e 1400, temos um vídeo menor.
3. Para telas maiores que 1400 pixels, temos um vídeo maior.

Nossa página possui um vídeo responsivo com dois tamanhos diferentes: um para celular e outro para telas do tamanho de desktop. Os usuários móveis obtêm uma ótima qualidade de vídeo, mas o arquivo tem apenas 2,6 MB, em comparação com o vídeo de 10 MB para desktop.

GIFs animados

GIFs animados são arquivos grandes. Embora os aGIFs e os arquivos de vídeo comprimam os dados por meio das dimensões de largura e altura, apenas os arquivos de vídeo têm eixo de tempo de compactação (geralmente maior). Os aGIFs estão essencialmente “folheando” imagens GIF estáticas rapidamente. Essa falta de compactação adiciona uma quantidade significativa de dados. Felizmente, é possível substituir aGIFs por um vídeo em loop, potencialmente economizando MBs de dados para cada solicitação.

 <video loop autoplay muted playsinline src="pseudoGif.mp4">

No Safari, há uma abordagem ainda mais sofisticada: você pode colocar um mp4 em loop na tag da imagem, assim:

 <picture> <source type="video/mp4" loop autoplay> <source type="image/webp"> <src="animated.gif"> </picture>

Nesse caso, o Safari reproduzirá o GIF animado, enquanto o Chrome (e outros navegadores que suportam WebP) reproduzirá o WebP animado, com um fallback para o GIF animado. Você pode ler mais sobre essa abordagem no ótimo post de Colin Bendell.

Vídeos de terceiros

Uma das maneiras mais fáceis de adicionar vídeo ao seu site é simplesmente copiar/colar o código de um serviço de compartilhamento de vídeo e colocá-lo em seu site. No entanto, assim como adicionar qualquer terceiro ao seu site, você precisa estar atento sobre que tipo de conteúdo é adicionado à sua página e como isso afetará o carregamento da página. Muitos desses widgets “simplesmente cole isso em seu HTML” adicionam 100s de KB de JavaScript. Outros farão o download do filme inteiro (pense em preload="auto" ), e alguns farão as duas coisas.

Prática recomendada de vídeo de terceiros : confie, mas verifique. Examine quanto conteúdo é adicionado e quanto isso afeta o tempo de carregamento da página. Além disso, o comportamento pode mudar, portanto, acompanhe suas análises regularmente.

Inicialização de transmissão

Quando um fluxo de vídeo é solicitado, o servidor fornece um arquivo de manifesto ao player, listando todos os fluxos disponíveis (com dimensões e informações de taxa de bits). No streaming HLS, o player geralmente escolhe o primeiro stream na lista para iniciar a reprodução. Portanto, o fluxo posicionado primeiro no arquivo de manifesto deve ser otimizado para inicialização de vídeo em dispositivos móveis e computadores (ou talvez arquivos de manifesto alternativos devam ser entregues em dispositivos móveis versus computadores).

Na maioria dos casos, a inicialização é otimizada usando um fluxo de qualidade inferior para iniciar a reprodução. Depois que o player baixa alguns segmentos, ele tem uma ideia melhor da taxa de transferência disponível e pode selecionar um fluxo de maior qualidade para segmentos posteriores. Como usuário, você provavelmente já viu isso – onde os primeiros segundos de um vídeo parecem muito pixelados, mas alguns segundos após a reprodução o vídeo fica mais nítido.

Ao examinar 1.065 arquivos de manifesto entregues a dispositivos móveis a partir do HTTP Archive, descobrimos que 59% dos vídeos têm uma taxa de bits inicial inferior a 1,2 MBPS – e provavelmente começarão a transmitir sem muito atraso a taxas de dados 3G de 1,6 MBPS. 11% usam uma taxa de bits entre 1,2 e 1,6 MBPS — o que pode retardar a inicialização em 3G e 30% têm uma taxa de bits acima de 1,6 MBPS — e não conseguem reproduzir nessa taxa de bits em uma conexão 3G. Com base nesses dados, parece que cerca de 41% de todos os vídeos não serão capazes de sustentar a taxa de bits inicial em dispositivos móveis, aumentando o atraso na inicialização e possivelmente aumentando o número de travamentos durante a reprodução.

Prática recomendada de inicialização de streaming : certifique-se de que sua taxa de bits inicial no arquivo de manifesto funcione para a maioria de seus clientes. Se o player precisar alterar os fluxos durante a inicialização, a reprodução será atrasada e você perderá visualizações de vídeo.

Então, o que acontece quando a taxa de bits do vídeo está próxima (ou acima) da taxa de transferência disponível? Após alguns segundos de download sem um segmento de vídeo completo pronto para reprodução, o player interrompe o download e escolhe um vídeo com taxa de bits de qualidade inferior e inicia o processo novamente. A ação de baixar um segmento de vídeo e depois abandoná-lo leva a um atraso adicional na inicialização, o que levará ao abandono do vídeo.

Podemos visualizar isso construindo manifestos de vídeo com diferentes taxas de bits iniciais. Testamos 3 cenários diferentes: começando com a taxa de bits mais baixa (215 KBPS), média (600 KBPS) e mais alta (2,6 MBPS).

Ao começar com o vídeo de qualidade mais baixa, a reprodução começa aos 11s. Após alguns segundos, o player começa a solicitar um fluxo de maior qualidade e a imagem fica mais nítida.

Ao iniciar com a taxa de bits mais alta (testando em uma conexão 3G a 1,6 MBPS), o player percebe rapidamente que a reprodução não pode ocorrer e alterna para o vídeo com a taxa de bits mais baixa (215 KBPS). O vídeo começa a ser reproduzido aos 17s. Há um atraso de 6 segundos e a qualidade do vídeo é a mesma baixa qualidade fornecida no primeiro teste.

Usar o vídeo de qualidade média permite um pouco de compensação, o vídeo começa a ser reproduzido em 13s (2 segundos mais lento), mas é de alta qualidade desde o início - e não há salto de pixelizado para vídeo de qualidade superior.

Prática recomendada para inicialização de vídeo : para uma reprodução mais rápida, comece com o fluxo de qualidade mais baixa. Para vídeos mais longos, considere usar um fluxo de 'qualidade média' no início para fornecer um vídeo nítido na inicialização (com um atraso um pouco maior).

Resultados do WebPageTest: O fluxo de vídeo inicial é baixo, médio e alto (de cima para baixo). O vídeo começa mais rápido com o vídeo de qualidade mais baixa. É importante notar que o vídeo inicial de alta qualidade aos 17s é a mesma qualidade que o início de baixa qualidade aos 11s.

Streaming: reprodução contínua

Quando o player de vídeo puder determinar o fluxo de vídeo ideal para reprodução e o fluxo for inferior à velocidade de rede disponível, o vídeo será reproduzido sem problemas. Existem truques que podem ajudar a garantir que o vídeo seja entregue de maneira ideal. Se examinarmos a seguinte entrada de manifesto:

 #EXT-X-STREAM-INF:BANDWIDTH=912912,PROGRAM-ID=1,CODECS="avc1.42c01e,mp4a.40.2",RESOLUTION=640x360,SUBTITLES="subs" video/600k.m3u8

A linha de informações informa que esse fluxo tem uma taxa de bits de 913 KBPS e resolução de 640 × 360. Se observarmos o URL para o qual essa linha aponta, veremos que ele faz referência a um vídeo de 600k. Examinar os arquivos de vídeo mostra que o vídeo tem 600 KBPS e o manifesto está superestimando a taxa de bits.

Exagerando a taxa de bits do vídeo

• PRÓ
  Exagerar na taxa de bits garantirá que, quando o player escolher um fluxo, o download do vídeo será mais rápido do que o esperado e o buffer será preenchido mais rapidamente do que o esperado, reduzindo a possibilidade de travamento.
• VIGARISTA
  Ao superestimar a taxa de bits, o vídeo entregue será um fluxo de qualidade inferior. Se observarmos toda a lista de taxas de bits relatadas versus reais:

Para usuários em uma conexão de 1,6 MBPS, o player escolherá a taxa de bits de 913 KBPS, atendendo ao vídeo de 600 KBPS do cliente. No entanto, se as taxas de bits tivessem sido relatadas com precisão, a taxa de bits de 950 KBPS seria usada e provavelmente seria transmitida sem problemas. Embora as escolhas aqui evitem paralisações, elas também diminuem a qualidade do vídeo entregue ao consumidor.

Prática recomendada : Um pequeno exagero na taxa de bits do vídeo pode ser útil para reduzir o número de interrupções na reprodução. No entanto, um valor muito grande pode levar a uma reprodução de qualidade reduzida.

Teste o vídeo Neilsen no navegador e veja se você consegue fazê-lo pular para frente e para trás.

Conclusão

Neste post, abordamos várias maneiras de otimizar os vídeos que você apresenta em seus sites. Seguindo as melhores práticas ilustradas neste post:

1. preload="auto"
   Use apenas se houver uma alta probabilidade de que este vídeo seja assistido por seus clientes.
2. preload="metadata"
   Padrão no Chrome, mas ainda pode levar a downloads de arquivos de vídeo grandes. Use com cuidado.
3. Vídeos silenciosos (GIFs em loop ou vídeos de fundo)
   Retirar o canal de áudio
4. Dimensões do vídeo
   Considere entregar vídeos de tamanhos diferentes para dispositivos móveis em computadores. Os vídeos serão menores, baixarão mais rápido e é improvável que seus usuários vejam a diferença (a carga do servidor também diminuirá!)
5. Compressão de vídeo
   Não se esqueça de compactar os vídeos para garantir que eles sejam entregues
6. Não 'esconda' vídeos
   Se o vídeo não for exibido — não faça o download.
7. Audite seus vídeos de terceiros regularmente
8. Transmissão
   Comece com um fluxo de qualidade inferior para garantir uma inicialização rápida. (Para vídeos de reprodução mais longos, considere uma taxa de bits média para obter melhor qualidade na inicialização)
9. Transmissão
   Não há problema em ser conservador na taxa de bits para evitar atrasos, mas vá longe demais e os fluxos fornecerão um vídeo de qualidade inferior.

Você descobrirá que o vídeo em sua página é otimizado para uma entrega ideal e que seus clientes não apenas se deliciarão com o vídeo que você apresentar, mas também desfrutarão de um tempo de carregamento de página mais rápido em geral.