Recherche avancée

Sur d’autres sites (12847)

• build : rename version.h to libavutil/ffversion.h

  29 novembre 2013, par Timothy Gu

  build : rename version.h to libavutil/ffversion.h
  Also the libavutil/ffversion.h will be installed.
  Rationale :
  
  * Applications might want to know FFmpeg’s version besides the individual
  
    libraries’.
  
  * Avoids file name clash between FFmpeg’s ./version.h and lib*/version.h when
  
    a library source file includes both and is compiled on an out-of-tree build.
  Fixes #1769.
  Signed-off-by : Timothy Gu <timothygu99@gmail.com>
  
  Reviewed-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] .gitignore
  • [DH] Makefile
  • [DH] cmdutils.c
  • [DH] doc/APIchanges
  • [DH] ffprobe.c
  • [DH] libavutil/Makefile
  • [DH] libavutil/version.h

• aarch64 : vp9itxfm16 : Do a simpler half/quarter idct16/idct32 when possible

  25 février 2017, par Martin Storsjö

  aarch64 : vp9itxfm16 : Do a simpler half/quarter idct16/idct32 when possible
  This work is sponsored by, and copyright, Google.
  This avoids loading and calculating coefficients that we know will
  
  be zero, and avoids filling the temp buffer with zeros in places
  
  where we know the second pass won’t read.
  This gives a pretty substantial speedup for the smaller subpartitions.
  The code size increases from 21512 bytes to 31400 bytes.
  The idct16/32_end macros are moved above the individual functions ; the
  
  instructions themselves are unchanged, but since new functions are added
  
  at the same place where the code is moved from, the diff looks rather
  
  messy.
  Before :
  
  vp9_inv_dct_dct_16x16_sub1_add_10_neon :     284.6
  
  vp9_inv_dct_dct_16x16_sub2_add_10_neon :    1902.7
  
  vp9_inv_dct_dct_16x16_sub4_add_10_neon :    1903.0
  
  vp9_inv_dct_dct_16x16_sub8_add_10_neon :    2201.1
  
  vp9_inv_dct_dct_16x16_sub12_add_10_neon :   2510.0
  
  vp9_inv_dct_dct_16x16_sub16_add_10_neon :   2821.3
  
  vp9_inv_dct_dct_32x32_sub1_add_10_neon :    1011.6
  
  vp9_inv_dct_dct_32x32_sub2_add_10_neon :    9716.5
  
  vp9_inv_dct_dct_32x32_sub4_add_10_neon :    9704.9
  
  vp9_inv_dct_dct_32x32_sub8_add_10_neon :   10641.7
  
  vp9_inv_dct_dct_32x32_sub12_add_10_neon :  11555.7
  
  vp9_inv_dct_dct_32x32_sub16_add_10_neon :  12499.8
  
  vp9_inv_dct_dct_32x32_sub20_add_10_neon :  13403.7
  
  vp9_inv_dct_dct_32x32_sub24_add_10_neon :  14335.8
  
  vp9_inv_dct_dct_32x32_sub28_add_10_neon :  15253.6
  
  vp9_inv_dct_dct_32x32_sub32_add_10_neon :  16179.5
  After :
  
  vp9_inv_dct_dct_16x16_sub1_add_10_neon :     282.8
  
  vp9_inv_dct_dct_16x16_sub2_add_10_neon :    1142.4
  
  vp9_inv_dct_dct_16x16_sub4_add_10_neon :    1139.0
  
  vp9_inv_dct_dct_16x16_sub8_add_10_neon :    1772.9
  
  vp9_inv_dct_dct_16x16_sub12_add_10_neon :   2515.2
  
  vp9_inv_dct_dct_16x16_sub16_add_10_neon :   2823.5
  
  vp9_inv_dct_dct_32x32_sub1_add_10_neon :    1012.7
  
  vp9_inv_dct_dct_32x32_sub2_add_10_neon :    6944.4
  
  vp9_inv_dct_dct_32x32_sub4_add_10_neon :    6944.2
  
  vp9_inv_dct_dct_32x32_sub8_add_10_neon :    7609.8
  
  vp9_inv_dct_dct_32x32_sub12_add_10_neon :   9953.4
  
  vp9_inv_dct_dct_32x32_sub16_add_10_neon :  10770.1
  
  vp9_inv_dct_dct_32x32_sub20_add_10_neon :  13418.8
  
  vp9_inv_dct_dct_32x32_sub24_add_10_neon :  14330.7
  
  vp9_inv_dct_dct_32x32_sub28_add_10_neon :  15257.1
  
  vp9_inv_dct_dct_32x32_sub32_add_10_neon :  16190.6
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/aarch64/vp9itxfm_16bpp_neon.S

• How do I send a mediaStream from the electron renderer process to a background ffmpeg process ?

  26 juillet 2020, par Samamoma_Vadakopa

  Goal (to avoid the XY problem) :

  


  I'm building a small linux desktop application using webRTC, electron, and create-react-app. The application should receive a mediaStream via a webRTC peer connection, display the stream to the user, create a virtual webcam device, and send the stream to the virtual webcam so it can be selected as the input on most major videoconferencing platforms.

  


  Problem :

  


  The individual parts all work : receiving the stream (webRTC), creating the webcam device (v4l2loopback), creating a child process of ffmpeg from within electron, passing the video stream to the ffmpeg process, streaming the video to the virtual device using ffmpeg, and selecting the virtual device and seeing the video stream in a videoconference meeting.

  


  But I'm currently stuck on tying the parts together.
The problem is, the mediaStream object is available inside electron's renderer process (as state in a deeply nested react component, FWIW). As far as I can tell, I can only create a node.js child process of ffmpeg from within electron's main process. That implies that I need to get the mediaStream from the renderer to the main process. To communicate between processes, electron uses an IPC system. Unfortunately, it seems that IPC doesn't support sending a complex object like a video stream.

  


  What I've tried :

  


  


  • starting ffmpeg child process (using child_process.spawn) from within renderer process throws 'fs.fileexistssync' error. Browsing SO indicates that only the main process can start these background processes.

    


  


  • creating separate webRTC connection between renderer and main to re-stream the video. I'm using IPC to facilitate the connection, but offer/answer descriptions aren't reaching the other peer over IPC - my guess is this is due to the same limitations on IPC as before.

    


  


  


  My next step is to create a separate node server on app startup which ingests the incoming RTC stream and rebroadcasts it to the app's renderer process, as well as to a background ffmpeg process.

  


  Before I try that, though, does anyone have suggestions for approaches I should consider ? (this is my first SO question, so any advice on how to improve it is appreciated).