Recherche avancée

Sur d’autres sites (11558)

• swscale : aarch64 : Optimize the final summation in the hscale routine

  20 avril 2022, par Martin Storsjö

  swscale : aarch64 : Optimize the final summation in the hscale routine
  Before :                     Cortex A53      A72      A73  Graviton 2  Graviton 3
  
  hscale_8_to_15_width8_neon :     8273.0   4602.5   4289.5      2429.7      1629.1
  
  hscale_8_to_15_width16_neon :   12405.7   6803.0   6359.0      3549.0      2378.4
  
  hscale_8_to_15_width32_neon :   21258.7  11491.7  11469.2      5797.2      3919.6
  
  hscale_8_to_15_width40_neon :   25652.0  14173.7  12488.2      6893.5      4810.4
  After :
  
  hscale_8_to_15_width8_neon :     7633.0   3981.5   3350.2      1980.7      1261.1
  
  hscale_8_to_15_width16_neon :   11666.7   5951.0   5512.0      3080.7      2131.4
  
  hscale_8_to_15_width32_neon :   20900.7  10733.2   9481.7      5275.2      3862.1
  
  hscale_8_to_15_width40_neon :   24826.0  13536.2  11502.0      6397.2      4731.9
  Thus, this gives overall a 8-29% speedup for the smaller filter
  
  sizes, around 1-8% for the larger filter sizes.
  Inspired by a patch by Jonathan Swinney <jswinney@amazon.com>.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libswscale/aarch64/hscale.S

• swscale/aarch64 : use multiply accumulate and shift-right narrow

  9 décembre 2019, par Sebastian Pop

  swscale/aarch64 : use multiply accumulate and shift-right narrow
  This patch rewrites the innermost loop of ff_yuv2planeX_8_neon to avoid zips and
  
  horizontal adds by using fused multiply adds. The patch also uses ld1r to load
  
  one element and replicate it across all lanes of the vector. The patch also
  
  improves the clipping code by removing the shift right instructions and
  
  performing the shift with the shift-right narrow instructions.
  I see 8% difference on an m6g instance with neoverse-n1 CPUs :
  
  $ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf bench=start,scale=1024x1024,bench=stop -f null -
  
  before : t:0.014015 avg:0.014096 max:0.015018 min:0.013971
  
  after :  t:0.012985 avg:0.013013 max:0.013996 min:0.012818
  Tested with `make check` on aarch64-linux.
  Signed-off-by : Sebastian Pop <spop@amazon.com>
  
  Reviewed-by : Clément Bœsch <u@pkh.me>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libswscale/aarch64/output.S

• Generating number of thumbnails depending on video size using AWS MediaConvert

  1er décembre 2020, par sakhunzai

  After reading this article I get the sense that AWS media convert job template cannot be re-used to generate thumbnails of arbitrary video size. The article assumes that we know the size/duration of video uploaded upfront hence the number of thumbnails we desire.

  


  What I am looking for is to generate a random number of thumbnails based of video size (e.g large number of thumbnails for large video and small number of thumbnails for small video). I approached this solution using lambda trigger and ffmpeg lambda layer but lambda function timeouts (15 minutes max) for videos larger than 150MB (since it takes time to read the video from the s3 bucket).

  


  What are my options to process large number of video , generate a variable number of thumbnails, merge those thumbs to generate a sprite ?

  


  I tried lambda trigger with ffmpeg/ffprob to generate sprite, but that has timeout issue. Now I have setup a cloud watch event rule to trigger lambda function on mediaconvert job status change( completed)
and merge the thumbs to generate sprite, which seems much lighter but I need an arbitrary number of thumbs.