Recherche avancée

Sur d’autres sites (5952)

• Strange behavior about ”ls | while read" with ffmpeg in shell script [duplicate]

  13 décembre 2018, par user3288408

  This question already has an answer here :

  • execute ffmpeg command in a loop
    
    3 answers
    

  I created a shell script to convert all wave files to mp3 files. I use Ubuntu 18.04, FFmpeg was installed using apt, and I run my script in bash.

  My script :

  #!/bin/bash
  
  
  
  ls *.wav | while read file
  
  do
  
      echo $file
  
      ffmpeg -i "$file" -codec:a libmp3lame -b:a 192k "${file%.*}.mp3"
  
  done

  The target files are followings : (include space characters. The real filenames are longer, but I simplified the filenames. Also in this case, the problem occurs)

  % ls *.wav
  
  '01 A.wav'  '02 A.wav'  '03 A.wav'

  The problem is that sometimes $file in the loop is blank or a part of filename strangely (’echo $file’ shows that), and ffmpeg says ’[broken filename] : No such file or directory’. I confirmed the following things.

  • When I comment out the ffmpeg line, ’echo’ shows what I expected. ($file not broken)
  • When I replace ffmpeg to a similar command like ’lame’, it works. ($file not broken)
  • When I replace ’ls *.wav | while read file’ to ’for file in *.wav’, it works. ($file not broken)

  So, only when I use combination of ’ls’ and ’ffmpeg’, $file is broken. What’s going on ? Or do I misunderstand something ?

• aarch64 : vp9 : use alternative returns in the core loop filter function

  9 janvier 2017, par Janne Grunau

  aarch64 : vp9 : use alternative returns in the core loop filter function
  Since aarch64 has enough free general purpose registers use them to
  
  branch to the appropiate storage code. 1-2 cycles faster for the
  
  functions using loop_filter 8/16, ... on a cortex-a53. Mixed results
  
  (up to 2 cycles faster/slower) on a cortex-a57.
  This is cherrypicked from libav commit
  
  d7595de0b25e7064fd9e06dea5d0425536cef6dc.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/aarch64/vp9lpf_neon.S

• ffmpeg volumedetect returns unstable result

  8 février 2018, par Eric Stdlib

  I am using ffmpeg to calculate the volume of my audio file, but I find that ffmpeg returns different values for different containers (like mp3 v.s. ogg)

  Here is an example. I am using an ogg file from Wikimedia Commons, and converting it to mp3, then analyze the volume of both files. For ogg file, I get -3.0 dB for mean volume, but for mp3 file, I get -3.4 dB. When I use other files, I also get different max volume and histogram.

  [user@localhost tmp]$ wget https://upload.wikimedia.org/wikipedia/commons/b/b9/Audio_Frequency_tone%2C_Middle_C%2C_C4%2C_261.63hz.ogg -O a.ogg 2> /dev/null
  
  [user@localhost tmp]$ ffmpeg -i a.ogg a.mp3 2> /dev/null
  
  [user@localhost tmp]$ ffmpeg -i a.ogg -af volumedetect tmp.ogg 2>&1 | grep volumedetect
  
  [Parsed_volumedetect_0 @ 0x555f69f3f4a0] n_samples: 88768
  
  [Parsed_volumedetect_0 @ 0x555f69f3f4a0] mean_volume: -3.0 dB
  
  [Parsed_volumedetect_0 @ 0x555f69f3f4a0] max_volume: 0.0 dB
  
  [Parsed_volumedetect_0 @ 0x555f69f3f4a0] histogram_0db: 27541
  
  [user@localhost tmp]$ ffmpeg -i a.mp3 -af volumedetect tmp.mp3 2>&1 | grep volumedetect
  
  [Parsed_volumedetect_0 @ 0x55fd62be4740] n_samples: 88768
  
  [Parsed_volumedetect_0 @ 0x55fd62be4740] mean_volume: -3.4 dB
  
  [Parsed_volumedetect_0 @ 0x55fd62be4740] max_volume: -0.0 dB
  
  [Parsed_volumedetect_0 @ 0x55fd62be4740] histogram_0db: 21340
  
  [user@localhost tmp]$ 

  Why is this bug happening ? Which one should I believe ?