Qual player de vídeo a maioria dos editores está usando?

Esta postagem foi atualizada pela última vez em 6 de julho de 2022

Nesta postagem de blog detalhada, examinaremos mais de perto os diferentes players de vídeo disponíveis para os editores no mercado, compararemos seus recursos (tabela de comparação incluída), examinaremos a veiculação de anúncios em vídeo, diferentes blocos de anúncios em vídeo e até mesmo as armadilhas de veiculação de anúncios.

Se você trabalha atualmente com o Google Ad Exchange, incluímos uma seção que também fornece as práticas recomendadas para veiculação de anúncios em vídeo. Vamos começar!

jogador JW

O player JW é um dos players baseados na web mais usados ​​que suportam uma ampla variedade de formatos (HLS, VAST 3.0, VPAID 2.0) e se integra à maioria das principais redes de anúncios.

Saiba mais sobre VPAID x VAST aqui.

Este player de vídeo oferece suporte à veiculação de anúncios multiplataforma com recursos avançados, como suporte a transmissão ao vivo, legendas ocultas e é à prova de futuro com suporte nativo para reprodução de vídeos 360 e VR.

Ele fornece SDKs nativos para Android e iOS para implementações no aplicativo. Também é um provedor confiável para veicular anúncios por meio do pacote DoubleClick do Google e é um parceiro de publicação certificado pelo Google.

Os clientes do jogador JW incluem Amazon, Vice, Univision, Fox e muitos mais. O JW player, em colaboração com o SpotX, introduziu recentemente lances de cabeçalho nativos (vídeo) para monetização de conteúdo veiculado usando o JW player.

Demonstrações e exemplos de implementações do reprodutor podem ser encontradas aqui, para se ter uma ideia dos recursos e aspectos funcionais do reprodutor.

Recursos disponíveis na versão oito do JW player:

• Suporte a streaming multiprotocolo: HLS, DASH (Adobe RTMP não suportado)
• Suporte para reprodução de vídeo 4K no modo HTML5
• Suporte para reprodução de vídeo 60FPS
• Suporte para listas de reprodução em formato RSS/XML e JSON
• VAST 4.0, VPAID 2.0, suporte a VMAP
• Integração com os principais SDKs de servidores de anúncios: Google IMA SDK e FreeWheel Ad Manager SDK
• Agrupamento, cascata/substituto, programação de anúncios

O preço deste player de vídeo começa em $ 5 por mês (cobrado anualmente). O preço personalizado para monetização por meio da veiculação de anúncios com base no tráfego é superior a US$ 50 por mês. A integração do IMA SDK não está disponível para as ofertas de entrada (5$ pm) e de nível médio (50$ pm).

Ooyala

A versão mais recente do reprodutor de vídeo Ooyala possui uma longa lista de recursos, que atenderão a todas as suas necessidades de publicação e monetização de vídeo. O design da interface do usuário segue as diretrizes do Google Material UX e é altamente personalizável para refletir sua marca.

Alguns dos recursos disponíveis no Ooyala player 4.0 são:

• Controles do player com reconhecimento de conteúdo
• Legendas codificadas (DFXP)
• Capacidade de compartilhar conteúdo nas mídias sociais
• Motor de recomendação
• Formatos suportados: VAST 3.0, VPAID 2.0, VMAP 1.0, HLS e MP4, OSMF Flash HDS, HDS empacotado pela Akamai e DASH e HLS
• Busca reversa na reprodução de conteúdo de transmissão ao vivo
• Agrupamento e gerenciamento de pontos de sinalização
• SDK para Android e iOS
• Integração do Google IMA por meio de um plug-in.
• Suporte a plataforma multianalítica (Adobe, comScore, Nielsen, Google Analytics, etc.)
• Oferta de monetização nativa via pulso Ooyala.
• Possui várias integrações de rede de anúncios prontas para uso.

Preços: Veja a estrutura de preços do cliente.

Brightcove

As ofertas de monetização e publicação de vídeo da Brightcove são voltadas para grandes editores com alto tráfego e grandes catálogos de conteúdo. O conjunto de produtos Brightcove atende a todos os requisitos para publicação de conteúdo de vídeo, desde a reprodução de conteúdo básico até a hospedagem de conteúdo, ingestão de conteúdo, análise avançada e ferramentas de marketing.

Isso ajudará a reduzir o número de peças móveis, eliminando assim quaisquer problemas de compatibilidade e aumentando a confiabilidade. Algumas das maiores marcas, como Ford, BBC, Oracle, Condenast e GoDaddy, usam a suíte Brightcove para suas necessidades de publicação.

