Recherche avancée

Sur d’autres sites (7394)

• HTML5 Video Compatibility (MP4, WEBM, OGG) in 2021

  19 juillet 2021, par William

  The support of HTML5 video has evolved a lot over the years. I am trying to understand whether the <video></video> element still needs to have three sources : MP4, WEBM, and OGG.

  


  There are a lot of answers throughout StackOverflow with deeply conflicting information - some of which say that you just need MP4 now, others say, MP4 and WEBM are enough, and then finally many say that you need all three (although many of those article are 10 years old).

  


  W3 suggests that either MP4 or WEBM alone would have universal support (Even though I found a 2011 article from Google saying that they would be removing support for MP4/H.264). Wikipedia paints a more complicated picture (as well as listing that Google Chrome does indeed support MP4/H.264). Azure Media services ONLY seems to allow output in MP4, which would suggest to me that MP4 must have widespread compatibility.

  


  Also see Example 1, Example 2, Example 3.

  


  Is there any definitive information on what video types to include in an HTML5 video player to achieve widespread compatibility ?

  


  Background : I am building a Content Management Platform that allows uploading videos. When a new video is uploaded, a conversion process kicks off to convert the video into the required formats. This takes time and CPU/Memory, so if it is possible I would like to convert uploaded videos into as few formats as possible.

  


  p.s. This question HAS been asked before, however, the fundamentals of playing video on the web continually evolve and most of the answers out there have become irrelevant.

  


• WMA Lossless and ProRes Encoder

  4 mars 2012, par Multimedia Mike — General

  The projects (FFmpeg / Libav) just got a WMA lossless decoder. For those keeping score, this means that there are open source methods for decoding every single one of Microsoft’s proprietary audio codecs (Windows Media Audio, or WMA) : WMA v1, WMA v2, WMA9/Pro, WMA Voice, and now WMA lossless. Currently, it’s only advertised to decode 16-bit audio (no 24-bit). Also, when I first tried it a few days ago, it didn’t decode the very end of the single sample file I concocted many years ago (luckynight.wma). But that might be cleared up by now.

  Some other recent developments in the projects that I wanted to call out : An encoder for the Apple ProRes encoder from Kostya ; XWD (X window dump) image decoding and encoding from Paul B. Mahol ; a Sun rasterfile encoder from Aneesh Dogra.

  And then there’s the new playback system for CDXL files, also courtesy of Paul B. Mahol. I wasn’t familiar with this format until I wrote this post, which is surprising, given the format’s vintage. This was a CD-ROM FMV format favored for Amiga computers. Here it is in all its 160x120x10fps glory :

  
  
  

  That’s the amigaball.cdxl sample available in the repository. The sample is 3835910 bytes large and plays for about 24 seconds. This yields a data rate of about 159 kbytes/second. So, yeah, single-speed CD-ROM FMV.

• Evolution #4148 : Augmenter la largeur de l’espace privé

  13 juin 2018, par tcharlss (*´_ゝ｀)

  Super nicod_, merci pour les remarques et le boulot :)

  Alors concernant la largeur, 1200px ce serait déjà beaucoup mieux.
  Mais pour ma part je pense que du 100% serait toujours la meilleur option. Au début ça fait un peu bizarre je le concède, mais on s’y fait vite et c’est dur de revenir sur une largeur fixe après. Pour les tableaux / listes d’objets par exemple ça devient vite indispensable. Le menu ne me pose pas de problème non plus : on comprend que les items sont alignés à gauche.

  Il y a bien certains contenus qui doivent être limité en largeur pour avoir 80 caractères par ligne c’est vrai, mais il s’agit de quelques blocs à identifier, et ça reste valable quelque soit la largeur globale de l’interface.
  Pour l’instant je ne vois que 2 blocs concernés : le #wysiwyg et les formulaires d’édition.
  Donc mon constat c’est : à partir du moment où on limite la largeur de certains blocs qui contiennent du texte afin que ça reste lisible, pourquoi limiter arbitrairement la largeur globale de l’interface ?
  Dans le plugin privé fluide, seul le #wysiwyg est ciblé pour l’instant. Attention il reste aussi des petits problèmes à régler dans certains cas, cf. capture d’écran.

  Pour comparaison, avec RastaPopoulos on avait installé une floppée de CMS pour étudier leurs interfaces au moment où on s’intéressait au sujet, et ils ont tous une largeur 100%.
  Je ne dis pas qu’il faut suivre bêtement ce que font les autres, mais ça donne des exemples concrets de choix de layouts qui fonctionnent.

  Sur la question de rendre cette largeur configurable, je ne suis pas très chaud. C’est exactement pour ça que j’avais fait le plugin privé fluide dans mon coin alors qu’il existe déjà le plugin d’Ybbet : je pense que l’interface doit être d’office adaptée à tous les écrans, sans rien à configurer. Aucune envie d’avoir à configurer ça sur chaque nouvelle instance de SPIP qu’on déploie :p

  Du coup on écrivant tout ça, je verrais finalement la chose comme ça :

  • Largeur globale 100%
  • Supprimer carrément la préférence utilisateur « taille de l’écran »
  • Jusqu’à 1200px : 2 colonnes (#navigation + #extra | #contenu)
  • Au-delà : 3 colonnes (#navigation | #contenu | #extra)

  Du coup en écran large on aurait toujours 3 colonnes et ça équilibre un peu plus.
  Et plutôt que du flex, je pense qu’on pourrait partir directement sur du css grid, avec un bête fallback en float pour les vieux navigateurs.
  Parceque du coup je ne vois pas comment mettre la colonne #extra soit en dessous de #navigation, soit à droite de #contenu juste avec du flex.