Recherche avancée

Sur d’autres sites (7787)

• Converting and Splitting .wav into .m4a with ffmpeg produces clicks between the splitted files

  24 mai 2023, par calp

  I need to convert an audio .wav-file to .m4a and splitting this m4a into small pieces of four seconds using ffmpeg. These files will be played in a webside again as one continous piece of audio.

  


  The problem is that I get clicks every four seconds where I have a transition from one file to the next.

  


  I found out that ffmpeg does not split the files correctly. I tried two different ways :

  


  

  1. First splitting the wave file and then converting the single files to m4a

  


  2. First converting the wave file to m4a and then splitting it.

  


  


  (1) does not work at all : ffmpeg cuts randomly into the audio and the next piece starts with a fade in. On the first picture you see the splitted wave-file on the first track, converted m4a on the second.

  


  

  


  (2) works better, as the audio is not cut randomly. But the new file still starts with a fade in.

  


  

  


  On the pictures you see a 400Hz sinus for testing purpose.

  


  For converting I used

  


  ffmpeg -i file.wav -c:a aac -b:a 64k out.m4a

  


  For splitting I used :

  


  ffmpeg -i file.m4a -f segment -segment_time 4 -c copy out%03d.m4a

  


  Of course with changing the file extensions according to the order of steps.

  


  Has anyone an idea, how I can avoid these fade-ins and / or split the files correctly ?

  


• Difference between ffmpeg and avconv for rawvideo image2pipe

  15 août 2016, par NHDaly

  I’m not sure why, but avconv does not seem to be piping raw video like I would expect.

  I’m trying pipe a video from ffmpeg into python (eventually I want to read from x11grab, not a video file). It works just fine on my Macbook using ffmpeg, but when I use avconv on Debian Jessie, the stream cuts off early !

  Here’s my basic python, which is following this guide :

  input_resolution_shape = (1280,800,3)
  
  input_bytes = reduce(mul, input_resolution_shape, 1)
  
  print input_bytes
  
  
  
  # Prints 3072000
  
  
  
  import subprocess as sp
  
  command = [ FFMPEG_BIN,   # This is either "avconv" or "ffmpeg".
  
              '-i', 'test_video.mp4',
  
              '-f', 'image2pipe',
  
              '-pix_fmt', 'rgb24',
  
              '-vcodec', 'rawvideo', '-']
  
  pipe = sp.Popen(command, stdout = sp.PIPE, bufsize=10**8)
  
  
  
  import numpy
  
  for _ in range(100):  # read 100 frames
  
      # read 1280*800*3 bytes (= 1 frame)
  
      raw_image = pipe.stdout.read(input_bytes)
  
      # transform the byte read into a numpy array
  
      image = numpy.fromstring(raw_image, dtype='uint8')
  
      if image.size != 0:
  
          print image.size
  
  
  
          # Prints 1015808

  On the mac, the image.size printed is the same as the input_bytes, 3072000. But on debian, it’s 1015808. Any ideas why that could be happening ?

  Interestingly, 3072000/1015808 is just about 3 :

  In [1]:    3072000./1015808.
  
  Out[1]:    3.024193548387097

• Revision d36852b702 : Add encoding option —static-thresh This option exists in VP8, and it was rewri

  11 juillet 2013, par Yunqing Wang

  Changed Paths :
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Add encoding option —static-thresh

  This option exists in VP8, and it was rewritten in VP9 to support
  skipping on different partition levels. After prediction is done,
  we can check if the residuals in the partition block will be all
  quantized to 0. If this is true, the skip flag is set, and only
  prediction data are needed in reconstruction. Based on DCT's energy
  conservation property, the skipping check can be estimated in
  spatial domain.

  The prediction error is calculated and compared to a threshold.
  The threshold is determined by the dequant values, and also
  adjusted by partition sizes. To be precise, the DC and AC parts
  for Y, U, and V planes are checked to decide skipping or not.

  Test showed that
  1. derf set :
  when static-thresh = 1, psnr loss is 0.666% ;
  when static-thresh = 500, psnr loss is 1.162% ;
  2. stdhd set :
  when static-thresh = 1, psnr loss is 1.249% ;
  when static-thresh = 500, psnr loss is 1.668% ;

  For different clips, encoding speedup range is between several
  percentage and 20+% when static-thresh <= 500. For example,
  clip bitrate static-thresh psnr time
  akiyo(cif) 500 0 48.923 5.635s(50f)
  akiyo 500 500 48.863 4.402s(50f)

  parkjoy(1080p) 4000 0 30.380 77.54s(30f)
  parkjoy 4000 500 30.384 69.59s(30f)

  sunflower(1080p) 4000 0 44.461 85.2s(30f)
  sunflower 4000 500 44.418 78.1s(30f)

  Higher static-thresh values give larger speedup with larger
  quality loss.

  Change-Id : I857031ceb466ff314ab580ac5ec5d18542203c53