Características incluem:

• Integração de IMA, OnceUX, SpotX e FreeWheel do Google
• Suporte para reprodução de vídeo 360
• Disponibilidade de proteção de conteúdo DRM (formato Widevine Media)
• Suporte de entrega multiformato de transmissão ao vivo (HLS, DASH, FairPlay Streaming da Apple)
• iOS nativo e SDK do Android para implementações no aplicativo
• Suporte nativo para tvOS (Apple TV)
• Suporte Airplay para conteúdo não monetizado com iOS SDK nativo
• Integração Native Analytics e Adobe Analytics
• Suporte a várias faixas de áudio em SDKs iOS e Android nativos
• Suporte para veiculação de anúncios do lado do servidor

Preço: apenas preços personalizados disponíveis.

Video.js

Ao contrário dos outros players nesta lista, o Video.js é uma oferta de código aberto de um player de vídeo baseado em HTML5 com suporte para monetização de vídeo. O principal patrocinador do projeto é a Brightcove, cujo reprodutor de vídeo também é construído sobre o framework video.JS.

O projeto tem uma comunidade muito útil com uma ampla gama de plugins para integração de terceiros e serviços adicionais. Ele pode ser personalizado de acordo com os requisitos (ajustes de HTML, CSS e Javascript são necessários) ou pode ser usado imediatamente.

Consulte o guia aqui e o plug-in disponível para oferecer suporte à integração do IMA SDK.

Alguns clientes conhecidos incluem Instagram, Twitter, Microsoft, Github, IGN, The Guardian e muitos mais.

Os recursos suportados pelos plug-ins são:

• Curadoria de lista de reprodução personalizada
• Suporte a Airplay e chromecast (depende do navegador e do dispositivo)
• Integração do Google Analytics
• Suporte para transmissão ao vivo (HLS e DASH)
• Relatório de erros personalizado
• Reprodução de conteúdo DRM (Apple Fairplay)
• Integração do SDK do IMA
• Integração CDN Ooyala
• Suporte para vídeo 360, VR e panorama
• Mecanismo de recomendação de conteúdo
• Integração de compartilhamento social

Preço: Gratuito

Matriz de comparação de recursos

Informações básicas sobre players de vídeo

Tradicionalmente, os players de vídeo tinham apenas um trabalho a fazer, reproduzir o conteúdo apenas com controles básicos de navegação. Os jogadores tinham uma lista de formatos de vídeo que podiam renderizar, e é isso.

Hoje, os players de vídeo evoluíram para atender a uma demanda cada vez maior e muitas funcionalidades além de apenas reproduzir um recurso de vídeo. Com a adoção do HTML5 em toda a indústria, uma vez que os players amplamente usados, baseados na estrutura do flash, estão em rápido declínio.

Existem vários motivos para você mudar para um player HTML5 em vez de players baseados em flash, dos quais os dois principais fatores determinantes são velocidade e segurança.

No entanto, se você deseja fornecer conteúdo baseado em flash, existem várias opções para você, mesmo a partir de agora, muitos players de vídeo oferecem suporte a arquivos de vídeo em formato flash.

No contexto da veiculação de anúncios, o flash não é mais compatível com os principais navegadores da web.

Como um player de vídeo solicita e veicula um anúncio?

Um player primeiro requer a implementação de uma tag de anúncio em vídeo, que será acionada nos pontos de sinalização em que o anúncio deve ser renderizado.

Existem três posições principais em que os anúncios em vídeo são veiculados:

1. Pre-roll: O anúncio quando reproduzido/renderizado antes do início da reprodução do conteúdo.
2. Anúncio intermediário: qualquer posição entre o início e o fim do conteúdo é considerada como anúncio intermediário.
3. Finalização : o anúncio quando reproduzido/renderizado no final/conclusão do conteúdo.

Quando a solicitação é feita ao servidor de anúncios, ocorre a seleção/RTB do anúncio e o anúncio vencedor é retornado em uma resposta VAST XML com todos os ativos de mídia associados e pings de eventos de rastreamento.

(VAST significa 'Digital Video Ad Serving Template', que é uma especificação desenvolvida pelo IAB para ter uma resposta XML comum de todos os servidores de anúncios. Antes disso, cada servidor de anúncios e player exigia uma resposta em diferentes formatos, o que não era eficiente)

