Recherche avancée

Sur d’autres sites (9543)

• Revision c8ed36432e : Non-uniform quantization experiment This framework allows lower quantization bi

  4 mars 2015, par Deb Mukherjee

  Changed Paths :
   Modify /configure

  
   Modify /vp9/common/vp9_blockd.h

  
   Modify /vp9/common/vp9_onyxc_int.h

  
   Modify /vp9/common/vp9_quant_common.c

  
   Modify /vp9/common/vp9_quant_common.h

  
   Modify /vp9/common/vp9_rtcd_defs.pl

  
   Modify /vp9/decoder/vp9_decodeframe.c

  
   Modify /vp9/decoder/vp9_detokenize.c

  
   Modify /vp9/encoder/vp9_block.h

  
   Modify /vp9/encoder/vp9_encodemb.c

  
   Modify /vp9/encoder/vp9_encodemb.h

  
   Modify /vp9/encoder/vp9_quantize.c

  
   Modify /vp9/encoder/vp9_quantize.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Non-uniform quantization experiment

  This framework allows lower quantization bins to be shrunk down or
  expanded to match closer the source distribution (assuming a generalized
  gaussian-like central peaky model for the coefficients) in an
  entropy-constrained sense. Specifically, the width of the bins 0-4 are
  modified as a factor of the nominal quantization step size and from 5
  onwards all bins become the same as the nominal quantization step size.
  Further, different bin width profiles as well as reconstruction values
  can be used based on the coefficient band as well as the quantization step
  size divided into 5 ranges.

  A small gain currently on derflr of about 0.16% is observed with the
  same paraemters for all q values.
  Optimizing the parameters based on qstep value is left as a TODO for now.

  Results on derflr with all expts on is +6.08% (up from 5.88%).

  Experiments are in progress to tune the parameters for different
  coefficient bands and quantization step ranges.

  Change-Id : I88429d8cb0777021bfbb689ef69b764eafb3a1de

• aacenc : remove the experimental flag

  5 décembre 2015, par Rostislav Pehlivanov

  aacenc : remove the experimental flag
  Thiss commit removes the experimental flag from the native AAC Encoder
  
  and thus makes it the default.
  After a lot of work, done by myself and Claudio Freire, the quality of
  
  this encoder rivals and surpasses libfdk_aac in some situations. The
  
  encoder had instability issues earlier which prevented it from having
  
  its experimental flag removed, however the last commits done by Claudio
  
  removed the last known source of instability and solved a lot of
  
  problems which were previously observed. The issues were caused by the
  
  various coding tools interfering with the scalefactor indices. Thus,
  
  with these problems solved, it should now be possible to declare this
  
  encoder as the default and recommend that the users should use it
  
  instead of others provided by external libraries, as it is both faster
  
  and has a subjectively higher quality with selected tracks.
  
  The encoder has still yet to be fine tuned for every possible audio file
  
  type like music or voice, so it is hoped that with the experimental flag
  
  removed the users should be able to provide feedback and make the
  
  encoder better than the alternatives for every type of audio and at
  
  every bitrate.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/aacenc.c

• How to stop a sound when certain other sound is inserted in the mix in ffmpeg ?

  3 avril 2022, par Antonio Oliveira

  I'm using a ffmpeg command that takes a set of sounds, mixes them into a single file, separating them by certain time intervals.

  


  Below is how my command is today.

  


  ffmpeg -i 
close_hh.wav    -i \
crash_l.wav     -i \
crash_r.wav     -i \
floor.wav       -i \
kick_l.wav      -i \
kick_r.wav      -i \
open_hh.wav     -i \
ride.wav        -i \
snare.wav       -i \
splash.wav      -i \
tom_1.wav       -i \
tom_2.wav       -i \
  tom_3.wav  -filter_complex  " [6]adelay=0|0[note_0];  [0]adelay=360|360[note_1];  [6]adelay=1260|1260[note_2];  [0]adelay=1537|1537[note_3];  [6]adelay=2494|2494[note_4];  [5]adelay=2767|2767[note_5];  [0]adelay=2969|2969[note_6];  [6]adelay=3673|3673[note_7];  [5]adelay=3924|3924[note_8];  [0]adelay=4132|4132[note_9];  [0][note_0][note_1][note_2][note_3][note_4][note_5][note_6][note_7][note_8][note_9]amix=inputs=11:normalize=0" record.wav


  


  This is the resulting audio that this command generates :

  


  ffmpg record.wav : https://drive.google.com/file/d/1LFV4ImLKLnRCqZRhZ7OqZy4Ecq5fwT3j/view?usp=sharing

  


  The purpose is to generate a drum recording, so I would like to simulate the dynamics of the hi-hat sounds : When the closed hi-hat is played, the open hi-hat will stop playing immediately if it is still sounding. The same behavior does not happen for any of the other sounds.

  


  One point that makes this a little more challenging is that other sounds can also be played between open hi-hat and closed hi-hat strikes, and theoretically the sound interruption behavior should work normally.

  


  Below is a recording demonstrating the expected result. (My app already reproduces the sound result I need internally, so I just made a simple recording with the microphone to illustrate)

  


  mic record.wav https://drive.google.com/file/d/19x19Fd_URQVo-MMCmGEHIC1SjaQbpWrh/view?usp=sharing

  


  Notice that in the first audio (ffmpeg record.wav) the first sound (open hi-hat) continues playing after the second is played.
In the second audio (mic record.wav) the first sound stops immediately after the second sound is played.

  


  How should the ffmpeg command be to get the expected result ?