[Cin] Two observations about screen recording via cingg

[Andrew Randrianasulu]

ср, 20 дек. 2023 г., 02:29 Phyllis Smith <phylsmith2017 at gmail.com>:

>
>> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20231220/fb7292d1/attachment.htm>