Depois que o player recebe a resposta VAST XML do servidor de anúncios, ele busca os arquivos de ativos criativos e os renderiza nos pontos de sinalização predefinidos antes/durante/depois da reprodução do conteúdo.

O player também acionará os eventos de rastreamento retornados no XML VAST nos acionadores de eventos associados. Caso haja alguma falha/problema, um erro VAST é acionado e registrado no servidor de anúncios para análise futura.

Existem três maneiras diferentes de hospedar os ativos de mídia no caso de veiculação de anúncios em vídeo:

servidor de anúncios hospedado

Os recursos de mídia são hospedados no servidor de anúncios usado para veicular os anúncios. A vantagem dessa abordagem é que uma URL de hospedagem direta dos arquivos de mídia é retornada na resposta VAST. Isso reduz significativamente a latência e a taxa de falhas para buscar os arquivos de mídia pelo player.

Hospedado externamente

Os ativos de mídia são hospedados em um CDN de terceiros e o URL de hospedagem é retornado no VAST XML. Isso pode aumentar a latência na busca dos arquivos de mídia, dependendo do tempo de resposta da CDN.

Marcas de redirecionamento

Este é o tipo de hospedagem de ativo de mídia mais comumente usado em que uma tag de redirecionamento é trafegada no servidor de anúncios e a mesma tag é retornada no VAST XML. O player aciona a tag de redirecionamento que busca os arquivos de mídia em uma segunda resposta VAST.

Esta opção é normalmente utilizada em implementações onde outro leilão é realizado em um segundo ad server, e os arquivos de mídia/anúncio podem ser diferentes para cada requisição.

Tipos de blocos/implementação/veiculação de anúncios em vídeo

Em transmissão

Nesse tipo de veiculação de anúncio em vídeo, os anúncios em vídeo são veiculados em um player/aplicativo. O foco principal do público-alvo, neste caso, será o conteúdo veiculado pelo player de vídeo especificamente. 3 formatos de anúncios geralmente são veiculados neste ambiente:

1. Linear: geralmente são anúncios em formato de vídeo e são veiculados interrompendo a reprodução do conteúdo.Existem três posições/linhas do tempo em que os anúncios lineares podem ser veiculados, antes do conteúdo (preroll), durante a reprodução do conteúdo (midroll) e após o término da reprodução do conteúdo (post-roll).
2. Não lineares: geralmente são imagens estáticas ou formatos habilitados para rich media, que não interrompem/pausam a reprodução do conteúdo.Eles são típicos de tamanho menor e são sobrepostos na seção inferior/inferior do player de vídeo.
3. Complementar: são anúncios gráficos gerais veiculados junto com os anúncios lineares nas proximidades do player para obter uma experiência mais envolvente e também para fornecer aos usuários a opção de realizar uma ação relacionada ao anúncio em vídeo veiculado antes, mesmo após o término (útil no caso de de anúncios em vídeo curtos).

Fluxo de saída:

Nesse tipo de implementação, não há conteúdo focal em um player de vídeo. Os anúncios em vídeo são exibidos de acordo com o conteúdo de exibição na página.

Existem várias formas ou implementações para veicular anúncios em vídeo outstream. O mais comum é o vídeo em banner, em que um anúncio em vídeo é renderizado em uma unidade de anúncio gráfico.

Outras implementações comumente usadas são vídeo intersticial, vídeo na página (gerando um player).

Pontos comuns de falha específicos da veiculação de anúncios em vídeo:

Tempo limite : Todo jogador tem a opção de definir um tempo limite predefinido, que quando atingido, o conteúdo iniciará a reprodução.Isso garante que o conteúdo/reprodução não seja interrompido, caso haja latência/atraso na busca dos arquivos de mídia, o que proporciona uma experiência de usuário ideal.

Resposta VAST vazia: é uma possibilidade no caso de tags de redirecionamento, se o URL de redirecionamento não buscou um anúncio, ou seja, a solicitação para o servidor de anúncios de terceiros não foi atendida.

Vários redirecionamentos: alguns anunciantes/provedores de criativos retornam outra tag de redirecionamento para a primeira tag de redirecionamento trafegada.Isso pode ser devido ao encadeamento e loops infinitos ou atraso em cada uma das respostas de redirecionamento.

Para evitar isso, os players de vídeo têm um limite de redirecionamento que, quando atingido, gera um erro VAST. Se não houver limite definido, o próximo ponto de falha será atingir o tempo limite.

