Currently, the extra audio channels just get cropped out. Another question might be, are there even any mics which produce more than 2 audio channels?

I have no idea why or how to fix it.

Need to transcode them separately then copy them into the container.

screencast.sh currently does not appear to read from the specified --config option, or from its default setting. Additionally, attempting to specify --config manually simply brings up the usage information.

.screencastrc:

For Logitech USB Mic

MICCHANNELS = 1
MICSOURCE=hw:1,0

Other Settings

FPS=20

The resulting processed.mp4 file (using screencast start, screencast stop then screencast post) uses the default values issued by the script.

Using [[ -t 0 ]] alone results in it always thinking it's in a terminal, while using [[ -p /dev/stdin ]] alone results in it never thinking it's in a terminal. Need to find a more robust test.

It looks like amixer can be used to check if stereo mix is supported and enabled, so this should be doable without terribly much trouble.

Since youtube likes to darken videos, it's helpful to brighten it up a bit before uploading it.

It should continue searching until all potential locations have been exhausted.

Current problem: remnants of older recordings (system audio, voice data) may get mixed in when post-processing a current recording.

Idea: record the options specified with screencast start to a temporary file (overwrite it if it already exists?). Read it (if it exists) when beginning post-processing, then remove the file when post-processing has completed with no errors.

Need to rewrite how this works. Currently we call the whole script again, passing along the arguments that come after the -p/--post option. I think the correct thing to do is to move the post_processing options into a function that can be called by either the post mode or the stop mode, allowing them to be set from either and thus preserving the common options (and allowing them to come later in the line for the stop mode as well).