Recherche avancée

Sur d’autres sites (6585)

• avcodec/avcodec : Free frame_thread_encoder on avcodec_open2() error

  18 avril 2021, par Andreas Rheinhardt

  avcodec/avcodec : Free frame_thread_encoder on avcodec_open2() error
  The frame_thread_encoder has so far not been freed in case an error
  
  happened in avcodec_open2() after ff_frame_thread_encoder_init().
  
  This commit changes this.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/avcodec.c

• avformat/oggparsevorbis : Update end_trimming for the last packet

  7 juillet 2021, par Guangyu Sun

  avformat/oggparsevorbis : Update end_trimming for the last packet
  Without end_trimming, the last packet will contain unexpected samples used
  
  for padding.
  This commit partially fixes #6367 when the audio length is long enough.
  dd if=/dev/zero of=./silence.raw count=20 bs=500
  
  oggenc —raw silence.raw —output=silence.ogg
  
  oggdec —raw —output silence.oggdec.raw silence.ogg
  
  ffmpeg -codec:a libvorbis -i silence.ogg -f s16le -codec:a pcm_s16le silence.libvorbis.ffmpeg.raw
  
  ffmpeg -i silence.ogg -f s16le -codec:a pcm_s16le silence.native.ffmpeg.raw
  
  ls -l *.raw
  The original test case in #6367 is still not fixed due to a remaining issue.
  The remaining issue is that ogg_stream->private is not kept during
  
  ogg_save()/ogg_restore(). Field final_duration in the private data is
  
  important to calculate end_trimming.
  Some common operations such as avformat_open_input() and
  
  avformat_find_stream_info() before reading packet will trigger ogg_save()
  
  and ogg_restore().
  Luckily, final_duration will not get updated until the last ogg page. The
  
  save/restore mentioned above will not change final_duration most of the
  
  time. But if the audio length is short, those reads may be performed on
  
  the last ogg page, causing trouble keeping the correct value of
  
  final_duration. We probably need a more complicated patch to address this
  
  issue.
  Signed-off-by : Guangyu Sun <gsun@roblox.com>
  

  • [DH] libavformat/oggparsevorbis.c

• FFMPEG take 3 minutes to generate thumbanils

  19 avril 2022, par The Dead Man

  I am generating the sprite image (combined thumbnails/screenshots) using FLUENT-FFMPEG and node js, the image looks like this.

  


  

  


  Here is my node js script for generating sprite images/thumbnails.

  


  const ffmpegPath = require("@ffmpeg-installer/ffmpeg").path;
const ffmpegCommand = require("fluent-ffmpeg");
ffmpegCommand.setFfmpegPath(ffmpegPath);

let videoUrl =
  "http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ElephantsDream.mp4";
const filename = `output_image`;

ffmpegCommand(videoUrl)
  .seekInput("00:00:01.000")
  .outputOptions([
    "-q:v",
    "8",
    "-frames:v",
    "1",
    "-vsync",
    "0",
    "-qscale",
    "50",
    "-vf",
    "fps=1/10,scale=128:72,tile=11x11",
  ])
  .addOption("-preset", "superfast")
  .on("error", (err) => {
    console.log("error", err);
    reject(err);
  })

  .save(`./tmp/${filename}.png`);


  


  Unfortunately, it takes almost 3 minutes to generate this image which is so bad.

  


  UPDATE

  


  @kesh answer is working only with internal videos.

  


  if I add the video URL as follows.

  


  let videoUrl ="./videos/t.mp4";

  


  then it takes less than 3 seconds to generate thumbnails.

  


  but if I use an external URL as follows.

  


  let videoUrl ="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ElephantsDream.mp4";

  


  Weird, it takes too long to generate thumbnails more than 3 minutes depending on the video.

  


  NOTE you can read full documentation here about FFmpeg and node js.

  


  What do I need to change so that I can super fast generate my thumbnails ?