<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Andrea,  in a followup, to your email below.  Does this mean that the patch, ffmpeg_flush_tmp.diff, fixed ffmpeg 4.4 so that it works the same as 4.3?  I was confused if you had applied this patch or not or had just changed render formats.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 4, 2021 at 1:31 AM Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com">gamberucci.andrea@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">I have tried rendering in DNxHR_sq; ffv1 and VP9 and confirm that<br>
there are no issues with dropped frames.<br>
<br>
[Note (OT): if you remember my other tests with x265, the encoding fps<br>
were around 25 fps (T about 85°C). Even with VP9 they are around 24<br>
fps and in fact it is a compressed codec, LonGOP and interframe like<br>
x265. Instead DNxHR and ffv1 are codecs studied just for editing and<br>
their greater efficiency is evident. DNxHR rendered at 111 fps with<br>
much lower temperatures (67°C) and with a CPU occupation of 20-30%.<br>
Ffv1 rendered at 88 fps; CPU 40% and T 70°C (I'm not sure but it seems<br>
to me that it also uses the GPU). The difference with compressed<br>
codecs in terms of quality and efficiency is huge. Even on the<br>
timeline they are much more efficient and playback is smoother. The<br>
only disadvantage is that they produce files of 4.3 GB instead of a<br>
few tens or hundreds of MB.]<br>
</blockquote></div></div>