Recherche avancée

Sur d’autres sites (8336)

• libavutil/thread.h : Fixed g++ build error when ASSERT_LEVEL is greater than 1

  17 avril 2017, par Aaron Levinson

  libavutil/thread.h : Fixed g++ build error when ASSERT_LEVEL is greater than 1
  Purpose : libavutil/thread.h : Fixed g++ build error when ASSERT_LEVEL
  
  is greater than 1.  This is only relevant when thread.h is included by
  
  C++ files.  In this case, the relevant code is only defined if
  
  HAVE_PTHREADS is defined as 1.  Use configure —assert-level=2 to do
  
  so.
  Note : Issue discovered as a result of Coverity build failure.  Cause
  
  of build failure pinpointed by Hendrik Leppkes.
  Comments :
  — libavutil/thread.h : Altered ASSERT_PTHREAD_NORET definition such
  
     that it uses av_make_error_string instead of av_err2str().
  
     av_err2str() uses a "parenthesized type followed by an initializer
  
     list", which is apparently not valid C++.  This issue started
  
     occurring because thread.h is now included by the DeckLink C++
  
     files.  The alteration does the equivalent of what av_err2str()
  
     does, but instead declares the character buffer as a local
  
     variable.
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavutil/thread.h

• FFmpeg Audio DPLII + Volume normalization seems failing

  10 avril 2017, par vit123

  Kind FFMpeg experts,

  I’m using the last FFmpeg version 3.2.4, my target is to normalize the DPLII output from a multichannel (e.g. DTS-HD) stream, by just the following two FFMpeg commands :

  1) ffmpeg -i myInput.dtshd -af "aresample=matrix_encoding=dplii:ocl=downmix,volumedetect" -f null NUL

  so detecting for example : "max_volume : -6.2 dB"
  then :

  2) ffmpeg -i myInput.dtshd -af "aresample=matrix_encoding=dplii:ocl=downmix,volume=6.199dB" myOutput.wav

  The big problem is that the WAV output I get is severely clipped and completely different from what I get issuing the following 2 separated commands after the (same) 1st one :

  2a) ffmpeg -i myInput.dtshd -af "aresample=matrix_encoding=dplii:ocl=downmix" myOutputLowVol.wav

  2b) ffmpeg -i myOutputLowVol.wav -af "volume=6.199dB" theCorrectOutput.wav

  Now the big question is : shouldn’t be the command 2) exactly equivalent to commands 2a) + 2b) ?
  Whyever I get 2 very different results : in the 1st case I get an "over-volumed" audio, in the 2nd case I get a perfectly normalized audio ?

  Am I missing anything ? is this a bug ?
  Thanks a lot for your help !

  Vittorio

  P.S.
  please note that issuing a "volumedetect" on "myOutputLowVol.wav", I get just the same "max_volume" resulting from 1), as expected, so the problem seems being all on command 2)

• pthread_frame : minor simplification to error handling

  27 mars 2017, par wm4

  pthread_frame : minor simplification to error handling
  Get rid of the "ret" variable, and always use err. Report the packet as
  
  consumed if err is unset. This should be equivalent to the old code,
  
  which obviously required err=0 for p->result>=0 (and otherwise,
  
  p->result must have had the value err was last set to). The code block
  
  added by commit 32a5b631267 is also not needed anymore, because the new
  
  code strictly returns err if it’s >=0.
  Reviewed-by : "Ronald S. Bultje" <rsbultje@gmail.com>
  

  • [DH] libavcodec/pthread_frame.c