<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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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/downl<wbr>oad/CinelerraGG_Manual/Render_<wbr>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/b<wbr>ugtracker/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<wbr>/mailman/listinfo/cin</a><br>
</blockquote></div>
</blockquote>