Recherche avancée

Sur d’autres sites (8543)

• lavu/tx : support in-place FFT transforms

  10 février 2021, par Lynne

  lavu/tx : support in-place FFT transforms
  This commit adds support for in-place FFT transforms. Since our
  
  internal transforms were all in-place anyway, this only changes
  
  the permutation on the input.
  Unfortunately, research papers were of no help here. All focused
  
  on dry hardware implementations, where permutes are free, or on
  
  software implementations where binary bloat is of no concern so
  
  storing dozen times the transforms for each permutation and version
  
  is not considered bad practice.
  
  Still, for a pure C implementation, it's only around 28% slower
  
  than the multi-megabyte FFTW3 in unaligned mode.
  Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
  
  contain multiple NOPs, multiple simple swaps, and a few chained swaps,
  
  so regular single-loop single-state permute loops were not possible.
  
  Instead, we filter out parts of the input indices which are redundant.
  
  This allows for a single branch, and with some clever AVX512 asm,
  
  could possibly be SIMD'd without refactoring.
  The inplace_idx array is guaranteed to never be larger than the
  
  revtab array, and in practice only requires around log2(len) entries.
  The power-of-two MDCTs can be done in-place as well. And it's
  
  possible to eliminate a copy in the compound MDCTs too, however
  
  it'll be slower than doing them out of place, and we'd need to dirty
  
  the input array.
  

  • [DH] doc/APIchanges
  • [DH] libavutil/tx.c
  • [DH] libavutil/tx.h
  • [DH] libavutil/tx_priv.h
  • [DH] libavutil/tx_template.c
  • [DH] libavutil/version.h

• How to sum audio from two streams in ffmpeg

  9 février 2021, par user3188445

  I have a video file with two audio streams, representing two people talking at different times. The two people never talk at the same time, so there is no danger of clipping by summing the audio. I would like to sum the audio into one stream without reducing the volume. The ffmpeg amix filter has an option that would seem to do what I want, but the option does not seem to work. Here are two minimal non-working examples (the audio tracks are [0:2] and [0:3]) :

  


  ffmpeg -i input.mkv -map 0:0 -c:v copy \
       -filter_complex '[0:2][0:3]amix' \
       output.m4v

ffmpeg -i input.mkv -map 0:0 -c:v copy \
       -filter_complex '[0:2][0:3]amix=sum=sum' \
       output.m4v


  


  The first example diminishes the audio volume. The second example is a syntax error. I tried other variants like amix=sum and amix=sum=1, but despite the documentation I don't think the sum option exists any more. ffmpeg -h filter=amix does not mention the sum option (ffmpeg version n4.3.1).

  


  My questions :

  


  


  1. Can I sum two audio tracks with ffmpeg, without losing resolution. (I'd rather not cut the volume in half and scale it up, but if there's no other way I guess I'd accept and answer that sacrifices a bit.)

     


  


  2. Is there an easy way to adjust the relative delay of one of the tracks by a few milliseconds ?

     


  


  


• Why is ffmpeg's hstack so much slower than overlay and pad ?

  27 janvier 2021, par cgenco

  I'm using ffmpeg to stitch together two videos of people chatting into a video with each of them side-by-side, like this :

  


  

  


  Here's the command I'm currently using to get this done, which runs at 2.5x on my 13" M1 MacBook Pro :

  


  ffmpeg -y -i left.mp4 -i right.mp4 -filter_complex "
  [0:v] crop=w=in_w/2 [croppedLeft];
  [1:v][1:v] overlay=x=overlay_w/4 [shiftedRight];
  [shiftedRight][croppedLeft] overlay [vout];
  [0:a][1:a] amix [aout]
" -map "[vout]" -map "[aout]" -ac 2 out.mp4


  


  This command crops the left video to half of its original width (cropping so the video is centered), then shifts the right video a quarter of its width to the right, then overlays the left video on the left half of the output merged with the shifted right video.

  


  One day on my weekly fun-time read-through the FFmpeg filters documentation I stumbled on a filter named hstack, which is described as being "faster than using overlay and pad filter to create same output."

  


  My ex wife can affirm that there are few higher priorities in my life than going faster, so I altered my ffmpeg script to use hstack instead of two overlays :

  


  ffmpeg -y -i left.mp4 -i right.mp4 -filter_complex "
  [0:v] crop=w=in_w/2 [croppedLeft];
  [1:v] crop=w=in_w/2 [croppedRight];
  [croppedLeft][croppedRight] vstack [vout];
  [0:a][1:a] amix [aout]
" -map "[vout]" -map "[aout]" -ac 2 out.mp4


  


  ...but that command runs painfully slowly, like 0.1x. It takes multiple minutes to render a single second.

  


  So uhhh what's going on here ? Why is hstack taking so long when it's supposed to be faster ?

  


  I've tried this on both the M1 native build from OSXExperts (version N-99816-g3da35b7) and the standard ffmpeg from brew and hstack is just as slow on each.