Recherche avancée

Sur d’autres sites (471)

• Anomalie #3281 (En cours) : remarques sur le nouveau thème graphique de la 3.1

  13 août 2016, par b b

  Ha mais non pardon, je pensais qu’on avait intégré les propositions alors que non... J’ouvre de nouveau, mais il serait bien de s’occuper de ce ticket un jour... (parce que là ça commence à dater ^^).

  Pour tenter d’avancer, quelques remarques à propos des propositions de tcharlss :

  formulaires latéraux (fiche d’un objet) : couleurs neutres (bordures et fond), boutons plus lisibles.

  Perso je n’avais même pas remarqué le problème car j’utilise toujours le gris dans le privé. Ça a failli être la couleur par défaut pour la 3.1, mais Arnaud nous a "gentiment" fait remarquer que le gris n’est une couleur... Du coup, je ne suis pas certain que ta proposition lui fera plaisir, par contre ça le fera certainement réagir :p

  Pour les boutons plus lisibles, je crois bien qu’on a augmenter le contraste de ce côté, ça semble bon de mon côté à ce jour.

  - fiche d’un objet : pas d’ombre portée, remplacée par une simple bordure.

  Perso avec ou sans je m’en cogne un peu, mais je trouve plus en accord avec le reste du thème de ne pas utiliser d’ombre portée. Je crois bien que c’est la seule présente dans tout le privé, elle fait un peu tâche du coup. +1 donc :)

  - marge entre le contenu éditorial d’un objet et les formulaires de date etc.

  Ce point semble aussi réglé maintenant.

  - bandeaux identité et outils : couleur de fond identique.

  J’ai un gros doute sur ce point, en effet, si on utilise la "non couleur" gris (^^) et qu’on applique le gris clair du premier bandeau au second (#f4f4f4), la séparation visuelle entre la zone haute et la zone de contenu est beaucoup moins perceptible.

  D’autres avis ?

• Anomalie #4500 : L’attribut meta de paquet.xml n’est pas traité correctement

  6 juin 2020, par Eric Lupinacci

  Oui, c’est aussi une question qu’on s’est posé avec Cédric quand je lui ai soumis le patch de la PR.
  Je n’ai pas rajouté de feature !
  C’est juste que cette question à 10 ans de retard et que l’implémentation actuelle est vérolée.

  Dans tout le code aujourd’hui on trimbale la table meta comme argument mais il y a des bugs et des manques qui font que ça ne marche pas du tout.
  Ce qui est étonnant d’ailleurs c’est qu’on ne propage plus cet argument dans le prototype de _upgrade et _vider_tables comme on devrait et je pense que ça nous a fait oublier cette feature.

  En fait, pour stocker des données de configuration dans une autre table meta l’API config le fait très bien et elle sait même créer et supprimer la table automatiquement.
  Si on devait se limiter à ça, je préconise juste de prendre les modifications que j’ai faites dans inc/config.php et dans la fonction supprimer_table_meta().
  Maintenant, si on veut pas se casser la tête pour l’instant, on prend tout en le vérifiant parce que j’ai quand même pas mal arrangé certaines fonctions et on laisse sans en faire plus de pub que depuis 10 ans ;-).

  En tout cas, mettre la configuration d’un ensemble de plugins dans une autre table c’est quand même pas mal, parce que nos plugins actuels ne sont pas tous nickel coté désinstallation et on se retrouve souvent avec une table meta encombrée.
  En fait je trouve qu’on aurait du séparer la config de SPIP de celle des autres plugins.
  Et dans ce cadre c’est vrai que la meta _base_version est une meta SPIP et pas vraiment du plugin lui-même, donc je suis d’accord avec vous.
  C’est pourquoi d’ailleurs il m’a toujours semblé bizarre de devoir faire un effacer_meta() de cette meta dans chaque fonction _vider_tables().

  Donc que décide-t-on ?

• Is it possible to grab a frame from a video stream and save it as png in another stream with ffmpeg ?

  9 février 2020, par Lázár Zsolt

  I am trying to use FFMpeg with System.IO.Process to convert a seek-able in-memory video stream into a thumbnail. Piping the thumbnail out through stdout isn’t a problem, but piping in the video is tricky.

  My current code copies the entire video stream into stdin, which is very slow and unnecessary, because ffmpeg obviously doesn’t need the entire file to get the first frame. Writing the stream to the file system and specifying its path as an input argument is also very slow, because the source video can be several gigabytes.

  I have tried accomplishing this using existing libraries, such as AForge, FFMpegCore, Xabe.FFMpeg, xFFMpeg.NET and Accord.FFMPEG.Video, but unfortunately they can only work with actual files, not streams, and my input video is not available as a file.

  The stream object that supplies the video fully implements seeking and random access reading functionalities, just like a file stream, so there is literally no valid reason for this to not be possible, besides the limitations of the APIs (or my knowledge).

  As a last resort, I could use the Dokan.NET filesystem driver to expose the video stream as a virtual file so ffmpeg can read it, but that would be an extreme overkill and I’m looking for a better solution.

  Below is my current code. For the sake of simplicity, I am emulating the input video stream with a FileStream.

  var process = new Process();
  
  process.StartInfo.FileName = "ffmpeg.exe";
  
  process.StartInfo.Arguments = "-i - -ss 00:00:01 -vframes 1 -q:v 2 -c:v png -f image2pipe -";
  
  process.StartInfo.RedirectStandardInput = true;
  
  process.StartInfo.RedirectStandardOutput = true;
  
  process.StartInfo.UseShellExecute = false;
  
  process.StartInfo.CreateNoWindow = true;
  
  process.Start();
  
  
  
  var stream = File.OpenRead("test.mp4");
  
  stream.CopyTo(process.StandardInput.BaseStream);
  
  process.StandardInput.BaseStream.Flush();
  
  process.StandardInput.BaseStream.Close();
  
  
  
  var stream2 = File.Create("test.png");
  
  var buffer = new byte[4096];
  
  int read;
  
  while((read = process.StandardOutput.BaseStream.Read(buffer, 0, buffer.Length)) > 0)
  
      stream2.Write(buffer, 0, read);

  EDIT :
  It might be useful to clarify what kind of data does the input stream contain. It is basically a video file that can be in any commonly used format (avi, mp4, mov, ts, mkv, wmv,...). The extension of the video (as if it was a file) is also known.