Recherche avancée

Sur d’autres sites (3504)

• Muxing multiple JPEG into a JXL animation

  11 août 2023, par malat

  Using ffmpeg I can mux multiple JPEG into a M-JPEG container without any loss since it is a just a plain bitstream copy :

  


  ffmpeg -framerate 30 -i input%03d.jpg -codec copy output.mjpeg


  


  Recently linux distributions started to offer JPEG-XL command line tools. I can now recode (lossless recompression) of JPEG into JXL :

  


  % file input.jpg
input.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 1016x708, components 3
% cjxl input.jpg output.jxl
% djxl output.jxl output.jpg
% md5sum input.jpg output.jpg
bea9e9c74e3580f6196ba9ac21509652  input.jpg
bea9e9c74e3580f6196ba9ac21509652  output.jpg


  


  However I fail to understand how to create a JXL animation (more than one JPEG) ?

  


  Eg :

  


  % ffmpeg -framerate 30 -i input%03d.jpg -codec copy output.jxl
[...]
[image2 @ 0x55c22e680040] The specified filename 'output.jxl' does not contain an image sequence pattern or a pattern is invalid.
[image2 @ 0x55c22e680040] Use a pattern such as %03d for an image sequence or use the -update option (with -frames:v 1 if needed) to write a single image.
[image2 @ 0x55c22e680040] Cannot write more than one file with the same name. Are you missing the -update option or a sequence pattern?
av_interleaved_write_frame(): Invalid argument
frame=    2 fps=0.0 q=-1.0 Lsize=N/A time=00:00:00.06 bitrate=N/A speed= 223x
video:224kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Conversion failed!


  


  Or :

  


  % cjxl input*.jpg output.jxl
Unknown argument: input002.jpg
Use 'cjxl -h' for more information


  


• lavc/aacpsdsp : fix clobber on RISC-V LP64D/ILP32D

  6 octobre 2022, par Rémi Denis-Courmont

  lavc/aacpsdsp : fix clobber on RISC-V LP64D/ILP32D
  Although the DSP function only uses single precision from RISC-V F, the
  
  caller may leave double precision values in the spilled registers if the
  
  calling convention supports double precision hardware floats. Then, we
  
  need to save and restore FS registers as double precision.
  Conversely, we do not need to save anything at all if an integer calling
  
  convention is in use. However we can assume that single precision floats
  
  are supported, since the Zve32f extension implies the F extension.
  
  So for the sake of simplicity, we always save at least single precision
  
  values.
  In theory, we should even save quadruple precision values if the LP64Q
  
  ABI is in use. I have yet to see a compiler that supports it though.
  

  • [DH] libavcodec/riscv/aacpsdsp_rvv.S

• lavu/cpu : CPU flags for the RISC-V Vector extension

  26 septembre 2022, par Rémi Denis-Courmont

  lavu/cpu : CPU flags for the RISC-V Vector extension
  RVV defines a total of 12 different extensions, including :
   5 different instruction subsets :
  
    - Zve32x : 8-, 16- and 32-bit integers,
  
    - Zve32f : Zve32x plus single precision floats,
  
    - Zve64x : Zve32x plus 64-bit integers,
  
    - Zve64f : Zve32f plus Zve64x,
  
    - Zve64d : Zve64f plus double precision floats.
   6 different vector lengths :
  
    - Zvl32b (embedded only),
  
    - Zvl64b (embedded only),
  
    - Zvl128b,
  
    - Zvl256b,
  
    - Zvl512b,
  
    - Zvl1024b,
   and the V extension proper : equivalent to Zve64f and Zvl128b.
  In total, there are 6 different possible sets of supported instructions
  
  (including the empty set), but for convenience we allocate one bit for
  
  each type sets : up-to-32-bit ints (RVV_I32), floats (RVV_F32),
  
  64-bit ints (RVV_I64) and doubles (RVV_F64).
  Whence the vector size is needed, it can be retrieved by reading the
  
  unprivileged read-only vlenb CSR. This should probably be a separate
  
  helper macro if needed at a later point.
  

  • [DH] libavutil/cpu.c
  • [DH] libavutil/cpu.h
  • [DH] libavutil/riscv/cpu.c
  • [DH] tests/checkasm/checkasm.c