[Cin] Two observations about screen recording via cingg

[Phyllis Smith]

>
>
> 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?
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, 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 likley will want to set
   the input frequency to 44100 and then everything should work smoothly.
   - Attempting to record 1440*900*24bit*30fps with cpu 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20231219/98d34650/attachment.htm>