Recherche avancée

Sur d’autres sites (9221)

• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  10 février 2021

  Les grands principes de séparation entre la forme et le contenu, oui ok d’accord.

  Mais t’as bien vu que l’objet de cette proposition, c’est justement d’accepter de faire un compromis pour simplifier la vie de tout le monde : à la fois pour maintenir le truc et à la fois quand on veut les utiliser dans le core et les plugins.
  Le constat de départ je rappelle, c’est qu’actuellement c’est bien des classes sémantiques-tout-ça, mais au prix de circonvolutions hypers lourdes dans le css (t’as jeté un coup d’oeil à boutons.css ?).

  Si on est pas content des quelques icônes qui peuvent se ballader d’office dans certains formulaires ou bouts de squelettes, on règle ça en 1 ligne de CSS hein : .icone-spip { display: none }
  Ou même si on veut les garder et les surcharger : .icone-spip svg { display: none } et voilà.
  Ça me semble pas un très gros prix à payer.

• ffmpeg concatenate two videos, unexpectedly changes the first second(s) of 2nd video

  29 juin 2019, par Roy

  I used ffmpeg to concatenate two videos of my game play recordings. I wrote a list.txt file which lists the two files :

  list.txt:
  
  file 2019~06~28_~_Game_1_~_Part_2.mp4
  
  file 2019~06~28_~_Game_1_~_Part_3.mp4

  I then run ffmpeg to concat them :

  ffmpeg -safe 0 -f concat -i list.txt -c copy "output.mp4"

  However, the resulting video seems to be skipping frames (or going through them really quickly) at the first second(s) of the second video, causing the perception of the motion suddenly fast-forwarded.

  The two videos were recorded by the same game video recorder "GeForce Experience" in one game session. They should match smoothly when concatenated.

  Here is the output of ffmpeg :

  ffmpeg version 3.4.1 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 7.2.0 (GCC)
  
    configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx
  
    libavutil      55. 78.100 / 55. 78.100
  
    libavcodec     57.107.100 / 57.107.100
  
    libavformat    57. 83.100 / 57. 83.100
  
    libavdevice    57. 10.100 / 57. 10.100
  
    libavfilter     6.107.100 /  6.107.100
  
    libswscale      4.  8.100 /  4.  8.100
  
    libswresample   2.  9.100 /  2.  9.100
  
    libpostproc    54.  7.100 / 54.  7.100
  
  [mov,mp4,m4a,3gp,3g2,mj2 @ 000001600bbdb5e0] Auto-inserting h264_mp4toannexb bitstream filter
  
  Input #0, concat, from 'list.txt':
  
    Duration: N/A, start: 0.000000, bitrate: 24674 kb/s
  
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt470m), 1920x1080 [SAR 1:1 DAR 16:9], 24479 kb/s, 59.69 fps, 60 tbr, 90k tbn, 120 tbc
  
      Metadata:
  
        creation_time   : 2019-06-29T04:43:18.000000Z
  
        handler_name    : VideoHandle
  
      Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 195 kb/s
  
      Metadata:
  
        creation_time   : 2019-06-29T04:43:18.000000Z
  
        handler_name    : SoundHandle
  
  File 'output.mp4' already exists. Overwrite ? [y/N] y
  
  Output #0, mp4, to 'output.mp4':
  
    Metadata:
  
      encoder         : Lavf57.83.100
  
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt470m), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 24479 kb/s, 59.69 fps, 60 tbr, 90k tbn, 90k tbc
  
      Metadata:
  
        creation_time   : 2019-06-29T04:43:18.000000Z
  
        handler_name    : VideoHandle
  
      Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 195 kb/s
  
      Metadata:
  
        creation_time   : 2019-06-29T04:43:18.000000Z
  
        handler_name    : SoundHandle
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
    Stream #0:1 -> #0:1 (copy)
  
  Press [q] to stop, [?] for help
  
  [mov,mp4,m4a,3gp,3g2,mj2 @ 000001600bbdb5e0] Auto-inserting h264_mp4toannexb bitstream filter
  
  frame= 7405 fps=0.0 q=-1.0 Lsize=  221175kB time=00:02:03.63 bitrate=14655.4kbits/s speed= 157x
  
  video:218137kB audio:2862kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.079741%

  In particular, I don’t know what does "Auto-inserting h254_mp4toannexb bitstream filter" mean. Did this caused the unexpected change ?

• 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 ?