<div dir="ltr"><div>oh, and I dropped down to cuda 10, that made no difference</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 16, 2021 at 1:18 PM gorge rankin <<a href="mailto:nonoobspam@gmail.com">nonoobspam@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>some progress, So in short, it appears changing the workspace color format to YUVA-8Bit from RGBA-8Bit is where my slow down occurs.</div><div><br></div><div>OK, so my videos are from OBS:</div><div>color format: nv12</div><div>color space 709</div><div>color range: partial</div><div>h264/nvenc/mkv <br></div><div><br></div><div>so that's their defaults. those are under advanced, and I would assume normal users dont change such things.<br></div><div><br></div><div>mediainfo reports the files as having yuv420 with color range of BT.709<br></div><div><br></div><div>I get very fast rendering if cin has:</div><div>Settings->Format RGBA-8Bit</div><div>Render to yuv420</div><div>Speed is 1 to 1 for the above with nvenc.<br></div><div><br></div><div>However, if I use the above, then my files have too much brightness, the contrast and colors are off.</div><div><br></div><div>So, I need to use to have my output files with proper color/bright. This is dramatically slower.</div><div>Settings->Format YUVA-8Bit</div><div>Render to yuv44p</div><div><br></div><div>The only way to get my video's to look kind of like the originals in decent time<br></div><div>Settings->Format RBGA-8Bit</div><div>Render to yuv420p</div><div>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.<br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 16, 2021 at 3:24 AM gorge rankin <<a href="mailto:nonoobspam@gmail.com" target="_blank">nonoobspam@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">ok, built it, but same issue, very slow.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 16, 2021 at 2:45 AM gorge rankin <<a href="mailto:nonoobspam@gmail.com" target="_blank">nonoobspam@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'm building cin now as I type this.</div><div><br></div><div>I just saw this when it was building ffmpeg, <br></div><div>clang: warning: Unknown CUDA version. cuda.h: CUDA_VERSION=11030. Assuming the latest supported version 10.1 [-Wunknown-cuda-version]<br></div><div><br></div><div>Maybe my CUDA is too new?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 15, 2021 at 1:26 PM Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank">randrianasulu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>On Thursday, July 15, 2021, gorge rankin via Cin <<a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>may be some library/driver was updated system-wide...? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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... </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>There are no errors at all printed to the console if I launch cin from the terminal.</div></div></blockquote><div><br></div><div><br></div><div> odd... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>what setting you have for "Use HW device" in preferencies->performance? only affect decoding.. What video outputt driver setting in Cin you use? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div><br></div><div>due to lack if hw encoding accel in termux (on android) I record with system's recorder, so this is... workaround... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.<br></div></div></blockquote><div><br></div><div>good, but slow encoding still a problem.. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 15, 2021 at 8:32 AM Andrea paz via Cin <<a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Lately many people are experiencing performance problems in encoding,<br>
I am one of them. I think the cause is the lack of multithreading in<br>
encoding (but also decoding in timeline).</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div></blockquote><div><br></div><div>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.... </div><div><br></div><div><br></div><div><br></div><div>$ cat cinelerra/ffmpeg.C | grep ff_cpu</div><div> avctx->thread_count = ffmpeg->ff_cpus();</div><div> ctx->thread_count = ff_cpus();</div><div>int FFMPEG::ff_cpus()</div><div> avctx->thread_count = ff_cpus();</div><div>$</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> A rendering done with<br>
external ffmpeg from command line is much more efficient than the same<br>
rendering done in CinGG (always using ffmpeg).<br>
No fix has been found, only a workaround that makes use of the Render Farm:<br>
<br>
<a href="https://cinelerra-gg.org/download/CinelerraGG_Manual/Render_Farm_Usage.html" rel="noreferrer" target="_blank">https://cinelerra-gg.org/download/CinelerraGG_Manual/Render_Farm_Usage.html</a><br>
<br>
Lately the user fary54 has made available his script to automate the<br>
use of the render farm and external ffmpeg. Above all it is suitable<br>
for CPUs with many threads. You can find the script and explanations<br>
here:<br>
<br>
<a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=575" rel="noreferrer" target="_blank">https://www.cinelerra-gg.org/bugtracker/view.php?id=575</a><br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>
</blockquote>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>