Recherche avancée

Sur d’autres sites (9868)

• trying to use fluent-ffpmeg on raspberry pi

  3 septembre 2018, par cdoern

  I am trying to use fluent ffmpeg to make a h264 file into an mp4 file. However, installing regular ffmpeg did not work since ti downloaded a very old version onto my pi. through some research i stumbled upon an ffmpeg installer on npm that installers a newer version and allows you to use it : https://www.npmjs.com/package/@ffmpeg-installer/ffmpeg however, when incorporating this into my project, PM2, the process manager I am using to run my files, throws a very stranger error :

  err._length = err.length;
TypeError: Cannot create property '_length' on string 'Unsupported platform/architecture: linux-arm

  below is my code for converting the file

  const ffmpegPath = require('@ffmpeg-installer/ffmpeg').path;
  
  var ffmpeg = require('fluent-ffmpeg');
  
  ffmpeg.setFfmpegPath(ffmpegPath);
  
  ffmpeg('/home/pi/Videos/video.h264').format('mp4');
  
  ffmpeg.on('error', function(err) {
  
    console.log('an error happened: ' + err.message);
  
  })
  
  // save to file
  
  ffmpeg.save('/home/pi/Videos/testmovie.mp4');

• ffmpeg : memory not freed on multi-threaded decoding

  31 mai 2020, par toby_e

  I am developing a video player based on the ffmpeg libraries and have run into a rather strange memory increase or failure to decrease memory when unloading a video file. My code is based on various examples of demuxing, decoding and scaling video and audio frames - but with the excecption that i have put each of these steps into seperate threads to avoid waiting for time-consuming calls. Everything works perfectly, but Visual Studio shows that Process Memory does not decrease when i call the various avclose and avfree calls. My Windows task manager confirms these memory increases that continue into the gigabyes !

  



  My player is roughly made up by two clases with the following calls to the ffmpeg libraries :

  



  —

  



  READER :

  



  Open (on main thread) : avformat_open_input(), avformat_find_stream_info()

  



  Read (on seperate thread) : av_read_frame()

  



  Close (on main thrad) : avformat_close_input()

  



  DECODER :

  



  Open (on main thread) : avcodec_find_decoder(), avcodec_alloc_context3(), avcodec_parameters_to_context(), avcodec_open2()

  



  Decode (on seperate thread) : avcodec_send_packet(), avcodec_receive_frame()

  



  Close (on main thread) : avcodec_free_context()

  



  —

  



  Is threre any issues with opening/closing on the main thread and reading/deconding on other threads ?

  


• stream_encoder : Improve selection of residual accumulator width

  19 juin 2014, par Miroslav Lichvar

  stream_encoder : Improve selection of residual accumulator width
  In the precompute_partition_info_sums_ function, instead of selecting
  
  64-bit accumulator when the signal bps is larger than 16, revert to the
  
  original approach based on partition size, but make room for few extra
  
  bits to not overflow with unusual signals where the average residual
  
  magnitude may be larger than bps.
  It slightly improves the performance with standard encoding levels and
  
  16-bit files as the 17-bit side channel can still be processed with the
  
  32-bit accumulator and correctly selects the 64-bit accumulator with
  
  very large 16-bit partitions.
  This is related to commits 6f7ec60c and 187e596e.
  Signed-off-by : Erik de Castro Lopo <erikd@mega-nerd.com>
  

  • [DH] src/libFLAC/include/private/stream_encoder.h
  • [DH] src/libFLAC/stream_encoder.c
  • [DH] src/libFLAC/stream_encoder_intrin_sse2.c
  • [DH] src/libFLAC/stream_encoder_intrin_ssse3.c