Optimize sync of audio/video

[rfht]

With default values, there appears to be a small, but at times noticeable audio delay relative to video. I've worked around this with a negative audio offset argument (-a -0.2). Unclear if that's a universally "correct" audio offset for better sync, or if this may need to be approached differently.

[morgant]

Thanks for identifying this!

I'll re-review downloaded VODs from my most recent Twitch steams using PR #13 and see if I hadn't noticed a slight delay in audio from the start, despite confirming no de-sync drift over time (issue #5). Very likely since few of my streams are for gaming and, even then, usually retro games and I only encode/stream at 720p25.

I should have a recent VOD where I played Indiana Jones and the Fate of Atlantis in ScummVM, so that should allow me to identify a small delay.

Further notes-to-self, based on discussions with @rfht on IRC:

• I'm running lower-end hardware (dual-core i7)
• I've not tested with fauxstream's VA-API support yet
• I'm only capturing/encoding at 25 fps (as noted above)
• I do renice my fauxstream process group (including the ffmpeg child processes) a few seconds after executing it (currently using: renice -10 -g "$(ps -o pgid -p "$(pgrep -u "$DOAS_USER" -nf fauxstream | tail -n 1)" | tail -n 1)")

[morgant]

Laughing at myself while reviewing my Twitch stream VODs because I can't detect any audio offset, but it's a recording of me playing Indiana Jones and the Fate of Atlantis and I'm watching the pixelated mouths to see if they're in sync with the voice overs! "Looks good to me!" Obviously not a good example!

I'll have to do some new recordings with DOOM or something with more obvious synced audio.

In the meantime, @rfht, I wonder if you'd see any benefit from renice-ing (see my example above)?

[morgant]

Just did some testing with PR #13 recording a GZDoom window playing Venturous.

First test with no negative audio offset specified and no renice of fauxstream and it's ffmpeg processes has a definite delay.

Second test with no negative audio offset specified and using renice and there's less of a delay.

Third test with a -0.1 audio offset and renice, is pretty close, but it'd probably have been better with your -0.2 offset.

So, I do think we need to address the delay and maybe a default of -0.2 is appropriate. I'd also like to see if @rfht sees less delay when using renice or not.