Recherche avancée

Sur d’autres sites (8310)

• ffmpeg android : change the speed of video and audio

  2 octobre 2015, par John

  I am working on Android platform with ffmpeg, I’ve built the ffmpeg and run as ’run-time’ command for my android app.

  I’ve tested some function like video trim, it’s working :

  ffmpeg -i /sdcard/vpai/in.mp4 -ss 5 -t  5 -c:v copy -c:a copy /sdcard/vpai/out.mp4

  merge video and audio, also working :

  ffmpeg -i /sdcard/vpai/in.mp4 -i /sdcard/vpai/in.mp3 -c:v copy -c:a copy /sdcard/vpai/out1.mp4

  But when I try to speed up the video, it’s not working, the command is :

  ffmpeg -i /sdcard/vpai/in.mp4 -filter_complex '[0:v]setpts=0.5*PTS[v];[0:a]atempo=2.0[a]' -map '[v]' -map '[a]' /sdcard/vpai/output.mp4

  I execute the exact same command on desktop, its working fine, but not working on the Android...

  The error message :
  Invalid stream specifier :"[v]".
  Last message repeated 3 times
  Stream map "[v]" matches no streams.

  Any one can help ?

• Speed Compare audio file library [closed]

  11 avril, par DrGMark7

  I am trying to benchmark some popular python audio libs for audio work in python. I intend to test how the Read/Write of these libs are. I tested with wav files with length 1, 2, 5, 10, 30, 60, 300, 600, 1800 with the following libs : PyTorch Audio, librosa, soundfile, pydub. The speed is shown in the graph below. Can anyone explain me why it is so fast and why pydub is the fastest ? I am also wondering how big software like Meta or Youtube handle such small audio files in large quantities.

  


  I'm trying to understand it if we take away from Python, it's a slow language.

  


  P.S. I understand that Pytorch is slow because of the overhead of converting to Tensor.

  


• configure : speed up check_deps()

  5 août 2018, par Avi Halachmi (:avih)

  configure : speed up check_deps()
  x4 - x25 faster.
  check_deps() recursively enables/disables components, and its loop is
  
  iterated nearly 6000 times. It's particularly slow in bash - currently
  
  consuming more than 50% of configure runtime, and about 20% with other
  
  shells.
  This commit applies few local optimizations, most effective first :
  
   Use $1 $2 ... instead of pushvar/popvar, and same at enable_deep*
  
   Abort early in one notable case - empty deps, to avoid costly no-op.
  
   Smaller changes which do add up :
  
    - Handle $cfg_checking locally instead of via enable[d]/disable
  
    - $cfg_checking : test done before inprogress - x2 faster in 50%+
  
    - one eval instead of several at the empty-deps early abort path.
   The "actual work" part is unmodified - just its surroundings.
  Biggest speedups (relative and absolute) are observed with bash.
  Tested-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Tested-by : Helmut K. C. Tessarek <tessarek@evermeet.cx>
  
  Tested-by : Dave Yeo <daveryeo@telus.net>
  
  Tested-by : Reino Wijnsma <rwijnsma@xs4all.nl>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] configure