[Cin] my rendering is really slow

Fri Jul 16 19:19:59 CEST 2021

oh, and I dropped down to cuda 10, that made no difference

On Fri, Jul 16, 2021 at 1:18 PM gorge rankin <nonoobspam at gmail.com> wrote:

> some progress, So in short, it appears changing the workspace color format
> to YUVA-8Bit from RGBA-8Bit is where my slow down occurs.
>
> OK, so my videos are from OBS:
> color format: nv12
> color space 709
> color range: partial
> h264/nvenc/mkv
>
> so that's their defaults. those are under advanced, and I would assume
> normal users dont change such things.
>
> mediainfo reports the files as having yuv420 with color range of BT.709
>
> I get very fast rendering if cin has:
> Settings->Format RGBA-8Bit
> Render to yuv420
> Speed is 1 to 1 for the above with nvenc.
>
> However, if I use the above, then my files have too much brightness, the
> contrast and colors are off.
>
> So, I need to use to have my output files with proper color/bright. This
> is dramatically slower.
> Settings->Format YUVA-8Bit
> Render to yuv44p
>
> The only way to get my video's to look kind of like the originals in
> decent time
> Settings->Format RBGA-8Bit
> Render to yuv420p
> Add filters to adjust bright, colors.  This is way faster than using YUV,
> but obv slower than normal RBGA as I'm using filters now which slows things
> down some, but at least it's liveable.
>
>
>
>
> On Fri, Jul 16, 2021 at 3:24 AM gorge rankin <nonoobspam at gmail.com> wrote:
>
>> ok, built it, but same issue, very slow.
>>
>> On Fri, Jul 16, 2021 at 2:45 AM gorge rankin <nonoobspam at gmail.com>
>> wrote:
>>
>>> I'm building cin now as I type this.
>>>
>>> I just saw this when it was building ffmpeg,
>>> clang: warning: Unknown CUDA version. cuda.h: CUDA_VERSION=11030.
>>> Assuming the latest supported version 10.1 [-Wunknown-cuda-version]
>>>
>>> Maybe my CUDA is too new?
>>>
>>> On Thu, Jul 15, 2021 at 1:26 PM Andrew Randrianasulu <
>>> randrianasulu at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thursday, July 15, 2021, gorge rankin via Cin <
>>>> cin at lists.cinelerra-gg.org> wrote:
>>>>
>>>>> I've only been using cin for about 3 months.  I could have sworn I
>>>>> tested the render speed vs others and was happy.  This is just odd.
>>>>>
>>>>
>>>> may be some library/driver was updated system-wide...?
>>>>
>>>>
>>>>>
>>>>> I've tried the render farm idea as well.  Sometimes tho, I get an
>>>>> empty file.  Don't know why.  So I'm gun shy to try it for this project
>>>>> where I have 3 hours estimated, it's only 15 minute video, ugh.
>>>>>
>>>>
>>>> yeah, emoty files for renderfarm-locally sounds like bug. I think I run
>>>> into some odd behavior when I was playing locally (on arm/termux) with
>>>> renderfarm. Try to increase number of pieces for each job and timeout, too?
>>>> in preferences...
>>>>
>>>>
>>>>>
>>>>> There are no errors at all printed to the console if I launch cin from
>>>>> the terminal.
>>>>>
>>>>
>>>>
>>>>  odd...
>>>>
>>>>>
>>>>> The nvidia settings do show that about 5-8% load.  I'm used to seeing
>>>>> that at 50-60% in other editors and also in OBS.
>>>>>
>>>>
>>>> what setting you have for "Use HW device" in preferencies->performance?
>>>> only affect decoding.. What video outputt driver setting in Cin you use?
>>>>
>>>>>
>>>>> I know my pc is not "new" and the "fastest" but it would be faster if
>>>>> I were to make the compositor borderless and record that with OBS.
>>>>>
>>>>
>>>>
>>>> due to lack if hw encoding accel in termux (on android) I record with
>>>> system's  recorder, so this is... workaround...
>>>>
>>>>>
>>>>> It's really odd, the compositor isn't dropping any frames whatsoever.
>>>>> All my effects look *awesome * in the compositor.  The app is running
>>>>> awesome.  I've not had a crash at all.
>>>>>
>>>>
>>>> good, but slow encoding still a problem..
>>>>
>>>>
>>>>>
>>>>> On Thu, Jul 15, 2021 at 8:32 AM Andrea paz via Cin <
>>>>> cin at lists.cinelerra-gg.org> wrote:
>>>>>
>>>>>> Lately many people are experiencing performance problems in encoding,
>>>>>> I am one of them. I think the cause is the lack of multithreading in
>>>>>> encoding (but also decoding in timeline).
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> you can try to add printf("ff_cpus: %i, \n", ff_cpus) ; to few places
>>>> in cinelerra/ffmpeg.C and see if it was dropping down to 1 or 0 somewhat?
>>>> as crude hack you can force it to your number of threads....
>>>>
>>>>
>>>>
>>>> $ cat cinelerra/ffmpeg.C | grep ff_cpu
>>>>                                         avctx->thread_count =
>>>> ffmpeg->ff_cpus();
>>>>                         ctx->thread_count = ff_cpus();
>>>> int FFMPEG::ff_cpus()
>>>>                 avctx->thread_count = ff_cpus();
>>>> $
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>  A rendering done with
>>>>>> external ffmpeg from command line is much more efficient than the same
>>>>>> rendering done in CinGG (always using ffmpeg).
>>>>>> No fix has been found, only a workaround that makes use of the Render
>>>>>> Farm:
>>>>>>
>>>>>>
>>>>>> https://cinelerra-gg.org/download/CinelerraGG_Manual/Render_Farm_Usage.html
>>>>>>
>>>>>> Lately the user fary54 has made available his script to automate the
>>>>>> use of the render farm and external ffmpeg. Above all it is suitable
>>>>>> for CPUs with many threads. You can find the script and explanations
>>>>>> here:
>>>>>>
>>>>>> https://www.cinelerra-gg.org/bugtracker/view.php?id=575
>>>>>> --
>>>>>> Cin mailing list
>>>>>> Cin at lists.cinelerra-gg.org
>>>>>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20210716/57ba53ad/attachment.htm>