Recherche avancée

Sur d’autres sites (6206)

• Can the outputFile of MediaRecorder be a named pipe ?

  13 avril 2017, par Harrison

  Following
  Android Camera Capture using FFmpeg
  and
  feed raw yuv frame to ffmpeg with timestamp

  I successfully put raw frames of Android phone camera into a named pipe made by mkfifo, and used ffmpeg to process them and generated a video file.

  But the problem is that by ffmpeg, the encoding is very slow, it can only process 3 5 frames per second. The reason I have to use ffmpeg instead of MediaRecorder is that later I need to use ffmpeg to generate HLS segments and m3u8 file.

  So I have to turn to use native encoder like MediaRecorder and try to set its OutputFile to a named pipe following
  How to use unix pipes in Android

  My code likes this,

  private String pipe = "/data/data/com.example/v_pipe1";
  
  ...
  
  mMediaRecorder.setOutputFile(pipe);
  
  ...
  
  mMediaRecorder.start();

  Also I have a ffmpeg thread to use this pipe as the input.

  But when I call mMediaRecorder.start() ; It will throw java.lang.IllegalStateException. I’ve tried to put ffmpeg thread before or after calling mMediaRecorder.start(), but with the same error.

  I have no idea about this now. Could someone tell me how to solve this ?
  Any suggestions are welcome and appreciated. Thanks.

• Javascript, method chaining, how to realize response in callback ?

  12 avril 2017, par CHBS

  Good afternoon, ladies and gentlemen.
  I write for myself a module on node js, I can not implement the save () function

  module.exports = function(filename, callback){
  
      this.callback = callback(require(filename));
  
      return { 
  
          save: function() {
  
              console.log(this);
  
              //fs.writeFile(filename, 'Hello Node.js');
  
          }
  
      }; 
  
  }
  
  
  
  File('file.json', function(data){
  
      data['blablabla'] = 12345;
  
  }).save();

  How from a callback, to transfer the changed copy of a file in save (), and there already to save it through fs ?
  I’m interested in the implementation of the fluent-ffmpeg function save ()

  ffmpeg('/path/to/file.avi')
  
   .videoCodec('libx264')
  
   .audioCodec('libmp3lame')
  
   .size('320x240')
  
   .on('error', function(err) {
  
     console.log('An error occurred: ' + err.message);
  
   })
  
   .on('end', function() {
  
     console.log('Processing finished !');
  
   })
  
   .save('/path/to/output.mp4');

  And as well as implemented on() ?

  on('end'),   
  
  on('error'),   
  
  on('response'),

  I will be grateful for the information provided.

• avcodec/h264, videotoolbox : fix crash after VT decoder fails

  21 février 2017, par Aman Gupta

  avcodec/h264, videotoolbox : fix crash after VT decoder fails
  The way videotoolbox hooks in as a hwaccel is pretty hacky. The VT decode
  
  API is not invoked until end_frame(), so alloc_frame() returns a dummy
  
  frame with a 1-byte buffer. When end_frame() is eventually called, the
  
  dummy buffer is replaced with the actual decoded data from
  
  VTDecompressionSessionDecodeFrame().
  When the VT decoder fails, the frame returned to the h264 decoder from
  
  alloc_frame() remains invalid and should not be used. Before
  
  9747219958060d8c4f697df62e7f172c2a77e6c7, it was accidentally being
  
  returned all the way up to the API user. After that commit, the dummy
  
  frame was unref’d so the user received an error.
  However, since that commit, VT hwaccel failures started causing random
  
  segfaults in the h264 decoder. This happened more often on iOS where the
  
  VT implementation is more likely to throw errors on bitstream anomolies.
  
  A recent report of this issue can be see in
  
  http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html
  The issue here is that the dummy frame is still referenced internally by the
  
  h264 decoder, as part of the reflist and cur_pic_ptr. Deallocating the
  
  frame causes assertions like this one to trip later on during decoding :
    Assertion h->cur_pic_ptr->f->buf[0] failed at src/libavcodec/h264_slice.c:1340
  With this commit, we leave the dummy 1-byte frame intact, but avoid returning it
  
  to the user.
  This reverts commit 9747219958060d8c4f697df62e7f172c2a77e6c7.
  Signed-off-by : wm4 <nfxjfg@googlemail.com>
  

  • [DH] libavcodec/h264_refs.c
  • [DH] libavcodec/h264dec.c
  • [DH] libavcodec/version.h
  • [DH] libavcodec/videotoolbox.c