[Cin] my rendering is really slow
gorge rankin
nonoobspam at gmail.com
Fri Jul 16 19:44:52 CEST 2021
I'm going from top of my head, but iirc they've had a few versions of nvenc
so they're keeping the older around for backware compat.
On Fri, Jul 16, 2021 at 1:39 PM Andrew Randrianasulu <
randrianasulu at gmail.com> wrote:
>
>
> On Friday, July 16, 2021, gorge rankin <nonoobspam at gmail.com> wrote:
>
>> Sorry, just saw your note asking me to confirm if ffmpeg can do
>> h264/nvenc:
>>
>> cmd:~/cinelerra/thirdparty/ffmpeg-4.3$ ffmpeg -encoders
>>
>
>
> i think you need full_path/ffmpeg, for launching our self-compiled copy
> instead if system-vide one...
>
>
> Encoders:
>> V..... = Video
>> A..... = Audio
>> S..... = Subtitle
>> .F.... = Frame-level multithreading
>> ..S... = Slice-level multithreading
>> ...X.. = Codec is experimental
>> ....B. = Supports draw_horiz_band
>> .....D = Supports direct rendering method 1
>>
>> V..... libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4
>> part 10 (codec h264)
>> V..... libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4
>> part 10 RGB (codec h264)
>> V..... h264_nvenc NVIDIA NVENC H.264 encoder (codec h264)
>> V..... h264_omx OpenMAX IL H.264 video encoder (codec h264)
>> V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
>> (Intel Quick Sync Video acceleration) (codec h264)
>> V..... h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec
>> h264)
>> V..... h264_vaapi H.264/AVC (VAAPI) (codec h264)
>> V..... nvenc NVIDIA NVENC H.264 encoder (codec h264)
>> V..... nvenc_h264 NVIDIA NVENC H.264 encoder (codec h264)
>>
>
>
> strange, two, even three nvenc_h264??
>
>
>
>> So yes, it's built to handle it. Also, since I'm encoing 1440p videos in
>> realtime in RGBA mode, it has to be working, myh computer is not that fast
>> LOL
>>
>> Also in the nvidia control panel, and I can see this:
>> [image: image.png]
>> But the percentage will hit up to 30-50% many times.
>>
>> On Fri, Jul 16, 2021 at 1:19 PM gorge rankin <nonoobspam at gmail.com>
>> wrote:
>>
>>> 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/fee5bd02/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9735 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20210716/fee5bd02/attachment-0001.png>
More information about the Cin
mailing list