Recherche avancée

Sur d’autres sites (11282)

• How to use ffmpeg to encode isolated motion vectors (using codecview)

  22 juillet 2021, par Temmeh

  I have been successfully using this command to superimpose MPEG motion vectors onto a video :

  


  ffmpeg -v error -flags2 +export_mvs -i input.mp4 -vf codecview=mv=pf+bf+bb -y output.mp4

  


  Now I would like to be able to export an h264 mp4 of just the motion vector arrows, like in this example, without the original video layered underneath. I checked the codecview documentation and and did not find a flag or option to do this.

  


  Any help is appreciated !

  


• swscale/x86/output : add AVX2 version of yuv2nv12cX

  26 avril 2020, par Nelson Gomez

  swscale/x86/output : add AVX2 version of yuv2nv12cX
  256 bits is just wide enough to fit all the operands needed to vectorize
  
  the software implementation, but AVX2 is needed to for a couple of
  
  instructions like cross-lane permutation.
  Output is bit-for-bit identical to C.
  Signed-off-by : Nelson Gomez <nelson.gomez@microsoft.com>
  

  • [DH] libswscale/x86/output.asm
  • [DH] libswscale/x86/swscale.c

• configure : _deps : validate, reduce sensitivity

  28 août 2018, par Avi Halachmi (:avih)

  configure : <fflib>_deps : validate, reduce sensitivity
   Allow to add deps in any order rather than "in linking order".
  
   Expand deps chains as required rather than just once.
  
   Validate that there are no cycles.
  
   Validate that [after expansion] deps are limited to other fflibs.
  
   Remove expectation for a specific output order of unique().
  Previously when adding items to <fflib>_deps, developers were
  
  required to add them in linking order. This can be awkward and
  
  bug-prone, especially when a list is not empty, e.g. when adding
  
  conditional deps.
  It also implicitly expected unique() to keep the last instance of
  
  recurring items such that these lists maintain their linking order
  
  after removing duplicate items.
  This patch mainly allows to add deps in any order by keeping just
  
  one master list in linking order, and then reordering all the
  
  <fflib>_deps lists to align with the master list order.
  This master list is LIBRARY_LIST itself, where otherwise its order
  
  doesn't matter.
  The patch also removes a limit where these deps lists were expanded
  
  only once. This could have resulted in incomplete expanded lists,
  
  or forcing devs to add already-deducable deps to avoid this issue.
  Note : it is possible to deduce the master list order automatically
  
  from the deps lists, but in this case it's probably not worth the
  
  added complexity, even if minor. Maintaining one list should be OK.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] configure