Recherche avancée

Sur d’autres sites (10172)

• Fast movie creation using MATLAB and ffmpeg

  24 février 2018, par hyiltiz

  I have some time series data that I would like to create into movies. The data could be 2D (about 500x10000) or 3D (500x500x10000). For 2D data, the movie frames are simply line plot using plot, and for 3D data, we can use surf, imagesc, contour etc. Then we create a video file using these frames in MATLAB, then compress the video file using ffmpeg.

  To do it fast, one would try not to render all the images to display, nor save the data to disk then read it back again during the process. Usually, one would use getframe or VideoWriter to create movie in MATLAB, but they seem to easily get tricky if one tries not to display the figures to screen. Some even suggest plotting in hidden figures, then saving them as images to disk as .png files, then compress them using ffmpeg (e.g. with x265 encoder into .mp4). However, saving the output of imagesc in my iMac took 3.5s the first time, then 0.5s after. I also find it not fast enough to save so many files to disk only to ask ffmpeg to read them again. One could hardcopy the data as this suggests, but I am not sure whether it works regardless of the plotting method (e.g. plot, surf etc.), and how one would transfer data over to ffmpeg with minimal disk access.

  This is similiar to this, but immovie is too slow. This post 3 is similar, but advocates writing images to disk then reading them (slow IO).

• Rails ActionController::Live - Sends everything at once instead of async

  28 janvier 2016, par Michael B

  I have an issue with rails ActionController::Live

  In the end I want to show the progress of FFMPEG to the user, but for now I want to get this minimal example running :

  Rails media_controller.rb :

  class MediaController < ApplicationController
  
    include ActionController::Live
  
  
  
    def stream
  
      puts "stream function loaded"
  
  
  
        response.headers['Content-Type'] = 'text/event-stream'
  
        i = 0
  
        begin
  
          response.stream.write "data: 1\n\n"
  
          sleep 0.5
  
          i += 1
  
          puts "response... data: " + i.to_s
  
        end while i < 10
  
      response.stream.close
  
    end
  
  end

  Javascript :

  source = new EventSource("/test/0");
  
  source.addEventListener("message", function(response) {
  
    // Do something with response.data
  
    console.log('I have received a response from the server: ' + response);
  
  }, false);

  When I navigate to the site, there are no JavaScript Errors showing. As soon as I navigate to the site, the "stream"-Action of the MediaController gets successfully called. I can verify this, by looking at the Server-Console. It gives me the following output. After every response line, there is a 500ms delay, like expected :

  stream function loaded
  
  response... data: 1
  
  response... data: 2
  
  response... data: 3
  
  response... data: 4
  
  response... data: 5
  
  response... data: 6
  
  response... data: 7
  
  response... data: 8
  
  response... data: 9
  
  response... data: 10
  
  Completed 200 OK in 5005ms (ActiveRecord: 0.8ms)

  On the JavaScript Side, it gives me the following Output :

  (10x) I have received a response from the server: [object MessageEvent]

  But the problem is here, that it sends all these 10 Messages from the server after 5 seconds at the same time ! The expected behavior however is, that it should send me 1 message every 0.5 seconds !

  So what am I doing wrong here ? Where is the error ?

  

• Evolution #4753 (Nouveau) : Styles du privé : listes d’objets (suite des boîtes et des formulaires)

  30 avril 2021

  Les boîtes et les formulaires ont été visuellement « raccordés » ensembles.
  Je pense que logiquement les listes d’objets devraient suivre.
  En fait ce sont 3 variations d’un même composant : une boîte avec entête, corps et pied.

  Pour les listes on peut séparer la question en 2 aspects :

  1) L’emballage extérieur¶

  Là il s’agirait de reprendre les choix graphiques propres à « l’emballage extérieur » des boîtes et formulaires : bordure, arrondi, espacements.
  Exemple sur l’image suivant où les 3 sont visibles (nb : ceux en colonne sont automatiquement « ressérés », d’où la différence de padding etc.)

  

  Après en fonction de l’un ou de l’autre, il y aura peut-être lieu d’ajuster le padding ou la taille du titre. Mais pour l’instant ce sont ceux en place.

  2) L’intérieur¶

  Ensuite je propose de procéder à quelques ajustements à l’intérieur de ces listes.
  Je pense que certains choix ont été faits pour s’accommoder du manque de place en largeur à l’époque, et ne sont plus nécessaires maintenant.

  Pour me faire un idée de ce qui fonctionnerait le mieux, et comprendre les détails visuels qui me gênaient un peu, j’ai parcouru quelques articles de recommandations sur l’ergonomie des data tables.
  Alors ils traitent plutot des fonctionnalités de ces tables dans leur ensemble, mais il y a aussi quelques guidelines visuelles intéressantes.

  • https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1e
  • https://medium.com/nextux/design-better-data-tables-4ecc99d23356
  • https://www.uxbooth.com/articles/designing-user-friendly-data-tables/
  • https://uxdesign.cc/lets-design-data-tables-bf065a60e588

  Je retiens quelques règles simples :

  • Des espacements suffisants et consistants (le padding quoi)
  • Une taille de police identique partout (au moins dans le tbody). C’est fatiguant pour l’oeil et moins lisible quand on passe sans arrêt d’un taille de police à l’autre sur une même ligne. Et je ne suis pas sûr qu’il y ait forcément besoin de gras pour certains éléments comme les titres ou autres.
  • À quelques exceptions près (id, picto), pas de largeur fixes sur les colonnes, laisser faire le navigateur.

  Donc voilà, c’est pas grand chose à ajuster non plus.
  Les colonnes des tables ont des classes .importante et .secondaire.
  À mon avis elle ne devraient plus avoir d’incidence en vue « normale », mais juste décider quelles colonnes afficher et masquer en vue réduite, dans les colonnes ou ailleurs.

  Donc dans les grandes lignes ça donnerait quelques chose comme ça (juste une maquette) :

  

  3) Détails¶

  Enfin pour ces 3 composants, je propose qu’il y ait une classe modificatrice commune pour produire un affichage compact, c’est à dire ressérer tout le contenu.
  Cette classe serait automatiquement appliquée dans les colonnes.

  Ça pourrait être « compact », mais sur d’autres composants pour varier les tailles je suis parti sur mini / large. Donc mini aussi ?