Recherche avancée

Sur d’autres sites (4000)

• avformat/mov : Set start_pad correctly in mov_fix_index()

  16 octobre 2017, par Dale Curtis

  avformat/mov : Set start_pad correctly in mov_fix_index()
  Sets the correct start padding value when an edit list is present.
  A new fate test is added, fate-mov-440hz-10ms, to ensure this is
  
  handled correctly.
  Signed-off-by : Dale Curtis <dalecurtis@chromium.org>
  
  Reviewed-by : Sasi Inguva <isasi-at-google.com@ffmpeg.org>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/mov.c
  • [DH] tests/fate/mov.mak
  • [DH] tests/ref/fate/mov-440hz-10ms

• avformat/mov : Fix trampling of ctts during seeks when sidx support is enabled.

  18 juillet 2017, par Dale Curtis

  avformat/mov : Fix trampling of ctts during seeks when sidx support is enabled.
  When sidx box support is enabled, the code will skip reading all
  
  trun boxes (each containing ctts entries for samples inthat box).
  If seeks are attempted before all ctts values are known, the old
  
  code would dump ctts entries into the wrong location. These are
  
  then used to compute pts values which leads to out of order and
  
  incorrectly timestamped packets.
  This patch fixes ctts processing by always using the index returned
  
  by av_add_index_entry() as the ctts_data index. When the index gains
  
  new entries old values are reshuffled as appropriate.
  This approach makes sense since the mov demuxer is already relying
  
  on the mapping of AVIndex entries to samples for correct demuxing.
  As a result of this all ctts entries are now 1-count. A followup
  
  change will be submitted to remove support for > 1 count entries
  
  which will simplify seeking.
  Notes for future improvement :
  
  Probably there are other boxes (stts, stsc, etc) that are impacted
  
  by this issue... this patch only attempts to fix ctts since it
  
  completely breaks packet timestamping.
  This patch continues using an array for the ctts data, which is not
  
  the most ideal given the rearrangement that needs to happen (via
  
  memmove as new entries are read in). Ideally AVIndex and the ctts
  
  data would be set-type structures so addition is always worst case
  
  O(lg(n)) instead of the O(n^2) that exists now ; this slowdown is
  
  noticeable during seeks.
  Signed-off-by : Dale Curtis <dalecurtis@chromium.org>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/isom.h
  • [DH] libavformat/mov.c
  • [DH] tests/fate/seek.mak
  • [DH] tests/ref/seek/extra-mp4

• 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