Recherche avancée

Sur d’autres sites (8131)

• record desktop save every 30 minutes

  31 mars 2014, par Maged E William

  here is my question that related to the same problem :

  better way to record desktop via ffmpeg

  I have this command : ffmpeg -f dshow -i video="screen-capture-recorder" -r 30 -t 10 E:\test01.flv

  And i am happy with it, but i wonder if i can make it save every 30 minutes so if the power went off i only loses the last 30 minutes.

  I use C# to launch and hide ffmpeg cmd, so i wonder how to make it save to the same test01.flv every 30 minutes ?

• FFmpeg process killed when press poweroff button

  11 avril 2018, par dastan

  I am using the WritingMinds/ffmpeg-android-java library for ffmpeg. When I press the Power button of Asus T00J (4.4), the ffmpeg process is canceled. How can I prevent process to being killed ?

  process = shellCommand.run(cmd);

  The only solution I have in my mind is to recompile ffmpeg with all supported libraries in the shared library format (.so) instead of the executable binary and write JNI to access the ffmpeg main method. But it will take so much time. So, I am looking for alternative solutions.

• imdct15 : replace the FFT with a faster PFA FFT algorithm

  4 janvier 2017, par Rostislav Pehlivanov

  imdct15 : replace the FFT with a faster PFA FFT algorithm
  This commit replaces the current inefficient non-power-of-two FFT with a
  
  much faster FFT based on the Prime Factor Algorithm.
  
  Although it is already much faster than the old algorithm without SIMD,
  
  the new algorithm makes use of the already very throughouly SIMD’d power
  
  of two FFT, which improves performance even more across all platforms
  
  which we have SIMD support for.
  Most of the work was done by Peter Barfuss, who passed the code to me to
  
  implement into the iMDCT and the current codebase. The code for a
  
  5-point and 15-point FFT was derived from the previous implementation,
  
  although it was optimized and simplified, which will make its future
  
  SIMD easier. The 15-point FFT is currently using 6% of the current
  
  overall decoder overhead.
  The FFT can now easily be used as a forward transform by simply not
  
  multiplying the 5-point FFT’s imaginary component by -1 (which comes
  
  from the fact that changing the complex exponential’s angle by -1 also
  
  changes the output by that) and by multiplying the "theta" angle of the
  
  main exptab by -1. Hence the deliberately left multiplication by -1 at
  
  the end.
  FATE passes, and performance reports on other platforms/CPUs are
  
  welcome.
  Performance comparisons :
  iMDCT, PFA :
  
  101127 decicycles in speed,   32765 runs,      3 skips
  
  iMDCT, Old :
  
  211022 decicycles in speed,   32768 runs,      0 skips
  Standalone FFT, 300000 transforms of size 960 :
  
      PFA        Old FFT     kiss_fft    libfftw3f
  
      3.659695s, 15.726912s, 13.300789s, 1.182222s
  Being only 3x slower than libfftw3f is a big achievement by itself.
  There appears to be something capping the performance in the iMDCT side
  
  of things, possibly during the pre-stage reindexing. However, it is
  
  certainly fast enough for now.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/imdct15.c
  • [DH] libavcodec/imdct15.h