Sur d’autres sites (12589)

• Webm video files recorded on Chrome Mobile cannot be converted to MP4

  7 juillet 2022, par Tobias Kristensen

  I have a website where I record the user's webcam via the MediaRecorder API.
The video stream is created with navigator.mediaDevices.getUserMedia() :

  


  // Create stream
const cameraStream = await navigator.mediaDevices.getUserMedia({ video: 
  { 
    aspectRatio: 1/1, 
    facingMode: 'user',
    width: { min: 360, ideal: 720, max: 1080 },
    height: { min: 360, ideal: 720, max: 1080 },
    deviceId: undefined
  }  
});

// Add stream to videoElement to display a video preview
videoElement.srcObject = cameraStream; 


  


  I then check which mime types are available in the browser and use that info to initialize the MediaRecorder :

  


  const validMimeTypes = [
  "video/webm\;codecs=vp8",
  "video/webm\;codecs=daala",
  "video/webm\;codecs=h264",
  "video/webm",
  "video/mpeg"
];

const getFirstAvailableMimeType = () => {
  for (const mimeType of validMimeTypes) {
    if (MediaRecorder.isTypeSupported(mimeType)) {
      return mimeType;
    }
  }
}

// Initialize Media Recorder
const mediaRecorder = new MediaRecorder(cameraStream, {
  mimeType: getFirstAvailableMimeType(),
});


  


  After I finish recording a video, I upload it to a server and store it on Firebase Storage, so it can be downloaded later.

  


  After downloading a video, I would like to convert it to an MP4 file. I've tried using CloudConvert and HandBrake. Both services have no issues converting videos that were recorded via Chrome on my desktop, but both fail when I try to convert videos recorded via Chrome Mobile on my phone.

  


  When trying to convert the video to MP4 via CloudConvert, the following error is shown :

  


  EBML header parsing failed. /input/import1/69fcceaccc27a0d6eabcb8a65045e87e.webm Invalid data found when processing input


  


  Any ideas how I can resolve this issue ?

  


• Berlin website owners need consent for using Google Analytics

  19 novembre 2019, par Joselyn Khor — Uncategorized

  Website owners in Berlin need consent for using Google Analytics

  According to the Berlin Data Protection Office, if you’re a website owner collecting and sending data to third-party services (like Google Analytics) who are also using that data “for own purpose uses” in Berlin, you are now required to ask for specific consent from visitors in order to collect that information. 

  This means you can only use Google Analytics or similar services once you’ve gotten consent from visitors. In contrast, Matomo does not use information from Cloud or On-Premise users for “own purpose uses”.

  Consent is also needed when keystrokes or mouse movements are recorded. That means you need users to consent to your usage of features like Heatmaps and Session Recordings.

  It’s advised that website owners in Berlin should check their websites for third-party content and tracking mechanisms. If you do use these third-party functions that require consent, you must either get consent or remove the functions. Consent is only effective if the visitor (whose data you’re collecting) is informed and agrees to their data being processed.

  Currently this applies to website owners in Berlin, and should likely be applied for the whole of Germany to be on the safe side.

  Further reading :

  • Learn more about Matomo’s Cloud Data Processing Agreement
  • Read about asking for consent in Matomo
  • To use Matomo Analytics and be compliant with the regulation we recommend you learn how to make Matomo GDPR compliant in 12 steps.

  And learn more about all the features in our GDPR user guide and privacy user guide. You can also learn more about GDPR through our blog posts.

• Evolution #4720 : [css vars] Utiliser nos variables CSS dans le thème de l’espace privé

  27 avril 2021

  Ah oui bien les astuces à base de —spip-is-ltr.

  Pour compléter sur le sujet des propriétés de positionnement, dans le futur, pour avoir le support complet quelque soit la direction (horizontale ou verticale) il faudra définir le writing-mode : https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode
  Valeur qu’il faudrait pouvoir récupérer en fonction du code de langue, donc.
  D’après ce que j’ai compris, en son absence ça se repose sur la direction du document (dir="rtl"), donc c’est bon pour les langues à l’horizontale.

  Bref, on a donc pris un peu d’avance et commencé à utiliser tout de suite des variables CSS.
  Le choix s’est fait un peu tout seul : ça simplifie énormément la tâche, surtout en l’absence de préprocesseur, et ça permet d’unifier et maintenir plus facilement tous les composants.

  Par contre avant de poursuivre, il faudrait peut-être faire un petit point d’étape, voir rédiger des guidelines pour ne pas assister à une hyper-inflation de ces variables, et qu’elles ne soient pas utilisées à tord et à travers dans tous les sens.

  La règle que j’ai suivie jusqu’à présent :

  • Des variables globales --spip-xxx, de portée générale et utilisables partout : couleurs, propriétés de texte, arrondis des blocs, gouttières, etc.
  • Et pour chaque composant, quelques variables qui lui sont propres : --composant-xxx. À quelques exceptions près, elles ne devraient pas être utilisées en dehors. J’essaie de limiter le nombre en général, une dizaine au max (sauf pour les boutons, un cas spécial).

  Enfin, il y a 2 variables globales bien importantes qu’il va falloir mettre au point : ce sont celles qui définissent les gouttières horizontales et verticales. Importantes cas après, chaque composant se basera dessus pour ses propres besoins, et au final on aura des espacements bien harmonisés et facilement contrôlables.

  Il peut s’agit d’une mesure arbitraire, mais en général pour la gouttière horizontale on prend l’équivalent d’une hauteur de ligne, c’est à dire font-size * line-height à la racine du document.
  Je l’ai ajoutée en prévision (spip-spacing-y), sauf que pour l’instant elle est pas trop utilisable : le font-size qu’on reçoit dans l’env est pas celui qui est utilisé sur le body, donc ça fausse toutes les mesures. Le font-size du body est redéfini plusieurs fois d’affilée, c’est le bordel. Bref, encore des choses à mettre au point.