Recherche avancée

Sur d’autres sites (12947)

• yadif : restore speed of the C filtering code

  10 mars 2013, par James Darnley

  yadif : restore speed of the C filtering code
  Always use the special filter for the first and last 3 columns (only).
  Changes made in 64ed397 slowed the filter to just under 3/4 of what it
  
  was.  This commit restores the speed while maintaining identical output.
  For reference, on my Athlon64 :
  
  1733222 decicycles in old
  
  2358563 decicycles in new
  
  1727558 decicycles in this
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] libavfilter/vf_yadif.c
  • [DBH] libavfilter/x86/vf_yadif_init.c
  • [DBH] libavfilter/yadif.h

• 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

• Sending Blobs from a Chrome Extension to a Node.js Process without WebSockets [closed]

  29 octobre 2023, par Matrix 404

  Question :
I have a Puppeteer script that runs a Chrome extension, which opens a webpage. The extension records that tab and sends the recorded blobs to the main Node.js process using WebSockets. The main process then streams these blobs to an RTMP server.

  


  I'm looking for an alternative method to send blobs to the main process without using WebSockets. Additionally, I want to know if it's possible to stream these blobs directly from the browser using FFmpeg wasm.

  


  Details :

  


  


  1. My current setup : Puppeteer script -> Chrome extension (recording) -> WebSockets -> Node.js process -> RTMP server.

     


  


  2. I'm exploring options to eliminate the use of WebSockets while maintaining the ability to send recorded blobs from the Chrome extension to the Node.js process efficiently.

     


  


  3. Is it possible to use FFmpeg wasm to stream blobs directly from the browser to an RTMP server ? If so, how can this be achieved ?

     


  


  


  Additional Information :

  


  

  • The technology stack I'm using includes Puppeteer, Chrome extension, Node.js, and FFmpeg.

  


  • Any code snippets, examples, or recommended libraries are greatly appreciated.

  


  


  Constraints :

  


  

  • Compatibility with modern browsers and reasonable performance are essential.

  


  • Ideally, the solution should work in a headless Chrome instance.

  


  


  Thank you for your assistance in finding an efficient solution to this problem !

  


  

  • The technology stack I'm using includes Puppeteer, Chrome extension, Node.js, and FFmpeg.

  


  • Any code snippets, examples, or recommended libraries are greatly appreciated.