Recherche avancée

Sur d’autres sites (7580)

• Reduce write time in stdin stream

  20 décembre 2020, par گورو سینی

  I'm trying to record the web page with puppeteer. For that I'm using the same approach as puppeteer-recorder ie taking the screenshot for each frame and writing to the spawned ffmpeg's stdin stream with slight modifications.

  


  The average time taken for screenshot per frame comes between 1-2ms but the average time to write the screenshot data into stream comes to be 290-300ms per frame.

  


  const ffmpeg = spawn(ffmpegPath, ffmpegArgs(30));

for (let i = 1; i <= totalFrames; i++) {
  let screenshot = await page.screenshot({ omitBackground: true });  --> 1ms
  await write(ffmpeg.stdin, screenshot);                             --> 290ms
}

ffmpeg.stdin.end();


const write = (stream, buffer) =>
 new Promise((resolve, reject) => {
   stream.write(buffer, error => {
     if (error) reject(error);
     else resolve();
 });
});


const ffmpegArgs = fps => [
  '-y', '-f', 'image2pipe',
  '-r', `${+fps}`,
  '-i', '-',
  '-c:v', 'libx264',
  '-auto-alt-ref', '0',
  '-s:v', '1280x720',
  '-crf', '20',
  '-pix_fmt', 'yuv420p',
  '-metadata:s:v:0', 'alpha_mode="1"',
  '-tune', 'stillimage', 
  '-movflags', '+faststart', 'output.avi'
];


  


  Is there any way to reduce the time taken while writing ? Thanks.

  


• avformat/hls : Fixes overwriting existing #EXT-X-PROGRAM-DATE-TIME value in HLS playlist

  1er décembre 2020, par Vignesh Ravichandran

  avformat/hls : Fixes overwriting existing #EXT-X-PROGRAM-DATE-TIME value in HLS playlist
  fix ticket : 8989
  This is is due to the following behavior in the current code :
  
  1. The initial_prog_date_time gets set to the current local time
  
  2. The existing playlist (.m3u8) file gets parsed and the segments
  
     present are added to the variant stream
  
  3. The new segment is created and added
  
  4. The existing segments and the new segment are written to the
  
     playlist file. The initial_prog_date_time from point 1 is used
  
     for calculating "#EXT-X-PROGRAM-DATE-TIME" for the segments,
  
     which results in incorrect "#EXT-X-PROGRAM-DATE-TIME" values
  
     for existing segments
  
  The following approach fixes this bug :
  
  1. Add a new variable "discont_program_date_time" of type double
  
     to HLSSegment struct
  
  2. Store the "EXT-X-PROGRAM-DATE-TIME" value from the existing
  
     segments in this variable
  
  3. When writing to playlist file if "discont_program_date_time"
  
     is set, then use that value for "EXT-X-PROGRAM-DATE-TIME" else
  
     use the value present in vs->initial_prog_date_time
  Signed-off-by : Vignesh Ravichandran <vignesh.ravichandran02@gmail.com>
  
  Signed-off-by : liuqi05 <liuqi05@kuaishou.com>
  

  • [DH] libavformat/hlsenc.c

• FFmpeg trim filter fails to use sexagisimal time specification and the output stream is empty. Is it a bug and is there a fix ?

  29 novembre 2020, par Link-akro

  With ffmpeg the trim filter (or its audio variant atrim) malfunctions whenever i try to write a sexagesimal time specification for the boundaries or duration parameters of the filter : the result is always an empty stream.

  


  According to the documentation i already linked, which was generated on November 26, 2020 so far, the time duration specification should be supported.

  


  


  start, end, and duration are expressed as time duration specifications

  


  


  Quote of the spec.

  


  


  [-][HH :]MM:SS[.m...]

  


  


  


  [-]S+[.m...][s|ms|us]

  


  


  I am working in a Windows_10-64bit and scripting in its CMD.exe command-line, should it matter.

  


  Here is an instance of trimming a video stream out of a media file with hardcoded value for simplicity. The audio is retained unless i use atrim as well.
We may or may not append the setpts filter as recommended in the documentation henceforth setpts=PTS-STARTPTS if we want to shift the stream to start at the beginning of the cut range.

  


      ffmpeg -i sample-counter.mp4 -vf "trim=start=start='1:2':end='1:5'" sample-counter-trimmed.mp4


  


  If i use decimal it works as intended.

  


      ffmpeg -i sample-counter.mp4 -vf "trim=start=start='2':end='5'" sample-counter-trimmed.mp4


  


  This is the banner of my ffmpeg build. We may see it is the latest build by gyan.dev at the moment i post this.

  


      ffmpeg version 4.3.1-2020-11-19-full_build-www.gyan.dev Copyright (c) 2000-2020 the FFmpeg developers
      built with gcc 10.2.0 (Rev5, Built by MSYS2 project)
      configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-libsnappy --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint


  


  The incorrect stream is always reported as 0kB weight in the output of ffmpeg. I confirmed with ffprobe Movie_Countdown-trim-2-5.mov -show_streams -show_entries format=duration that the incorrect stream is duration zero.

  


  Should i report it as a bug ? Is there some correction or workaround ?

  


  I would rather a solution with the trim filter itself, but if not possible a CMD batch scripting.
We should not need a different filter like select or seeking option like there are tutorials and questions/answers everywhere already. Scripting would be straight-forward in a proper *nix shell+distrib and taught everywhere so it is not worth caring while CMD answers on the other hand are rare so a scripting workaround for CMD would have some microcosmic worth since making one is considerably less straight-forward than a shell with modern mathematics and parsing abilities built-in or packaged.