Recherche avancée

Sur d’autres sites (12224)

• lavc/vp8dsp : rework R-V V idct_dc_add4y

  2 juin 2024, par Rémi Denis-Courmont

  lavc/vp8dsp : rework R-V V idct_dc_add4y
  DCT-related FFmpeg functions often add an unsigned 8-bit sample to a
  
  signed 16-bit coefficient, then clip the result back to an unsigned
  
  8-bit value. RISC-V has no signed 16-bit to unsigned 8-bit clip, so
  
  instead our most common sequence is :
  
      VWADDU.WV
  
      set SEW to 16 bits
  
      VMAX.VV zero     # clip negative values to 0
  
      set SEW to 8 bits
  
      VNCLIPU.WI       # clip values over 255 to 255 and narrow
  Here we use a different sequence which does not require toggling the
  
  vector type. This assumes that the wide addend vector is biased by
  
   128 :
  
      VWADDU.WV
  
      VNCLIP.WI    # clip values to signed 8-bit and narrow
  
      VXOR.VX 0x80 # flip sign bit (convert signed to unsigned)
  Also the VMAX is effectively replaced by a VXOR of half-width. In this
  
  function, this comes for free as we anyway add a constant to the wide
  
  vector in the prologue.
  On C908, this has no observable effects. On X60, this improves
  
  microbenchmarks by about 20%.
  

  • [DH] libavcodec/riscv/vp7dsp_rvv.S
  • [DH] libavcodec/riscv/vp8dsp_rvv.S

• aarch64 : vp9 : Implement NEON loop filters

  14 novembre 2016, par Martin Storsjö

  aarch64 : vp9 : Implement NEON loop filters
  This work is sponsored by, and copyright, Google.
  These are ported from the ARM version ; thanks to the larger
  
  amount of registers available, we can do the loop filters with
  
  16 pixels at a time. The implementation is fully templated, with
  
  a single macro which can generate versions for both 8 and
  
  16 pixels wide, for both 4, 8 and 16 pixels loop filters
  
  (and the 4/8 mixed versions as well).
  For the 8 pixel wide versions, it is pretty close in speed (the
  
  v_4_8 and v_8_8 filters are the best examples of this ; the h_4_8
  
  and h_8_8 filters seem to get some gain in the load/transpose/store
  
  part). For the 16 pixels wide ones, we get a speedup of around
  
  1.2-1.4x compared to the 32 bit version.
  Examples of runtimes vs the 32 bit version, on a Cortex A53 :
  
                                         ARM AArch64
  
  vp9_loop_filter_h_4_8_neon :          144.0   127.2
  
  vp9_loop_filter_h_8_8_neon :          207.0   182.5
  
  vp9_loop_filter_h_16_8_neon :         415.0   328.7
  
  vp9_loop_filter_h_16_16_neon :        672.0   558.6
  
  vp9_loop_filter_mix2_h_44_16_neon :   302.0   203.5
  
  vp9_loop_filter_mix2_h_48_16_neon :   365.0   305.2
  
  vp9_loop_filter_mix2_h_84_16_neon :   365.0   305.2
  
  vp9_loop_filter_mix2_h_88_16_neon :   376.0   305.2
  
  vp9_loop_filter_mix2_v_44_16_neon :   193.2   128.2
  
  vp9_loop_filter_mix2_v_48_16_neon :   246.7   218.4
  
  vp9_loop_filter_mix2_v_84_16_neon :   248.0   218.5
  
  vp9_loop_filter_mix2_v_88_16_neon :   302.0   218.2
  
  vp9_loop_filter_v_4_8_neon :           89.0    88.7
  
  vp9_loop_filter_v_8_8_neon :          141.0   137.7
  
  vp9_loop_filter_v_16_8_neon :         295.0   272.7
  
  vp9_loop_filter_v_16_16_neon :        546.0   453.7
  The speedup vs C code in checkasm tests is around 2-7x, which is
  
  pretty much the same as for the 32 bit version. Even if these functions
  
  are faster than their 32 bit equivalent, the C version that we compare
  
  to also became around 1.3-1.7x faster than the C version in 32 bit.
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 4-5x.
  Examples of runtimes vs C on a Cortex A57 (for a slightly older version
  
  of the patch) :
  
                           A57 gcc-5.3  neon
  
  loop_filter_h_4_8_neon :        256.6  93.4
  
  loop_filter_h_8_8_neon :        307.3 139.1
  
  loop_filter_h_16_8_neon :       340.1 254.1
  
  loop_filter_h_16_16_neon :      827.0 407.9
  
  loop_filter_mix2_h_44_16_neon : 524.5 155.4
  
  loop_filter_mix2_h_48_16_neon : 644.5 173.3
  
  loop_filter_mix2_h_84_16_neon : 630.5 222.0
  
  loop_filter_mix2_h_88_16_neon : 697.3 222.0
  
  loop_filter_mix2_v_44_16_neon : 598.5 100.6
  
  loop_filter_mix2_v_48_16_neon : 651.5 127.0
  
  loop_filter_mix2_v_84_16_neon : 591.5 167.1
  
  loop_filter_mix2_v_88_16_neon : 855.1 166.7
  
  loop_filter_v_4_8_neon :        271.7  65.3
  
  loop_filter_v_8_8_neon :        312.5 106.9
  
  loop_filter_v_16_8_neon :       473.3 206.5
  
  loop_filter_v_16_16_neon :      976.1 327.8
  The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
  
  is again 30-50% faster than the cortex-a53.
  This is an adapted cherry-pick from libav commits
  
  9d2afd1eb8c5cc0633062430e66326dbf98c99e0 and
  
  31756abe29eb039a11c59a42cb12e0cc2aef3b97.
  Signed-off-by : Ronald S. Bultje <rsbultje@gmail.com>
  

  • [DH] libavcodec/aarch64/Makefile
  • [DH] libavcodec/aarch64/vp9dsp_init_aarch64.c
  • [DH] libavcodec/aarch64/vp9lpf_neon.S

• FFMPEG support for HLS v4 and v5

  5 février 2015, par omkar

  As I understand latest FFMPEG version 2.0.1 supports till HLS version 3.

  After going through draft specifications for HLS :

  New features introduced in HLS V4 are :

  • Segments with bit range support with tag EXT-X-BYTERANGE
  • Support for fast forward and fast rewind with tags EXT-X-I-FRAMES-ONLY and EXT-X-I-FRAME-STREAM-INF
  • Alternate media option with tag EXT-X-MEDIA

  New features introduced in HLS V5 are :

  • Introduction of new attributes KEYFORMAT and KEYFORMATVERSIONS for tag EXT-X-KEY
  • Introduction of tag EXT-X-MAP
  • Support for subtitles by introduction of SUBTITLES value for attribute TYPE of tag EXT-X-MEDIA.

  Wanted to know which of the above features are planned to be implemented in FFMPEG library in near future ? It will be great if you share the expected delivery dates or versions for these features.

  Thanks in advance.