oh, and I dropped down to cuda 10, that made no difference On Fri, Jul 16, 2021 at 1:18 PM gorge rankin <[email protected]> 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 <[email protected]> wrote: > >> ok, built it, but same issue, very slow. >> >> On Fri, Jul 16, 2021 at 2:45 AM gorge rankin <[email protected]> >> 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 < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Thursday, July 15, 2021, gorge rankin via Cin < >>>> [email protected]> 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 < >>>>> [email protected]> 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 >>>>>> [email protected] >>>>>> https://lists.cinelerra-gg.org/mailman/listinfo/cin >>>>>> >>>>>
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
