Recherche avancée

Sur d’autres sites (4133)

• TV Screen gittery while sending Stream using FFMPEG Android

  24 septembre 2019, par Arvind

  I am getting issue while i am sending the stream to wowza using FFMPEG on RTMP
  issue is stream working good sending to wowza but issue is while sending its making android tv screen gittery probable what i found this is because its taking time on transcoding and UI thread gets hang

  let me show you my command :

  -i - -strict experimental -acodec aac -ac 1 -ar 44100 -vcodec libx264 -pix_fmt yuv420p -g 8 -vb 26k -profile:v main -preset ultrafast -r 8 -f flv -threads 0 -async 1 -vsync 1 rtmp://origin.cdn.wowza.com:1935

  and below some log :

   D/From the FFMPEG: frame=   51 fps= 13 q=40.0 size=      85kB time=00:00:06.52 bitrate= 107.0kbits/s dup=6 drop=273 speed=1.61x    
  
  09-24 03:27:42.094 2189-2189/com.addwatchhdmi.app D/Execute onProgress: frame=   51 fps= 13 q=40.0 size=      85kB time=00:00:06.52 bitrate= 107.0kbits/s dup=6 drop=273 speed=1.61x    

• avcodec/v4l2_m2m : handle v4l2 end of stream event

  1er avril 2020, par Ming Qian

  avcodec/v4l2_m2m : handle v4l2 end of stream event
  When flushing the capture buffers, the driver may send a V4L2_EVENT_EOS
  
  to notify that draining is completed. Currently, v4l2_m2m does not
  
  subscribe to this event, which can cause some devices (i.e. imx8qm) to
  
  hang at the end of encoding/decoding. Support for handling the event is
  
  added in this commit.
  Some devices may not signal V4L2_EVENT_EOS. This is logged as a warning
  
  message during initialization and not treated as a fatal error.
  Signed-off-by : Ming Qian <ming.qian@nxp.com>
  
  Signed-off-by : Andriy Gelman <andriy.gelman@gmail.com>
  

  • [DH] libavcodec/v4l2_context.c
  • [DH] libavcodec/v4l2_m2m_dec.c
  • [DH] libavcodec/v4l2_m2m_enc.c

• ffmpeg buffering stdin when spawned from node

  3 juin 2020, par devneal17

  I'm trying to use node.js to write png data to ffmpeg to create video. I've verified that the following code works :

  



  let ffmpeg = spawn(
  "ffmpeg",
  [
    "-y",
    "-loglevel", "info",
    "-f", "image2pipe",
    "-c:v", "png",
    "-r", `${this.fps}`,
    "-i", "-",

    "-an",
    "-vcodec", "libx264",
    "-pix_fmt", "yuv420p",
    "output.mp4",
  ],
);
ffmpeg.stdout.on('data', data => {
  console.log(`ffmpeg stdout: ${data}`);
});
ffmpeg.stderr.on('data', data => {
  console.log(`ffmpeg stderr: ${data}`);
});

let bufs = [];
let p = Promise.resolve();
for (let i = 0; i < this.frameData.length; i++) {
  p = p.then(_ => new Promise(resolve => {
    this.renderFrame(i);
    this.renderer.domElement.toBlob(blob => {
      blob.arrayBuffer().then(arr => {
        console.log('writing...');
        let uInt8Arr = new Uint8Array(arr);
        // ffmpeg.stdin.write(uInt8Arr);
        bufs.push(uInt8Arr);
        resolve();
      });
    });
  }));
}
p = p.then(_ => {
  for (let buf of bufs) {
    ffmpeg.stdin.write(buf);
  }
  ffmpeg.stdin.end();
});



  



  Sorry if it seems complicated, the promises are used as a workaround for the fact that toBlob() runs asynchronously but the frames must be written in order.

  



  That code works correctly as written, but it's needlessly inefficient because it writes the frame data to an array only to write it to ffmpeg later. However if I uncomment ffmpeg.stdin.write(uInt8Arr); and comment the loop where the array data is copied to ffmpeg, ffmpeg will simply hang at the end without generating any video. If I then perform a "large enough" action like save a file or spawn a new process, ffmpeg will generate the video correctly.

  



  I suspect that there's some sort of buffering issue causing this, but I don't fully understand it or know how to fix it. I've already tried sending various signals with to ffmpeg with ffmpeg.kill() and running it through stdbuf as suggested here to no avail. Is there any workaround for this ?