Recherche avancée

Sur d’autres sites (10920)

• Feeding raw image bytes into ffmpeg rawvideo fails with Invalid buffer size on linux only

  13 février 2021, par cherouvim

  I have a nodejs program which generates raw (rgb24) image(s), which I then pipe into ffmpeg so it saves as png or mp4. My code looks like this :

  


  const fs = require("fs");
// ...
const outputBuffer = Buffer.alloc(outputPngWidth * 3 * outputPngHeight);
// ... write data into outputBuffer
fs.writeSync(process.stdout.fd, outputBuffer);


  


  I then do the following in CLI :

  


  node generate | ffmpeg -f rawvideo -pixel_format rgb24 -video_size 1000x1000 -i - test.png


  


  Alternatively, if I generate lots of images from my program, I do this to generate the video file :

  


  node generate | ffmpeg -f rawvideo -pixel_format rgb24 -video_size 1000x1000 -r 60 -i - -codec:v libx265 test.mp4


  


  On windows this works flawlessly. On linux (either on Ubuntu 20 VM, or Ubuntu 20 installed directly on a physical machine), it consistently fails with :

  


  pipe:: corrupt input packet in stream 0
[rawvideo @ 0x55f5256c8040] Invalid buffer size, packet size 65536 < expected frame_size 3000000
Error while decoding stream #0:0: Invalid argument


  


  If I split this in 2 phases like so, then it works perfectly on linux as well :

  


  node generate > test.raw
cat test.raw | ffmpeg -f rawvideo -pixel_format rgb24 -video_size 1000x1000 -i - test.png


  


  By looking at the error "packet size 65536 < expected frame_size 3000000" it seems that node's fs.writeSync only sends 65536 bytes at a time, but ffmpeg expects 3000000 bytes (that is 1000 width * 1000 height * 3 channels).

  &#xA;

  If I reduce my image size to something small, e.g 50x50 or 100x100, then it works. As soon as x * y * 3 exceeds 65536, it fails (eg. 160x160 fails with "packet size 65536 < expected frame_size 76800" because 160 * 160 * 3 = 76800).

  &#xA;

  What I've tried so far to solve the issue without luck :

  &#xA;

  &#xA;
  • Force node to spit out the whole buffer at once :

  &#xA;

  &#xA;

  fs.writeSync(process.stdout.fd, outputBuffer, 0, outputBuffer.length);


  &#xA;

  &#xA;
  • All suggestions of Add a big buffer to a pipe between two commands with various linux commands to buffer between node and ffmpeg.

  &#xA;

  • Use Ubuntu 18 instead of 20.

  &#xA;

  • Use node 12 instead of 15.

  &#xA;

  • Figure out a way to change the chunk size in https://nodejs.org/api/fs.html

  &#xA;

  &#xA;

  Is there a way to overcome this ?

  &#xA;

• Evolution #3966 (Nouveau) : Date de création des contenus

  26 juin 2017, par tcharlss (*´_ゝ｀)

  Il n’y a pas longtemps j’ai eu besoin de faire des statistiques éditoriales : on voulait connaître l’évolution du nombre d’articles publiés chaque année.
  Mais les données ne sont pas fiables : les utilisateurs avaient pour habitude de faire des « remises en avant » en changeant la date de publication de vieux articles pour les refaire apparaître en page d’accueil. Donc un article écrit en 2014 mais remis en avant en 2017 se retrouve compté comme ayant été publié en 2017.

  Et c’est valable pour tout les objets éditoriaux en fait : on ne conserve pas leur date de création / 1ère publication.
  Certains objets ont une date de publication, mais elle peut être changée. Et d’autres objets n’ont tout simplement pas de date (hormis maj).

  Donc je me demandais s’il ne serait pas pertinent d’avoir cette information de façon générique pour tous les objets éditoriaux, un champ date_creation par exemple qui serait rempli soit à la création, soit à la 1ère publication, et qui ne bougerait pas ensuite.

  Ci-dessous, un tableau récapitulatif de ce qu’on a actuellement pour les principaux objets.

  Objet	Champ de date	Date pérènne ?
  Articles	date	Non : peut être modifiée manuellement
  Brèves	date_heure	Non : peut être modifiée manuellement
  Rubriques	date	Oui
  Auteurs	X	X
  Mot-clé	X	X
  Groupe de mots-clés	X	X
  Document	date	Oui
  Forum	date_heure	oui
  Pétition	X	X

• Anomalie #4543 : Accessibilité des chargements ajax (live regions)

  22 septembre 2020, par nicod _

  nicod _ a écrit :

  C’est bien ce que je comprends des recos, oui, attribut aria sur le premier résultat et redonner le focus sur cet élément.

  J’ai dit une bêtise : retirer l’attribut aria-live et juste gérer le focus.

  Précisions :

  (D’ailleurs, pour effectuer cela, afin de donner le focus à un élément qui normalement ne le reçoit pas, il faut lui ajouter un attribut tabindex="-1".)
  Enfin, il est vraiment important de voir en contexte leur nécessité, si je reprend l’exemple donné sur le github de la disic, à propos d’un panier d’achats, ce n’est pas aussi simple qu’ils l’ont écrit. Tout va dépendre du comportement global. Exemples, après avoir mis un article dans le panier :

  - je suis redirigé vers la page du panier s’affiche (rechargement de page) > alors pas d’aria-live
  je reste sur ma page produit et une "animation" montre mon article qui va dans le panier où le nombre d’article est incrémenté > là on utilise une live region qui va dire un truc du style "3 articles dans le panier" (ou qui peut être plus précise même : "l’article "x" a été ajouté, vous avez 3 articles dans le panier")
  - le panier s’affiche comme une modale (souvent c’est un panneau à droite de l’écran) -> là non plus, a priori pas d’aria-live nécessaire, comme il y a forcément une gestion du focus à prévoir pour amener l’utilisateur dans la bonne zone, on va donner le focus à un titre du style "votre panier (3 articles)"
  etc.