- player.style é uma coleção de temas para players de vídeo e áudio baseada no Media Chrome, aplicável da mesma forma a diversos players web e frameworks de apps
- Depois de escolher o tema de player desejado e selecionar o player e o framework, o fluxo leva a um código que pode ser copiado e colado
- É possível filtrar temas por Video/Audio, HTML, React, Next.js, Vue, Svelte e por recursos como timeline thumbnails, AirPlay, Google Cast, chapters e tooltips
- A UI do player pode ser ajustada apenas com HTML e CSS, e também há configurações de cores de tema como Primary, Secondary e Accent
- Sutro, Instaplay, Notflix, YT, Minimal, Winamp e outras experiências de players de mídia existentes foram recriadas como temas para a web, permitindo aplicação rápida
Como usar e customizar o player.style
- player.style oferece temas para players de vídeo e áudio criados com Media Chrome
- O escopo alvo é “every web player” e “every web app framework”
- O fluxo de aplicação é composto por 3 etapas simples
- Escolher um tema de player de que você goste
- Selecionar o player e o framework de app que serão usados
- Copiar e colar o código gerado
- A UI do player pode ser ajustada em detalhes apenas com HTML e CSS
- Os filtros e itens de configuração incluem:
- Mídia: Video, Audio
- Frameworks: HTML, React, Next.js, Vue, Svelte
- Recursos: timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
- Cores: Primary, Secondary, Accent
Galeria de temas de players web
- Sutro: tema elegante e moderno inspirado no nome da antena de TV de SF
- X-mas: tema natalino com tons de vermelho e verde, luzes cintilantes e clima de fim de ano
- Halloween: tema que adiciona uma atmosfera de Halloween ao player de vídeo
- Instaplay: tema mobile-first inspirado na experiência de reprodução de um app popular de mídia social
- Sutro Audio: tema de áudio com a mesma descrição do Sutro
- Notflix: tema que remete a uma experiência sem o “grande N vermelho” e a longa viagem de ônibus para Los Gatos
- Reelplay: tema de player de mídia retrô inspirado em players de mídia do passado
- Vimeonova: tema que reinterpreta o design clássico do player do Vimeo
- YT: homenagem ao player do YouTube moderno e amplamente usado, recriado da forma mais próxima possível com Web Components
- Tailwind Audio: tema minimalista de player de áudio feito com Tailwind CSS
- Demuxed 2022: tema de player de mídia criado para o Demuxed 2022
- Microvideo: tema voltado para conteúdos curtos que não precisam de controles de reprodução robustos exigidos por conteúdos longos
- Minimal: tema simples que reduz a experiência do Mux Player aos controles básicos necessários para o espectador
- Winamp: tema retrô inspirado no clássico player de mídia Winamp
1 comentários
Opiniões no Hacker News
Se você só precisa de música, e não de vídeo, https://webamp.org/ também vale a pena ver
Não é preciso “compilar” nem fazer uma grande “integração”; é só incluir, e a playlist pode ser gerada pelo app. Ex.: Music
Gosto desta ideia e agradeço por a terem disponibilizado sob licença MIT
Por acaso estou criando um app de mídia — mais exatamente, um editor de vídeo — e no passado também já criei alguns players de vídeo em Flash e HTML/JS. Por volta de 2015, usei Web Components em um player, mas continuou sendo doloroso, então acabei voltando ao JavaScript comum. Curiosamente, no app de mídia atual estou usando Web Components, como uma timeline de editor de vídeo, e até agora tem funcionado muito bem. Não sei ao certo o que mudou, ou se a compatibilidade finalmente ficou boa o suficiente graças à evolução lenta da Web
Dei uma olhada na documentação do Media Chrome e passei rapidamente pelo repositório no GitHub, e gostei dos princípios de design e das notas de arquitetura. Ao adotar algo assim, especialmente do ponto de vista de quem já construiu esse tipo de coisa várias vezes, minhas maiores preocupações são extensibilidade e tamanho dos arquivos. Por exemplo, fico curioso para saber quão difícil seria adaptar meu componente de timeline ao paradigma do MediaController. Quando se constrói tudo por conta própria, a vantagem é ter só o que é necessário e nada além disso. O Media Chrome provavelmente tem muitos recursos que eu jamais usaria; a questão é quanto peso desnecessário eu teria de carregar por causa disso. Não apenas componentes não usados, mas também recursos não usados dentro dos componentes usados. Às vezes, recursos desnecessários existentes também atrapalham a extensibilidade em um nível mais baixo
Além disso, o repositório
media-elements[1] não tem arquivo de licença. O package.json diz que os elementos também são MIT, mas é sempre bom ter um arquivo LICENSE explícitoAinda assim, é uma biblioteca bem atraente. No mínimo, até agora era a página que a incluía que conectava os elementos, e eu estava querendo uma abstração melhor; então acho que vou roubar a ideia de envolver meus componentes em algo como um media-controller
Nesse meio-tempo houve a especificação v2 de Web Components, mas não sou especialista no que mudou. Hoje vejo Web Components em vários lugares, especialmente em players de mídia. Um exemplo é o player web da Apple
Fico feliz que você tenha gostado da arquitetura do controller. As versões iniciais faziam todos os elementos apontarem diretamente para o elemento de mídia, e a chegada do controller organizou muito as coisas. Pelo menos em comparação com a forma como eu fazia, recomendo fortemente
Vejo a UI de editor de vídeo como uma extensão natural da família Media Chrome. Seria ótimo se você abrisse uma issue no repositório dizendo o que mais ajudaria nessa área
Entendo profundamente a hesitação em adotar algo como o Media Chrome por causa da flexibilidade futura e do tamanho. Para mim, há 3 pontos que poderiam convencer: 1) você pode incluir apenas os componentes de UI de que precisa, e isso é uma grande diferença em termos de tamanho em relação a outros players de vídeo na Web. 2) alguns dos desenvolvedores de players mais experientes estão trabalhando nisso, inclusive em partes como acessibilidade e internacionalização futura. 3) estamos tentando torná-lo muito configurável com slots, CSS parts e variáveis CSS
Claro que não dá para vencer o tamanho de arquivo de um software totalmente sob medida, mas, quando todos os recursos básicos estiverem prontos, acho que vai chegar bem perto. Obrigado por avisar sobre a licença dos elements
A estratégia de marketing da Mux é inteligente
Ela compra projetos open source ou cria novos para que desenvolvedores procurando pacotes de vídeo acabem se deparando com o nome da empresa
Outro exemplo recente que vi é https://github.com/cookpete/react-player
Parte do que se vê no lado de players open source acontece porque, de todo modo, acabamos tendo de dar suporte a esses projetos. Como somos agnósticos em relação a players, nossos clientes usam vários projetos open source, inclusive alguns que não têm manutenção muito ativa
Hoje há pouquíssimas empresas de vídeo voltadas a desenvolvedores contribuindo ativamente com open source, então acho que estamos nos beneficiando disso
O Mux parece bom, mas não confio que a empresa vá manter para sempre o tier gratuito de encoding de vídeo, então acho que eu não construiria nada em cima disso
Encoding on-demand para usuários também parece fazer pouco sentido em termos de recursos. O modelo starter funciona comprando US$ 100 em créditos por US$ 10. Tudo parece um grande produto isca, e está ficando difícil confiar em empresas que parecem queimar dinheiro todos os dias. Eu preferiria que cobrassem alguma coisa. Sei que encoding não é de graça. Ou, se houvesse uma seção no site explicando como conseguem continuar no negócio cobrando menos do que todo mundo no setor, isso reduziria bastante a minha desconfiança. Já me queimei demais com SaaS
“Uma seção explicando como conseguem continuar no negócio cobrando menos do que todo mundo no setor” é um feedback muito bom, e vou colocar na lista de coisas a fazer. Isso definitivamente precisa existir
Não vamos oferecer preços com uma economia que não conseguimos sustentar, ou no mínimo precisamos ter um caminho claro para sustentá-los. Todos os preços por volume são públicos, então, se você entende o conceito de créditos, não deveria acabar sofrendo uma mudança de preço depois da isca. É o oposto de alguns concorrentes que surpreendem usuários com novos preços quando eles crescem. Eu detesto essa abordagem
Internamente, temos uma vantagem por usar encoding just-in-time e outras otimizações avançadas. Também temos economias de escala, e pretendemos escrever sobre isso
Dito isso, a percepção dos clientes é difícil. Alguns clientes entendem encoding e seus custos, além dos benefícios de adaptive streaming ou de lidar com uploads gerados por usuários. Muitos desenvolvedores estão mexendo com vídeo pela primeira vez e esperam que custe o mesmo que colocar um MP4 no S3. Algumas pessoas apontam concorrentes que não têm custo de encoding; outras dizem que deveria ser mais barato por causa do YouTube. No passado, a Mux cobrava pelo encoding, então era classificada como a “opção cara”; por isso estamos criando uma nova estrutura de preços em que você começa em um nível de encoding mais baixo e economicamente sustentável e, se achar que há valor, pode escolher níveis mais altos de custo/valor de encoding. Parte disso já foi lançado e parte ainda está por vir
Acreditamos que vídeo deveria estar presente em muito mais lugares do que hoje, mas vídeo é inerentemente caro em comparação com muitos outros custos de criar apps. Por isso vemos como nosso trabalho continuar reduzindo custos e refinando a estrutura de preços para permitir o uso de vídeo em mais casos de uso
Os trade-offs ao usar encoding gratuito estão resumidos aqui: https://docs.mux.com/guides/use-video-quality-levels. Mesmo com o encoding basic gratuito, ainda há cobrança por armazenamento e transferência. Esperamos que, se ajudarmos a reduzir custos no início, possamos crescer juntos
Encoding on-demand, ou JIT, realmente parece mágica quando você vê o quão consistentemente ele funciona bem
Trabalho na Mux
Há algumas coisas meio estranhas aqui no tratamento de foco. Espero que isso seja recebido como crítica construtiva; todos têm o mesmo problema
Se você clicar no próprio vídeo, as setas esquerda/direita permitem navegar para frente e para trás no vídeo. Para cima/para baixo não fazem nada
Se você clicar na barra de navegação, as setas esquerda/direita param de funcionar. Em vez disso, as setas para cima/para baixo começam a retroceder/avançar em intervalos de tempo diferentes
Se você clicar em algum espaço vazio, como a barra azul com aparência de Windows 98 no exemplo do Winamp ou do Reelplay, todos esses controles param de funcionar, e espaço para reproduzir/pausar também não funciona
Verificado no Chrome mais recente no macOS
Em geral, a situação fica um pouco complicada por causa da sobreposição entre “atalhos” que controlam o vídeo, controles de acessibilidade de cada componente e expectativas gerais de acessibilidade da página inteira. Por exemplo, quando o player está com foco, devemos sempre capturar as setas para cima/baixo para controlar volume, ou não deveríamos fazer isso porque as pessoas esperam usá-las para rolar a página?
De qualquer forma, essa é uma área que ainda precisa de mais iterações, então o feedback ajuda
Player.style é excelente
Na minha startup anterior, comecei a criar um tema de video.js do zero, mas algumas horas depois decidi que não valia meu tempo e usei o padrão. No futuro, esses temas devem ser um ponto de partida muito melhor para criar algo mais customizado
Já que há especialistas em vídeo nesta thread, fico curioso se existe alguma implementação de player que permita navegação rápida e suave com áudio
Estou falando de algo parecido com o recurso do Adobe Premiere de percorrer ou assistir à timeline em 16x. Imagino que seria preciso carregar agressivamente com antecedência algo como uma faixa de áudio mono de 16 kHz e um formato de vídeo 240p com sprites a 1 fps ou apenas I-frames, e trocar para isso durante a navegação
Não há uma resposta exata, mas talvez valha a pena olhar para a área de WebCodecs, onde estão surgindo exemplos de alta performance em um nível mais baixo: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...
Web Components são ótimos, e a Mux está fazendo coisas legais com eles
O código pode ser ajustado para funcionar com embeds do YouTube
Basta definir o seguinte no
srcdo embed do YouTubecontrols=0– remove os controles do player, como reproduzir, pausar e volumemodestbranding=1– minimiza o logotipo do YouTube dentro do playerrel=0– impede que vídeos relacionados sejam exibidos no final. Funciona apenas mostrando vídeos do mesmo canalshowinfo=0– remove o título do vídeo e as informações do uploader. Esse parâmetro foi descontinuado, masmodestbrandingajudafs=0– desativa o botão de tela cheiaiv_load_policy=3– oculta anotações de vídeo, como notificações pop-upDepois disso, no código, basta detectar a URL de embed do YouTube e criar o player com um
iframeem vez de uma tagvideo. Por fim, é só mapear os controles do player para a API de embed do YouTube. O Plyr.io fez algo parecidoFazer algo mais ou menos parecido com o Winamp não significa que isso seja Winamp