Formato de recurso de mídia não compatível: se o player de vídeo não conseguir renderizar os arquivos de mídia retornados no XML VAST, esse erro será acionado.Esse erro não é muito comum, pois haverá vários arquivos de mídia retornados, cada um com tamanho, taxa de bits, codificação etc. diferentes. O player pode escolher aquele que melhor se adapta ao ambiente em que o anúncio será renderizado.

Perder receita quando um anúncio não é reproduzido e aciona um erro?

E se as tags trafegadas em seu servidor de anúncios falharem em buscar um anúncio?

A oportunidade de gerar receita com essa solicitação/impressão específica será perdida. Para resolver esse problema, a cascata/retrocesso entra em ação. Quando um substituto é ativado em seu servidor de anúncios, ele envia um número predefinido de anúncios vencedores na resposta VAST XML.

Se o primeiro falhar por qualquer motivo, o jogador passará para o próximo anúncio da lista. Esse processo continua até que o player possa reproduzir um anúncio.

A pergunta óbvia nesse cenário é: isso causará um atraso/aumento no carregamento do anúncio e nos tempos de renderização?

A sobrecarga, neste caso, é muito insignificante e o jogador percorre o fallback em questão de milissegundos.

Um possível ponto de falha mesmo se o fallback estiver configurado corretamente:

O único ponto de falha, neste caso, seria se o servidor de terceiros não retornasse uma resposta ou retornasse uma resposta vazia pela falta de um anúncio.

Nesse caso, o reprodutor de vídeo aguardará o tempo limite definido, que uma vez atingido iniciará a reprodução do conteúdo. Os anúncios no substituto nem sequer foram testados.

Como resolver o problema do acionamento do timeout antes que todos os anúncios no fallback tenham sido tentados?

Existem duas abordagens para isso:

1. Teste a latência na resposta do servidor de anúncios de terceiros e evite usar servidores/tags de anúncios que demoram muito para retornar uma resposta, quando não há lances/anúncios vencedores.
2. Defina o tempo limite padrão do player para uma duração maior, dependendo dos tempos médios de resposta do servidor de anúncios das tags trafegadas em seu servidor de anúncios ou de parceiros de demanda.

Dicas e práticas recomendadas para veicular anúncios em vídeo por meio do Google Ad Exchange (AdX)

• Para poder veicular anúncios por meio das plataformas programáticas do Google, é necessário que o player de vídeo esteja integrado ao IMA SDK sem o que pode haver inconsistências e discrepâncias nos relatórios.

• Se a integração do SDK do IMA não for viável, o Google oferece uma abordagem alternativa para atender à demanda do AdX por meio do uso de tags de adaptador. Uma tag de adaptador, quando veiculada em um player integrado não IMA, emulará a funcionalidade SDK do IMA para essa solicitação específica e fornecerá todas as chamadas de função e funcionalidade de um player integrado SDK do IMA. As tags do adaptador podem ser geradas selecionando a tecnologia como 'Adaptador de IMA' ao gerar as tags de vídeo no Google AdX.

• Evite veicular tags do adaptador IMA em players integrados do SDK do IMA, pois essa não é uma abordagem recomendada e pode não reproduzir o anúncio, acionando um erro VAST 901.
• Garanta a conformidade com as políticas específicas de vídeo do AdX listadas aqui, além das políticas do programa AdX.
• A partir de abril de 2018, a nova atualização de política do Chrome impõe uma restrição à reprodução automática de anúncios em vídeo. Isso afetará apenas se você estiver veiculando anúncios em vídeo de reprodução automática com som e não se aplica a anúncios em vídeo de reprodução automática que são silenciados por padrão.
• Anúncios em vídeo não silenciados de reprodução automática podem ser veiculados apenas se algum dos seguintes critérios for atendido:
  • Antes de o anúncio iniciar a reprodução, o usuário interagiu em seu website.
  • O MEI (Media Engagement Index) do usuário é superior a um limite predefinido (somente para desktop). O cálculo do índice MEI é detalhado neste artigo.
  • Em uma plataforma móvel, se o usuário tiver fixado/marcado o site na tela inicial do dispositivo.

Conclusão

Embora tenhamos apresentado todas as informações para você neste artigo, os players de vídeo e a veiculação de anúncios em vídeo podem ser complicados. Para obter ajuda para escolher o caminho certo para o seu negócio editorial e implementá-lo corretamente, inscreva-se em uma conta profissional na MonetizeMore hoje!

Questões adicionais