Recherche avancée

Sur d’autres sites (6735)

• FFmpeg cant recognize 3 channels with each 32 bit

  4 avril 2022, par Chryfi

  I am writing the linearized depth buffer of a game to openEXR using FFmpeg. Unfortunately, FFmpeg does not adhere to the openEXR file specification fully (like allowing unsigned integer for one channel) so I am writing one float channel to openEXR, which is put into the green channel with this command -f rawvideo -pix_fmt grayf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr.

  


  The float range is from 0F to 1F and it is linear. I can confirm that the calculation and linearization is correct by testing 16 bit integer (per pixel component) PNG in Blender compositor. The 16 bit integer data is written like this short s = (short) (linearzieDepth(depth) * (Math.pow(2,16) - 1)) whereas for float the linearized value is directly written to OpenEXR without multiplying with a value.

  


  However, when viewing the openEXR file it doesn't have the same "gradient" as the 16 bit png... when viewing them side by side, it appears as if the values near 0 are not linear, and they are not as dark as they should be like in the 16 bit png.
(And yes, I set the image node to linear), and comparing it with 3d tracking data from the game I cant reproduce the depth and cant mask things using the depth buffer where as with the png I can.

  


  How is it possible for a linear float range to turn out so different to a linear integer range in an image ?

  


  UPDATE :

  


  I now write 3 channels to the ffmpeg with this code

  


  float f2 = this.linearizeDepth(depth);

buffer.putFloat(f2);
buffer.putFloat(0);
buffer.putFloat(0);


  


  the byte buffer is of the size width * height * 3 * 4 -> 3 channels with each 4 bytes. The command is now -f rawvideo -pix_fmt gbrpf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr which should mean that the input (byte buffer) is expecting 32 bit floats with 3 channels.

  


  FFmpeg is somehow splitting up channels or whatever... could be a bug, could be my fault ?

  


• Last bytes of AVPacket

  3 avril 2018, par João Gueifão

  I have been experimenting with FFmpeg libav C libraries to open, read and demux a video file with both video and KLV (key-lengh-value) streams. The data stream is built according to the UAS Datalink Local Metadata Set as per the MISB ST 0601.11 standard.
  At the moment I am able to play the video on a window and dump the KLV metadata on the console just fine. I came to realise that whenever I dump the content of a AVPacket on the console, the last 14 bytes are constant, throughout different video files. I was provided a KLV decoder according to that MISB standard, which is working just fine, but ONLY WHEN I REMOVE THOSE last 14 bytes from every AVPacket data array given by FFmpeg.

  My question is : what are those 14 bytes in the first place ? I could not find them in the video file itself. I inspected the raw binary stream at one of the files and could not find those bytes anywhere. That makes me hypothesise that it is FFmpeg that is computing them itself ?

  Further details

  I discovered the following :

  • for a same video file, the value of those 14 bytes never change ;
  • when switching to a different video file, only the first 2 bytes of those 14 final bytes change ;
  • when I dump the content of a AVPacket corresponding to a video frame, those 14 bytes also are very similar.

  Here are two examples of the different 14 byte strings that I got until so far :

  • FC00 0000 01CE 8C4D 9D10 8E25 E9FE
  • BD00 0000 01CE 8C4D 9D10 8E25 E9FE

  As you may see, they are all very similar.

  Below is an example of the dump of an AVPacket::data array on the console. First we can see the the 16-byte Universal Key for this UAS Datalink Local Data Set, followed by the remaining of the packet, finishing with the mysterious 14-byte footer. I provide newlines just for readability.

  06 0E2B 3402 0B01 010E 0103 0101 0000 00
  
  81 F102 0800 04CA 140D 4323 0B03 1545 5352 495F 4D65 7461 6461 7461 5F43 6F6C 6C65 6374 0406 4E39 3738 3236 0502 F86E 0602 119A 0702 ED0B 0A05 4332 3038 420B 000C 000D 043A 841D A40E 04B5 80F4 A10F 0231 C710 0201 8B11 0200 DE12 04CD 0444 4513 04F1 2666 6614 0400 0000 0015 0400 2037 BB16 0200 0017 043A 8562 8718 04B5 7C46 AC19 0223 811A 02FF BA1B 02FF 551C 0200 6F1D 02FF 801E 0200 451F 0200 A820 02FF 9421 0200 7E2F 0100 302A 0101 0102 0101 0304 2F2F 4341 0400 0500 0602 4341 1510 0000 0000 0000 0000 0000 0000 0000 0000 1602 0005 3801 003B 0846 6972 6562 6972 6441 0101 4808 0000 0000 0000 0000 0102 DA78 
  
  FC00 0000 01CE 8C4D 9D10 8E25 E9FE

  I tried to follow the metadata.c example file on FFmpeg source examples, but it was unhelpful, as it only shows how to leverage the decoding of metadata from streams for which FFmpeg was an appropriate metadata codec. Again, in my case, the data stream is structured according to the UAS Datalink Local Metadata Set, and FFmpeg does not provide an appropriate codec.

  Thank you for your help.

• Evolution #4256 (Nouveau) : Faire un signalement des mise à jour de sécu

  24 décembre 2018, par Franck D

  Hello :-)
  Quand un plug reçoit une mise à jour de sécu, l’utilisateur ne le sait pas, car, il n’y a pas de différence "d’affichage" entre une mise à jour de secu et une mise à jour "classique" !
  Résultat, les gens ne font pas forcément la mise à jour, car, il n’y a rien de "percutant" comme info !
  Cela va un peu avec https://core.spip.net/issues/3509 et https://core.spip.net/issues/3017, mais pas complètement non plus, car il ne faudrait même pas y avoir de besoin de lire les logs pour savoir qu’il y a une correction de secu.

  Il faudrait que quand SVP détecte une mise à jour de secu, l’arrière-plan du plug en question sur cette page /ecrire/ ?exec=admin_plugin devienne "rouge" par exemple, voir que le webmestre et les admi reçoivent l’info d’une façon ou d’une autre sans devoir aller sur cette page (mail, popup à la page d’accueil, autre ???)

  Je me demande s’il ne nous manque pas un fichier du type archivelist_secu.txt sur la zone ou SVP regarderait les plugins qui sont dedans avec leur version, nous aurions un affichage du type :
  Nom_du_prefix_du_plugin/Version_du_X_qui_contient_le_problème/Version_du_plugin_sans_problème

  Ce qui donnerait par exemple :
  saisie / version 1.x.x / 1.42.11
  saisie / version 2.x.x / 2.28.0
  saisie / version 3.x.x / 3.11.1
  Franck