Recherche avancée

Sur d’autres sites (11514)

• doc/ffmpeg : fix -enc_time_base documentation

  7 juillet 2023, par Anton Khirnov

  doc/ffmpeg : fix -enc_time_base documentation
  Stop claiming the argument is always a floating point number, which
  
  * confuses floating point and decimal numbers
  
  * is not always true even accounting for the above point
  

  • [DH] doc/ffmpeg.texi

• arm : vp9 : Add NEON itxfm routines

  8 octobre 2016, par Martin Storsjö

  arm : vp9 : Add NEON itxfm routines
  This work is sponsored by, and copyright, Google.
  For the transforms up to 8x8, we can fit all the data (including
  
  temporaries) in registers and just do a straightforward transform
  
  of all the data. For 16x16, we do a transform of 4x16 pixels in
  
  4 slices, using a temporary buffer. For 32x32, we transform 4x32
  
  pixels at a time, in two steps of 4x16 pixels each.
  Examples of relative speedup compared to the C version, from checkasm :
  
                           Cortex       A7     A8     A9    A53
  
  vp9_inv_adst_adst_4x4_add_neon :     3.39   5.83   4.17   4.01
  
  vp9_inv_adst_adst_8x8_add_neon :     3.79   4.86   4.23   3.98
  
  vp9_inv_adst_adst_16x16_add_neon :   3.33   4.36   4.11   4.16
  
  vp9_inv_dct_dct_4x4_add_neon :       4.06   6.16   4.59   4.46
  
  vp9_inv_dct_dct_8x8_add_neon :       4.61   6.01   4.98   4.86
  
  vp9_inv_dct_dct_16x16_add_neon :     3.35   3.44   3.36   3.79
  
  vp9_inv_dct_dct_32x32_add_neon :     3.89   3.50   3.79   4.42
  
  vp9_inv_wht_wht_4x4_add_neon :       3.22   5.13   3.53   3.77
  Thus, the speedup vs C code is around 3-6x.
  This is mostly marginally faster than the corresponding routines
  
  in libvpx on most cores, tested with their 32x32 idct (compared to
  
  vpx_idct32x32_1024_add_neon). These numbers are slightly in libvpx’s
  
  favour since their version doesn’t clear the input buffer like ours
  
  do (although the effect of that on the total runtime probably is
  
  negligible.)
                             Cortex       A7       A8       A9      A53
  
  vp9_inv_dct_dct_32x32_add_neon :    18436.8  16874.1  14235.1  11988.9
  
  libvpx vpx_idct32x32_1024_add_neon 20789.0  13344.3  15049.9  13030.5
  Only on the Cortex A8, the libvpx function is faster. On the other cores,
  
  ours is slightly faster even though ours has got source block clearing
  
  integrated.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/arm/Makefile
  • [DBH] libavcodec/arm/vp9dsp_init_arm.c
  • [DBH] libavcodec/arm/vp9itxfm_neon.S

• avcodec/nvenc : better surface allocation alghoritm, fix rc_lookahead

  21 novembre 2016, par Miroslav Slugeň

  avcodec/nvenc : better surface allocation alghoritm, fix rc_lookahead
  User selectable surfaces are not working correctly, if you set number of
  
  surfaces on cmdline, it will always use minimum 32 or 48 depends on
  
  selected resolution, but in nvenc it is not necessary to use so many
  
  surfaces.
  So from now you can define as low as 1 surface and nvenc will still
  
  work, it will ofcourse lower GPU memory usage by 95% and async_delay to zero
  That was the easy part, now littlebit more...
  Next part of this patch is to always prefer rc_lookahead to be more
  
  important for number of surfaces, than user defined surfaces value.
  
  Maximum rc_lookahead from nvidia documentation is 32, but could increase
  
  in future generations so there is no limit for this yet. Value
  
  async_depth is still accepted and prefered over rc_lookahead.
  There were also bug when you request more than rc_lookahead > 31, it
  
  will always set maximum 31, because surface numbers recalculation was
  
  after setting lookahead, which is now fixed.
  Results :
  
  If you set -rc_lookahead 32 and -bf 3 it will now use only 40 surfaces
  
  and lower GPU memory usage by 20%, also it will now increase PSNR by 0.012dB
  Two more comments :
  1. from my internal test, i don’t understand addition of 4 more surfaces
  
  when lookahead is calculated, i didn’t used this and everything works as
  
  with those 4 more extra surfaces, does anybody know what is going on
  
  there ? I looks like it was used for B frames which are calculated
  
  separately, because B frames maximum is 4.
  2. rc_lookahead is defined default to -1, but in test condition if
  
  (ctx->rc_lookahead) which sets lookahead it will be always true, i don’t
  
  know if this is intended behavior, so in default behavior is lookahead
  
  always on !
  This is default condition when rc_lokkahead is -1 (not defined on
  
  cmdline), whis is maybe something that is not intended :
  
  ctx->encode_config.rcParams.enableLookahead = 1 ;
  
  ctx->encode_config.rcParams.lookaheadDepth  = 0 ;
  
  ctx->encode_config.rcParams.disableIadapt   = 0 ;
  
  ctx->encode_config.rcParams.disableBadapt   = 0 ;
  Signed-off-by : Timo Rothenpieler <timo@rothenpieler.org>
  

  • [DH] libavcodec/nvenc.c