Recherche avancée

Sur d’autres sites (10330)

• ffmpeg-static Trimming a merging audio and viddeo having a freeza at the first second

  13 avril 2023, par sol

  I am using FFmpeg-static in my express server to merge audio and video coming from Youtube Readable Stream then Trim. seems ok and working but im getting an error

  


  ffmpeg video input stream error : Error : write EPIPE
ffmpeg audio input stream error : Error : write EPIPE

  


  then the triiming process has a glitch like freeze on the first second of the video output

  


  here is my code

  


  res.setHeader("Content-Disposition", attachment;  filename="${encodeURIComponent(info.videoDetails.title)}.mp4") ;

  


    let ffmpegArgs = [
      '-y', // Overwrite output file without asking
      '-i', 'pipe:3', // Read video stream from pipe 3
      '-i', 'pipe:4',
      '-map', '0:v',
      '-map', '1:a',
      '-c:v', 'copy',
      '-preset', 'ultrafast',
      '-b:v', '5000k',
      '-maxrate', '5000k',
      '-bufsize', '10000k',
      '-c:a', 'libmp3lame',
      '-crf', '18',
      '-preset', 'veryfast',
      '-movflags', 'frag_keyframe+empty_moov',
      '-f', 'mp4',
      '-loglevel', 'error'
  ];

  if (startTime && endTime) {
      ffmpegArgs = ffmpegArgs.concat(['-ss', startTime, '-to', endTime]); // Duration of the trimmed video
  }

  ffmpegArgs.push('-');

  let video = ytdl(url, { filter: 'videoonly', format: selectedFormat , highWaterMark: 1 << 25 })
  let audio = ytdl(url, { filter: 'audioonly', quality: 'highestaudio', highWaterMark: 1 << 25  });
  const ffmpegProcess = cp.spawn(ffmpeg, ffmpegArgs, {
      stdio: ['pipe', 'pipe', 'pipe', 'pipe', 'pipe'],
  });

  video.pipe(ffmpegProcess.stdio[3]); // Video stream to stdin (fd 3)
  audio.pipe(ffmpegProcess.stdio[4]);
      // Output the resulting merged and trimmed video to a file
      ffmpegProcess.stdio[1].pipe(res);

      // Handle the close event of the ffmpeg process
      ffmpegProcess.on('close', (code) => {
          if (code !== 0) {
            console.error(`ffmpeg process exited with code ${code}`);
          } else {
            console.log('ffmpeg process completed successfully');
            downloadedVideos.push({
              title: info.videoDetails.title,
              url: url,
              format: format
            });
          }
        });


  


  to the trim process i tried to move the -ss and -to to different lines but the freeze issue is still there

  


  i did try to add and error handling event but the output error is still the same error : write EPIPE

  


    // Pipe the video and audio streams to the ffmpeg process
          video.on('error', (err) => {
            console.error(`video stream error: ${err}`);
           });
            
          audio.on('error', (err) => {
            console.error(`audio stream error: ${err}`);
          });
            
          ffmpegProcess.stdio[3].on('error', (err)=> {
            console.error(`ffmpeg video input stream error: ${err} `);
          });
            
          ffmpegProcess.stdio[4].on('error', (err) => {
            console.error(`ffmpeg audio input stream error: ${err} `);
          });


  


• FFmpeg - Wave64 (.w64) file format : question regarding chunk GUIDs

  26 janvier 2023, par pdu

  I am having trouble understanding the headers of the Wave64 (.w64) files generated by ffmpeg and especially the GUIDs.

  


  The specification

  


  I have found this document which describes the file format and the GUIDs. I have also found other websites (here and here) that (indirectly) point to the same document. So this document is the only thing I have.

  


  According to this document the GUIDs are 128bits/16bytes long and should start with the FourCC of the Wave file format, but in lowercase instead of uppercase (see page 3). It also says that the 64bits fields are stored in little-endian (see item 3 of the list page 1), but it does not say anything about 128bits fields (but it should be the same).
For example the GUID for the RIFF chunk is : 66666972-912E-11CF-A5D6-28DB04C10000.

  


  The problem

  


  When I open a .w64 file generated by ffmpeg with an hex editor, I get this : 72 69 66 66 2E 91 CF 11 A5 D6 28 DB 04 C1 00 00. At the beginning, 76 69 66 66 stands for riff in ASCII. We can see that 0x66666972 from the spec was indeed stored in little-endian order (so far, so good). If we continue, we have 2E 91 and CF 11, which are still little-endian for 0x912E and 0x11CF. But now it gets weird : the following group of bytes are : A5 D6 and 28 DB 04 C1 00 00 for 0xA5D6 and 0x28DB04C10000 in the spec. So it is in big-endian now ?

  


  For reference, the relevant ffmpeg source files are wavenc.c, w64.h and w64.c.
I have also found this thread where someone implemented a .wav to .w64 converter (see the .7z attachment in the first post) and the GUIDs are stored in the same way as ffmpeg.

  


  Conclusion

  


  Seeing that two different implementations are doing the same thing, it probably means that I am missing something. Do you have any explanation ?

  


• aaccoder : add a new perceptual noise substitution implementation

  2 juillet 2015, par Rostislav Pehlivanov

  aaccoder : add a new perceptual noise substitution implementation
  This commit finalizes the PNS implementation previously added to the encoder
  
  by moving it to a seperate function search_for_pns() and thus making it
  
  coder-generic. This new implementation makes use of the spread field of
  
  the psy bands and the lambda quality feedback paremeter. The spread of the
  
  spectrum in a band prevents PNS from being used excessively and thus preserve
  
  more phase information in high frequencies.  The lambda parameter allows
  
  the number of PNS-marked bands to vary based on the lambda parameter and the
  
  amount of bits available, making better choices on which bands are to be marked
  
  as noise. Comparisons with the previous PNS implementation can be found
  
  here : https://trac.ffmpeg.org/attachment/wiki/Encode/AAC/
  This is V2 of the patch, the changes from the previous version being that this
  
  version uses the new band->spread metric from aacpsy and normalizes the
  
  energy using the group size. These changes were suggested by Claudio Freire
  
  on the mailing list. Another change is the use of lambda to alter the
  
  frequency threshold. This change makes the actual threshold frequencies
  
  vary between +-2Khz of what’s specified, depending on frame encoding performance.
  Reviewed-by : Claudio Freire <klaussfreire@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/aaccoder.c
  • [DH] libavcodec/aacenc.c
  • [DH] libavcodec/aacenc.h