Recherche avancée

Sur d’autres sites (10641)

• node-fluent-ffmpeg conversion to mp3 does not fire any "end" or "finish" event

  27 février 2024, par 1voy

  I am downloading a video using ytdl-core and converting it to mp3 using node-fluent-ffmpeg. It seems that the code after the ffmpeg conversion gets executed before the conversion finishes as trying to upload the .mp3 file to a Google Cloud Storage bucket throws an error. I am trying to detect 'end' or 'finish' events but none are being triggered.

  


  Code :

  


  ytdl(url?.toString() as string)
    .once('data', (data) => {
      console.log('start', data);
    })
    .on('progress', async function (progress, downloaded, total) {
      console.log(parseInt(((downloaded / total) * 100).toString()) + '%');
      
    })
    .on('finish', async function () {
      console.log('Download finished...');
      
      console.log('using ffmpeg to convert into mp3');
      Ffmpeg({ source: `/Users/user/project/server/output/${videoId}.mp4` })
        .setFfmpegPath(ffmpeg.path)
        .toFormat('mp3')
        .saveToFile(`/Users/user/project/server/output/${videoId}.mp3`)
        .on('finish', () => {
          console.log('finished conversion');
        });
      console.log('after ffmpeg mp3 conversion');

      const storage = new Storage({
        keyFilename: `./key.json`,
      });

      const bucketName = 'bucketname';
      const bucket = storage.bucket(bucketName);
      let mp3_url;
      console.log(
        fs.existsSync(`/Users/user/project/server/output/${videoId}.mp3`)
      ); // returns false
      bucket.upload(
        `/Users/user/project/server/output/${videoId}.mp3`,
// Error uploading: Error: ENOENT: no such file or directory, open '/Users/me/project/server/output/RMvenf7E-Dg.mp3'
        {
          destination: `${userId}/${videoId}.mp3`,
        },
        function (err, file) {
          if (err) {
            console.error(`Error uploading: ${err}`);
          } else {
            console.log(`mp3 uploaded to ${bucketName}.`);
            console.log(file?.publicUrl());
          }
        }
      );

      
    .pipe(
      fs.createWriteStream(`/Users/me/project/server/output/${videoId}.mp4`)
    );

  console.log('after download and conversion');

  req.on('close', async () => {
    res.end();
  });


  


  Error uploading: Error: ENOENT: no such file or directory, open '/Users/polo/makeklips/server/output/RMvenf7E-Dg.mp3'
[1] /Users/me/project/server/node_modules/.pnpm/fluent-ffmpeg@2.1.2/node_modules/fluent-ffmpeg/lib/processor.js:182
[1]           handleExit(new Error('ffmpeg exited with code ' + code));
[1]                      ^
[1] Error: ffmpeg exited with code 1: Output #0, mp3, to '/Users/me/project/server/output/RMvenf7E-Dg.mp3':
[1] Output file #0 does not contain any stream


  


• flvdec : Honor the "flv_metadata" option for the "datastream" metadata field

  9 février 2024, par Martin Storsjö

  flvdec : Honor the "flv_metadata" option for the "datastream" metadata field
  By default the option "flv_metadata" (internally using the field
  
  name "trust_metadata") is set to 0, meaning that we don't allocate
  
  streams based on information in the metadata, only based on
  
  actual streams we encounter. However the "datastream" metadata field
  
  still would allocate a subtitle stream.
  When muxing, the "datastream" field is added if either a data stream
  
  or subtitle stream is present - but the same metadata field is used
  
  to preemtively create a subtitle stream only. Thus, if the field
  
  was added due to a data stream, not a subtitle stream, the demuxer
  
  would create a stream which won't get any actual packets.
  If there was such an extra, empty subtitle stream, running
  
  avformat_find_stream_info still used to terminate within reasonable
  
  time before 3749eede66c3774799766b1f246afae8a6ffc9bb. After that
  
  commit, it no longer would terminate until it reaches the max
  
  analyze duration, which is 90 seconds for flv streams (see
  
  e6a084641aada7a2e4672172f2ee26642800a361,
  
  24fdf7334d2bb9aab0abdbc878b8ae51eb57c86b and
  
  f58e011a1f30332ba824c155078ca701e29aef63).
  Before that commit (which removed the deprecated AVStream.codec), the
  
  "st->codecpar->codec_id = AV_CODEC_ID_TEXT", set within the demuxer,
  
  would get propagated into st->codec->codec_id by numerous
  
  avcodec_parameters_to_context(st->codec, st->codecpar), then further
  
  into st->internal->avctx->codec_id by update_stream_avctx within
  
  read_frame_internal in libavformat/utils.c (demux.c these days).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/flvdec.c

• avcodec/dxvenc : Fix data races with slice threading

  24 janvier 2024, par Andreas Rheinhardt

  avcodec/dxvenc : Fix data races with slice threading
  The old code set a common struct from each thread ;
  
  this only "worked" (but is still UB) because the values
  
  written are the same for each thread.
  
  Fix this by moving the assignments to the main thread.
  (This also avoids casting const away from a const AVFrame*.)
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/dxvenc.c