ср, 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. > >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
