Recherche avancée

Sur d’autres sites (14255)

• ffmpeg is lossing quality [closed]

  19 septembre 2024, par gabriel guzman

  I have this in ffluent ffmpeg

  


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

      ffmpeg()
        .input(videoDetails.imagePath)
        .input(audioPath)
        .audioCodec('aac')
        .videoCodec('libx264')
        .outputOptions([
          '-crf 0',
          '-preset veryslow'
        ])
        .on('end', () => {
          console.log('Video generado correctamente');
          resolve(videoDetails); // Retorna el objeto videoDetails si se genera correctamente
        })
        .on('error', (err) => {
          console.error('Error:', err.message);
          reject(null); // Retorna null si falla
        })
        .save(videoDetails.videoPath);


  


  Why if the audio size is 100 kb and the image size is 2mb it generates a 1.5mb video ? This doesn't make sense

  


  I tried different .videoCodec('libx265') => it doesn't work
I tried

  


  ffmpeg()
//set rendering options
.input(imgPath)
.loop()
.addInputOption('-framerate 2')
.input(audioPath)
.videoCodec('libx264')
.audioCodec('copy')
.audioBitrate('320k')
.videoBitrate('8000k', true)
// .size('1920x1080')  just comment this out
.outputOptions([
    '-preset medium',
    '-tune stillimage',
    '-crf 18',
    '-pix_fmt yuv420p',
    '-shortest'
])
``` it doesn't work


  


• riscv : probe for Zbb extension at load time

  8 juin 2024, par Rémi Denis-Courmont

  riscv : probe for Zbb extension at load time
  Due to hysterical raisins, most RISC-V Linux distributions target a
  
  RV64GC baseline excluding the Bit-manipulation ISA extensions, most
  
  notably :
  
   Zba : address generation extension and
  
   Zbb : basic bit manipulation extension.
  
  Most CPUs that would make sense to run FFmpeg on support Zba and Zbb
  
  (including the current FATE runner), so it makes sense to optimise for
  
  them. In fact a large chunk of existing assembler optimisations relies
  
  on Zba and/or Zbb.
  Since we cannot patch shared library code, the next best thing is to
  
  carry a flag initialised at load-time and check it on need basis.
  
  This results in 3 instructions overhead on isolated use, e.g. :
  
  1 :  AUIPC rd, %pcrel_hi(ff_rv_zbb_supported)
  
      LBU   rd, %pcrel_lo(1b)(rd)
  
      BEQZ  rd, non_Zbb_fallback_code
  
      // Zbb code here
  The C compiler will typically load the flag ahead of time to reducing
  
  latency, and can also keep it around if Zbb is used multiple times in a
  
  single optimisation scope. For this to work, the flag symbol must be
  
  hidden ; otherwise the optimisation degrades with a GOT look-up to
  
  support interposition :
  
  1 :  AUIPC rd, GOT_OFFSET_HI
  
      LD    rd, GOT_OFFSET_LO(rd)
  
      LBU   rd, (rd)
  
      BEQZ  rd, non_Zbb_fallback_code
  
      // Zbb code here
  This patch adds code to provision the flag in libraries using bit
  
  manipulation functions from libavutil : byte-swap, bit-weight and
  
  counting leading or trailing zeroes.
  

  • [DH] libavcodec/riscv/Makefile
  • [DH] libavcodec/riscv/cpu_common.c
  • [DH] libavdevice/riscv/Makefile
  • [DH] libavdevice/riscv/cpu_common.c
  • [DH] libavfilter/riscv/Makefile
  • [DH] libavfilter/riscv/cpu_common.c
  • [DH] libavformat/riscv/Makefile
  • [DH] libavformat/riscv/cpu_common.c
  • [DH] libavutil/riscv/Makefile
  • [DH] libavutil/riscv/cpu.h
  • [DH] libavutil/riscv/cpu_common.c
  • [DH] libswscale/riscv/Makefile
  • [DH] libswscale/riscv/cpu_common.c
  • [DH] tests/ref/fate/source

• OpenCV no longer opens video files VideoCapture

  15 février 2018, par gruffmeister

  I have a problem seemingly caused by OpenCV 3.xx - the problem does not manifest in OpenCV 2.xx

  The issue is reading video files. I’ve set my code up as follows :

  >#include 
  
  >#include 
  
  >#include 
  
  >#include 
  
  >#include 
  
  
  
  >int main()
  
  
  
  >    cv::VideoCapture cap;
  
  >    cv::Mat frame;
  
  >    if(!cap.open("Myfile.avi"))
  
  >        std::cout << "Open failed" << std::endl;
  
  >    else
  
  >        cap.read(frame);
  
  >
  
  >    cv::imshow("Frame", frame);
  
  >    cv::waitKey(5000);
  
  >    return 0;

  Now the problem is when the code gets to "cap.read(frame)" I get a "vector subscript is out of range" error with OpenCV 3.40 and this does not happen with my build of OpenCV 2.4.9. The format of the file is in avi, its not some weird codec, and clearly it works in previous versions of OpenCV.

  I’ve tried other OpenCV 3.xx builds and I get the same or similar problems with simply reading a file in.

  My question is twofold :
  How do I get OpenCV 3.xx to work with reading video files (or do I need to regress to 2.xx ?)

  Why has the major revision change completely screwed up video file reading ? That doesn’t make any sense for a computer vision API.

  As a guess it will be something to do with the FFMPEG implementation because various searches have turned up other people having issues with this.

  Any help is much appreciated.

  Thanks