I know there is a shit tone of info on the internet about how to record screen casts using ffmpeg but I am wanting to know how to also capture my systems audio (so I can play a track in the background). I'm just not sure what command to use. An example I was given: ffmpeg -f pulse -i <input_options> -ac 2 -thread_queue_size 128 -f x11grab -s $RESOLUTION -i :0.0 -vcodec libx264 -preset ultrafast -threads 0 -loglevel quiet output.mkv I need to know what the pulse source is on my system for <input_options> I tried pactl list short sources as suggested on ffmpeg's wiki but it doesn't look like pactl is installed nor is available... Any idea what I should I use in its place to find the input device?

pulse is the pulseaudio source, if you want to capture pulseaudio's output you need (a) pulseaudio running (b) applications to be outputting to pulseaudio. An alternative on NetBSD is using a psuedo audio device, see https://man.netbsd.org/pad.4

nia Ok cool, thanks. can you give me an idea how I can use pad(4) in the ffmpeg command instead of pulse to capture my screencast and any music I play from an app like ncspot (which i believe uses portaudio )? currently my screencapture.sh looks like this: #!/bin/sh RESOLUTION=1366x768 ffmpeg -thread_queue_size 128 -f x11grab -r 30 -s $RESOLUTION -i :0.0 -vcodec libx264 -preset ultrafast -threads 0 -y output.mkv ffmpeg -i output.mkv workflow-${USER}.webm

I don't know how to point ncspot at a secondary audio device, maybe @pin can help.

nia I wonder if the easiest way wouldn't be for @pfr to build ncspot with the pulseaudio back-end? librespot itself supports most audio back-ends but, ncspot supports only alsa, pulse, portaudio and rodio.

A temporary workaround would be using another player either capable of speaking to /dev/audio directly or through ossaudio(3), then pointing ffmpeg to it by passing -i /dev/audio -f oss . @pfr might be interested in my ffmpeg screencast thread

JuvenalUrbino I think this won't work -- you need the pad in there to actually get the player's output fed back to userspace. If nscpot really doesn't have a way to configure PortAudio's default audio device (portaudio speaks /dev/audio), the pad's audio device could be made the default output using audiocfg, which would make portaudio use it.

nia I'm still unsure how to call pad from the script. Can you give me an example? Secondly, what if I just use mpg123 instead of ncspot? I've tried: mpg123 -a /dev/audio /home/$USER/Music/track.mp3 ffmpeg -f oss -i /dev/audio -thread_queue_size 128 -f x11grab -r 30 -s $RESOLUTION -i :0.0 -vcodec libx264 -preset ultrafast -threads 0 -y -loglevel quiet output.mkv However this still doesn't capture the audio.

That's because telling ffmpeg to read from /dev/audio will read from your microphone rather than mpg123. Maybe something like: ffmpeg4 -f s16le -ar 44100 -ac 2 -i /dev/pad0 -f x11grab -r 30 -s 640x480 -i :0.0 -vcodec libx264 -preset ultrafast output.mkv mpg123 -a /dev/audio1 file.mp3 (This is mostly copied from the example in the pad man page, with your x11grab bits added.) mpg123 needs to run after ffmpeg, only then will ffmpeg start recording. The reason for this is that the fake audio device /dev/audio1 is only created after /dev/pad0 is opened. Once mpg123 starts writing to /dev/audio1, the audio samples become available through the pad that ffmpeg opened.

nia This is, of course, the standard technique to make screencasts with background music, but, it doesn't work--neither on NetBSD nor on OpenBSD (with its sndio ). The only reliable, workable method on both OSes is to have 2 separate ffmpeg processes running: one for background music and another for MIC input + screen grab, both writing NUT files which are then combined into the final video file. Of course, this precludes any live screencasting.

[unknown] Hate to use a trope, but WorkForMe(tm). I just have to restart audio playback for some reason, then it's seamless.

Screen recording with ffmpeg

pfr

nia I'd... rather not.

Can I ask why? What are the side affects of doing this?

nia

pfr Increases the system-wide audio latency from 10 milliseconds to 1 second.

Also... https://freshbsd.org/netbsd/src/commit/YXkYhr6TqxmFajWC

rvp

rvp i can find no other workaround for that choppy playback.

There is one: use the sunau driver instead of oss and everything looks OK--so far. This may even work for live streaming now, I think.

Post #13 updated.

rvp

nia Yeah, I noticed that.

pad has other issues: eg. one has to stop the screen-capture first, and only then stop the background audio playback: ffmpeg will choke if you switch this order. Caveat emptor, etc...

pfr

rvp ffmpeg will choke if you switch this order.

Perhaps this was the problem I've been having. I still haven't successfully managed to capture pad audio when trying the methods mentioned in this thread. I will try again and be mindful of the specific order of things.

« Previous Page