ср, 20 дек. 2023 г., 02:29 Phyllis Smith <[email protected]>:
So I guess especially for screencapture on slow CPU running short
pre-session capture will be useful to see if you can get same length tracks with given resolution/fps/codec and if no either drop down recording fps or try to speed up encoder settings.
Andrew, adding this to Manual Real-World in Appendix D. Did I miss anything or say something wrong?
May be add still working link to .asoundrc I googled 6 years ago? https://bbs.archlinux.org/viewtopic.php?id=147852 I added few more words in {} I wonder if this cpu-eating effect affect just my combo of kernel and hardware, or more widespread ...? I'll try my laptop too.
Using Screen Capture on slower CPUs
Some results with different settings when working on slower CPUs follow:
- You can enable "loopback mode" in alsamixer, set xmms (with ALSA output) to play {any alsa-enabled app should work}, and then you can record both video and audio. If your motherboard has no loopback switch for its integrated audio, you can use a specialized .asoundrc file set up as an alsa loopback instead. - If you leave recording settings to their default value of input frequency = 48000, you may get strange one-core cpu overload in kernel space. This will show up in the color orange if using the system monitor software, gkrellm (GNU Krell Monitors). So you most likely will want to set the input frequency to 44100 and then everything should work smoothly. - Attempting to record 1440*900*24bit*30fps with cpu { AMD FX 4300 } set to its lowest frequency of 1.4Ghz, usually results in video being shorter than audio, so try slowing video down to different values, such as 0.68 or so via speed curve, and then just clip the few last silent frames. - If you set the CPU up for performance and if you can rev it up to 4Ghz, then audio and video tend to be much more aligned in terms of their length. In one particular case with generally good results, the codec was mjpeg444 / s16le into a mov container on tmpfs. - Specifically for screencapture on slow CPU, running short pre-session capture will be useful to see if you can get same length tracks with given resolution/fps/codec. And if not, either drop down recording fps or try to speed up encoder settings. - In trying other positioning methods, apart from software timings, such as check/uncheck add/drop frames checkboxes and setting different number of audio samples ... , there seems to be no algorithm/code to intellectually duplicate frames that are too late in their encoding. And setting buffered frames in the device to absurdly high value like 50, was also not working for screencapture driver and short recordings like 20-25 seconds long. In conclusion, no amount of buffering will save you if you are chronically late.