Recherche avancée

Sur d’autres sites (8670)

• avutil/mem : limit alignment to maximum simd align

  3 décembre 2023, par Timo Rothenpieler

  avutil/mem : limit alignment to maximum simd align
  FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
  
  which then end up heap-allocated.
  
  By declaring any variable in a struct, or tree of structs, to be 32 byte
  
  aligned, it allows the compiler to safely assume the entire struct
  
  itself is also 32 byte aligned.
  This might make the compiler emit code which straight up crashes or
  
  misbehaves in other ways, and at least in one instances is now
  
  documented to actually do (see ticket 10549 on trac).
  
  The issue there is that an unrelated variable in SingleChannelElement is
  
  declared to have an alignment of 32 bytes. So if the compiler does a copy
  
  in decode_cpe() with avx instructions, but ffmpeg is built with
  
  — disable-avx, this results in a crash, since the memory is only 16 byte
  
  aligned.
  Mind you, even if the compiler does not emit avx instructions, the code
  
  is still invalid and could misbehave. It just happens not to. Declaring
  
  any variable in a struct with a 32 byte alignment promises 32 byte
  
  alignment of the whole struct to the compiler.
  This patch limits the maximum alignment to the maximum possible simd
  
  alignment according to configure.
  
  While not perfect, it at the very least gets rid of a lot of UB, by
  
  matching up the maximum DECLARE_ALIGNED value with the alignment of heap
  
  allocations done by lavu.
  

  • [DH] libavutil/mem.c
  • [DH] libavutil/mem_internal.h

• avutil/mem : limit alignment to maximum simd align

  3 décembre 2023, par Timo Rothenpieler

  avutil/mem : limit alignment to maximum simd align
  FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
  
  which then end up heap-allocated.
  
  By declaring any variable in a struct, or tree of structs, to be 32 byte
  
  aligned, it allows the compiler to safely assume the entire struct
  
  itself is also 32 byte aligned.
  This might make the compiler emit code which straight up crashes or
  
  misbehaves in other ways, and at least in one instances is now
  
  documented to actually do (see ticket 10549 on trac).
  
  The issue there is that an unrelated variable in SingleChannelElement is
  
  declared to have an alignment of 32 bytes. So if the compiler does a copy
  
  in decode_cpe() with avx instructions, but ffmpeg is built with
  
  — disable-avx, this results in a crash, since the memory is only 16 byte
  
  aligned.
  Mind you, even if the compiler does not emit avx instructions, the code
  
  is still invalid and could misbehave. It just happens not to. Declaring
  
  any variable in a struct with a 32 byte alignment promises 32 byte
  
  alignment of the whole struct to the compiler.
  This patch limits the maximum alignment to the maximum possible simd
  
  alignment according to configure.
  
  While not perfect, it at the very least gets rid of a lot of UB, by
  
  matching up the maximum DECLARE_ALIGNED value with the alignment of heap
  
  allocations done by lavu.
  

  • [DH] libavutil/mem.c
  • [DH] libavutil/mem_internal.h

• How to optimize FFMPEG with pipe and memory reuse in Tide SDK

  7 janvier 2014, par Vincent Duprez

  Im running into an speed optimization issue. Im building a video cut tool in web technologies on desktop with TideSDK. On of the tools has a timeline with a position slider

  basically, whenever the slider moves, (using jquery UI), I get the position, translate this into a timecode and asks FFMPEG to encode to a file, when a get the finished event, I simply update the background-image attribute of the 'viewer' to this file. The file is located in some temporary folder.

  The thing is, it is just a bit too slow. Usable, but slow (approx 2 fps on a High end Computer)
  I think there are 2 bottlenecks on this strategy :
   Writing ffmpeg output to a file & reading back in css
   repeatedly loading the same movie file in ffmpeg

  This is the code executed on each move (var timecode is the calculated timecode based on the pointer position)

  var cmd = [FFMPEG];
  
  cmd.push('-y'); //overwrite existing files
  
  cmd.push('-ss',timecode); //CUE position
  
  cmd.push('-i',input); //input file
  
  cmd.push('-f','image2'); //output format
  
  cmd.push('-vframes','1'); //number of images to render
  
  cmd.push(Ti.API.Application.getDataPath( )+"/encoderframe.jpg"); //output file
  
  
  
  var makeframe = Ti.Process.createProcess(cmd);
  
  makeframe.setOnReadLine(function(data){ /*console.log(data);*/ });
  
  var time = new Date().getTime();
  
  makeframe.setOnExit(function(){ ffmpegrunning = false;  $('#videoframe').css('background-image','url(file://'+Ti.API.Application.getDataPath( ).replace(" ","%20")+'/encoderframe.jpg?'+time+')');     });
  
  makeframe.launch();

  Basically, this repeatedly asks the same Command :

  ffmpeg -y -ss 00:00:01.04 -i /somepath/somevideo.mov -f image2 -vframes 1 /path/to/output/encoderframe204.jpg

  How can I optimize this code, Pipe to output straight to css background with Base64 data, or reuse loaded memory file in ffmpeg. ?

  Thanks !