Recherche avancée

Sur d’autres sites (9738)

• (ffmpeg) How to sync dshow inputs, dropping frames, and -rtbufsize [closed]

  29 juillet 2021, par Zach Fleeman

  I wrote a quick batch script to capture anything from my Elgato HD60 Pro capture card, and while it works in some ways, I don't really understand how certain parameters are affecting my capture.

  


  Whenever I run this command without the -rtbufsize 2048M -thread_queue_size 5096 params, I drop a ton of frames. I only added those params with those values because I found them on another stackoverflow thread. I wouldn't mind actually knowing what these do, and how I can fine-tune them for my script.

  


  ffmpeg.exe -y -rtbufsize 2048M -thread_queue_size 5096 -fflags +igndts ^
-f dshow -i video="Game Capture HD60 Pro":audio="Game Capture HD60 Pro Audio" ^
-filter:v "crop=1410:1080:255:0, scale=706x540" ^
-c:v libx264 -preset veryfast -b:v 1500k -pix_fmt yuv420p ^
-c:a aac ^
-f tee -map 0:v -map 0:a "%mydate%_%mytime%_capture.mp4|[f=flv]rtmp://xxx.xxx.xxx.xxx/live"


  


  In Open Broadcaster Software, my Elgato is a near-instant video feed, but this captures/streams things at a 3-ish second delay, which is okay until I work on this second command. I'm using gdigrab to capture the window from LiveSplit for my speedrunning, but I can't get the video streams to be synced up. I tried adding and modifying another -rtbufsize before the gdigrab input, but again, I'm not sure if this is what I need to do to delay the LiveSplit grab. It seems to always be 2 to 3 seconds ahead of my capture card. How can I get these inputs to be synced and react at the same time ? i.e., I start the timer in LiveSplit at the same time that I hit a button on my super nintendo.

  


  ffmpeg.exe -y -rtbufsize 750M -thread_queue_size 5096 ^
-f dshow  -i video="Game Capture HD60 Pro":audio="Game Capture HD60 Pro Audio" ^
-rtbufsize 2000M -thread_queue_size 5096 ^
-f gdigrab -r 60 -i title=LiveSplit ^
-filter_complex "[0:v][0:v]overlay=255:0 [game];[game][1:v]overlay=0:40 [v]" ^
-c:v libx264 -preset veryfast -b:v 1500k -pix_fmt yuv420p ^
-c:a aac ^
-f tee -map "[v]" -map 0:a "%mydate%_%mytime%_capture.mp4|[f=flv]rtmp://192.168.1.7/live"


  


  tl ;dr
Where should I put -rtbufsize ? What value should it be ? And how about -thread_queue_size ? Are these things that I have to specify once or multiple times for each input ? How can I get my different input sources to sync up ?

  


  p.s., I'm cropping and overlaying my Elgato inputs because my capture card does 1920x1080, but my video is most likely a 4:3-ish SNES/NES game.

  


• lavc/adpcm : THP : don’t use the ADPC/SEEK table when not seeking

  20 juin 2015, par Rodger Combs

  lavc/adpcm : THP : don’t use the ADPC/SEEK table when not seeking
  This is almost certainly closer to how the actual Nintendo players work,
  
  and fixes some output pops in files with blank ADPC/SEEK tables (like
  
  those from brawlcustommusic).
  

  • [DH] libavcodec/adpcm.c
  • [DH] tests/ref/fate/adpcm-thp

• Chrome’s New Audio Notifier

  30 janvier 2014, par Multimedia Mike — General

  Version 32 of Google’s Chrome web browser introduced this nifty feature :

  
  
  

  When a browser tab has an element that is producing audio, the browser’s tab shows the above audio notification icon to inform the user. I have seen that people have a few questions about this, specifically :

  1. How does this feature work ?
  2. Why wasn’t this done sooner ?
  3. Are other browsers going to follow suit ?

  Short answers : 1) Chrome offers a new plugin API that the Flash Player is now using, as are Chrome’s internal media playing facilities ; 2) this feature was contingent on the new plugin infrastructure mentioned in the previous answer ; 3) other browsers would require the same infrastructure support.

  Longer answers follow…

  Plugin History
  Plugins were originally based on the Netscape Plugin API. This was developed in the early 1990s in order to support embedding PDFs into the Netscape web browser. The NPAPI does things like providing graphics contexts for drawing and input processing, and mediate network requests through the browser’s network facilities.

  What NPAPI doesn’t do is handle audio. In the early-mid 1990s, audio support was not a widespread consideration in the consumer PC arena. Due to the lack of audio API support, if a plugin wanted to play audio, it had to go outside of the plugin framework.

  
  
  

  There are a few downsides to this approach :

  • If a plugin wants to play audio, it needs to access unique audio APIs on each supported platform. One of the most famous things I’ve ever written deals concerns this nightmare on Linux. (The picture worth a thousand words.)
  • Plugin necessarily needs free unrestricted access to system facilities, i.e., security measures like sandboxing become more difficult without restricting functionality.
  • Since the browser doesn’t mediate access to the audio APIs, the browser can’t reasonably be expected to know when a plugin is accessing the audio resources.

  So that last item hopefully answers the question of why it has been so difficult for NPAPI-supporting browsers to implement what seems like it would be simple functionality, like implementing a per-tab audio notifier.

  Plugin Future
  Since Google released Chrome in an effort to facilitate advancements on the client side of the internet, they have made numerous efforts to modernize various legacy aspects of web technology. These efforts include the SPDY protocol, Native Client, WebM/WebP, and something call the Pepper Plugin API (PPAPI). This is a more modern take on the classic plugin architecture to supplant the aging NPAPI :

  
  
  

  Right away, we see that the job of the plugin writer is greatly simplified. Where was this API years ago when I was writing my API jungle piece ?

  The Linux version of Chrome was apparently the first version that packaged the Pepper version of the Flash Player (doing so fixed an obnoxious bug in the Linux Flash Player interaction with GTK). Now, it looks like Windows and Mac have followed suit. Digging into the Chrome directory on a Windows 7 installation :

  AppData\Local\Google\Chrome\Application[version]\PepperFlash\pepflashplayer.dll

  This directory exists for version 31 as well, which is still hanging around my system.

  So, to re-iterate : Chrome has a new plugin API that plugins use to access the audio API. Chrome knows when the API is accessed and that allows the browser to display the audio notifier on a tab.

  Other Browsers
  What about other browsers ? “Mozilla is not interested in or working on Pepper at this time. See the Chrome Pepper pages.”