Recherche avancée

Sur d’autres sites (2197)

• ffmpeg - when scaling, how to keep shapes of people's heads

  19 janvier 2017, par Dave

  Ok, I’m quite familiar with FFMPEG utility in general, and have used it for
  years to cut short snippets from videos, etc. But it’s only in the last
  month that and I decided to learn to use it to transcode with video-filters
  etc. (Before that, I was using other tools such as ’Handbrake’ and ’FreeMake’
  and VLC, etc.)

  For my ffmpeg transcodes, my target output resolution will always be constant, from one transcode run to the next. But the resolution and display aspect-ratio of the input file, from one transcode run to the next, will vary...could be almost any values.
  The input files will never already have black-bars when displayed.

  So, the relevant portion [ i.e. the video-filter(s) part) of my cmd line ] presently is as follows :

  ffmpeg ... -vf "scale=720:406,setsar=1,pad=720:506:0:40:Black" ...

  Also note : I do NOT use the "-aspect" option in the cmd-line. (Maybe I’ll
  need to (???) to solve my issue, but I’m unsure about how that interacts
  with scaling.)

  ( EDIT : Oh, I happen to have chosen that resolution value of 720x406, for
  the image-area (i.e. inside the top/bottom black bars) because it
  has an aspect ratio of 16:9 (Of course, 16:9 ratio is common these days. )

  My cmd always executes cleanly and produces an output file (a WebM, tho I doubt
  that container types and/or vcodec choices matter at all to scaling algorithm issues).

  So the issue/problem that I’m trying to solve is how to prevent any stretching
  in either direction. In other words, a round soccer ball in the input file
  must yield a round ball in the output file ! (NOT oval-shaped in either axis).

  ( Edit #2 : Oh, I forgot to mention that I’m not have the same amount of stretching from one ffmpeg output file to the next. Sometimes there is
  no stretch in my output file, and with some other input file, the
  people are too tall in the output, and some other output file will have
  people are too wide. I’m assuming
  there is some single cmd that will always work for each randomly sized
  input file, WITHOUT having to resort to examining meta-data of each
  input and then having to adjust portions of the needed ffmpeg cmd.
  I assume this because I have used a tool called "FreeMake" that needs
  no such adjustment. When you do a ’scale’ with that program, it asks
  you to choose one of four adjustment-algorithms labeled "original"
  "stretched", "zoom..." and "auto". If I recall correctly, it was the
  "auto" choice that prevented any stretching.)

  The goal of that last filter (i.e. the "pad=720:506:0:40:Black" phrase) is to
  add a black bar of 40 pixels to the top and 60 pixels to the bottom.
  (That filter IS producing the black-bands, as desired. I mention it,
  because I’m unsure whether it could be having any effect on the altered
  shape of the ’round soccer ball’). If the "pad" filter IS part of the
  issue, then maybe I’ll need to make multiple ffmpeg cmds to achieve
  my overall goal (!?!?). [I’d LIKE to be able to do everything in just
  one ffmpeg cmd, as shown.]

  OK ?

  So are there any image-processing and ffmpeg gurus out there that
  know how to fix my problem ?

  TIA...

  Dave

• aarch64 : Add NEON optimizations for 10 and 12 bit vp9 MC

  14 décembre 2016, par Martin Storsjö

  aarch64 : Add NEON optimizations for 10 and 12 bit vp9 MC
  This work is sponsored by, and copyright, Google.
  This has mostly got the same differences to the 8 bit version as
  
  in the arm version. For the horizontal filters, we do 16 pixels
  
  in parallel as well. For the 8 pixel wide vertical filters, we can
  
  accumulate 4 rows before storing, just as in the 8 bit version.
  Examples of runtimes vs the 32 bit version, on a Cortex A53 :
  
                                             ARM   AArch64
  
  vp9_avg4_10bpp_neon :                      35.7      30.7
  
  vp9_avg8_10bpp_neon :                      93.5      84.7
  
  vp9_avg16_10bpp_neon :                    324.4     296.6
  
  vp9_avg32_10bpp_neon :                   1236.5    1148.2
  
  vp9_avg64_10bpp_neon :                   4639.6    4571.1
  
  vp9_avg_8tap_smooth_4h_10bpp_neon :       130.0     128.0
  
  vp9_avg_8tap_smooth_4hv_10bpp_neon :      440.0     440.5
  
  vp9_avg_8tap_smooth_4v_10bpp_neon :       114.0     105.5
  
  vp9_avg_8tap_smooth_8h_10bpp_neon :       327.0     314.0
  
  vp9_avg_8tap_smooth_8hv_10bpp_neon :      918.7     865.4
  
  vp9_avg_8tap_smooth_8v_10bpp_neon :       330.0     300.2
  
  vp9_avg_8tap_smooth_16h_10bpp_neon :     1187.5    1155.5
  
  vp9_avg_8tap_smooth_16hv_10bpp_neon :    2663.1    2591.0
  
  vp9_avg_8tap_smooth_16v_10bpp_neon :     1107.4    1078.3
  
  vp9_avg_8tap_smooth_64h_10bpp_neon :    17754.6   17454.7
  
  vp9_avg_8tap_smooth_64hv_10bpp_neon :   33285.2   33001.5
  
  vp9_avg_8tap_smooth_64v_10bpp_neon :    16066.9   16048.6
  
  vp9_put4_10bpp_neon :                      25.5      21.7
  
  vp9_put8_10bpp_neon :                      56.0      52.0
  
  vp9_put16_10bpp_neon/armv8 :              183.0     163.1
  
  vp9_put32_10bpp_neon/armv8 :              678.6     563.1
  
  vp9_put64_10bpp_neon/armv8 :             2679.9    2195.8
  
  vp9_put_8tap_smooth_4h_10bpp_neon :       120.0     118.0
  
  vp9_put_8tap_smooth_4hv_10bpp_neon :      435.2     435.0
  
  vp9_put_8tap_smooth_4v_10bpp_neon :       107.0      98.2
  
  vp9_put_8tap_smooth_8h_10bpp_neon :       303.0     290.0
  
  vp9_put_8tap_smooth_8hv_10bpp_neon :      893.7     828.7
  
  vp9_put_8tap_smooth_8v_10bpp_neon :       305.5     263.5
  
  vp9_put_8tap_smooth_16h_10bpp_neon :     1089.1    1059.2
  
  vp9_put_8tap_smooth_16hv_10bpp_neon :    2578.8    2452.4
  
  vp9_put_8tap_smooth_16v_10bpp_neon :     1009.5     933.5
  
  vp9_put_8tap_smooth_64h_10bpp_neon :    16223.4   15918.6
  
  vp9_put_8tap_smooth_64hv_10bpp_neon :   32153.0   31016.2
  
  vp9_put_8tap_smooth_64v_10bpp_neon :    14516.5   13748.1
  These are generally about as fast as the corresponding ARM
  
  routines on the same CPU (at least on the A53), in most cases
  
  marginally faster.
  The speedup vs C code is around 4-9x.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/aarch64/Makefile
  • [DH] libavcodec/aarch64/vp9dsp_init.h
  • [DH] libavcodec/aarch64/vp9dsp_init_10bpp_aarch64.c
  • [DH] libavcodec/aarch64/vp9dsp_init_12bpp_aarch64.c
  • [DH] libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
  • [DH] libavcodec/aarch64/vp9dsp_init_aarch64.c
  • [DH] libavcodec/aarch64/vp9mc_16bpp_neon.S

• arm : Add NEON optimizations for 10 and 12 bit vp9 loop filter

  5 janvier 2017, par Martin Storsjö

  arm : Add NEON optimizations for 10 and 12 bit vp9 loop filter
  This work is sponsored by, and copyright, Google.
  This is pretty much similar to the 8 bpp version, but in some senses
  
  simpler. All input pixels are 16 bits, and all intermediates also fit
  
  in 16 bits, so there’s no lengthening/narrowing in the filter at all.
  For the full 16 pixel wide filter, we can only process 4 pixels at a time
  
  (using an implementation very much similar to the one for 8 bpp),
  
  but we can do 8 pixels at a time for the 4 and 8 pixel wide filters with
  
  a different implementation of the core filter.
  Examples of relative speedup compared to the C version, from checkasm :
  
                                     Cortex    A7     A8     A9    A53
  
  vp9_loop_filter_h_4_8_10bpp_neon :          1.83   2.16   1.40   2.09
  
  vp9_loop_filter_h_8_8_10bpp_neon :          1.39   1.67   1.24   1.70
  
  vp9_loop_filter_h_16_8_10bpp_neon :         1.56   1.47   1.10   1.81
  
  vp9_loop_filter_h_16_16_10bpp_neon :        1.94   1.69   1.33   2.24
  
  vp9_loop_filter_mix2_h_44_16_10bpp_neon :   2.01   2.27   1.67   2.39
  
  vp9_loop_filter_mix2_h_48_16_10bpp_neon :   1.84   2.06   1.45   2.19
  
  vp9_loop_filter_mix2_h_84_16_10bpp_neon :   1.89   2.20   1.47   2.29
  
  vp9_loop_filter_mix2_h_88_16_10bpp_neon :   1.69   2.12   1.47   2.08
  
  vp9_loop_filter_mix2_v_44_16_10bpp_neon :   3.16   3.98   2.50   4.05
  
  vp9_loop_filter_mix2_v_48_16_10bpp_neon :   2.84   3.64   2.25   3.77
  
  vp9_loop_filter_mix2_v_84_16_10bpp_neon :   2.65   3.45   2.16   3.54
  
  vp9_loop_filter_mix2_v_88_16_10bpp_neon :   2.55   3.30   2.16   3.55
  
  vp9_loop_filter_v_4_8_10bpp_neon :          2.85   3.97   2.24   3.68
  
  vp9_loop_filter_v_8_8_10bpp_neon :          2.27   3.19   1.96   3.08
  
  vp9_loop_filter_v_16_8_10bpp_neon :         3.42   2.74   2.26   4.40
  
  vp9_loop_filter_v_16_16_10bpp_neon :        2.86   2.44   1.93   3.88
  The speedup vs C code measured in checkasm is around 1.1-4x.
  
  These numbers are quite inconclusive though, since the checkasm test
  
  runs multiple filterings on top of each other, so later rounds might
  
  end up with different codepaths (different decisions on which filter
  
  to apply, based on input pixel differences).
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 2-4x.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/arm/Makefile
  • [DH] libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
  • [DH] libavcodec/arm/vp9lpf_16bpp_neon.S