<br><br>On Monday, August 16, 2021, Phyllis Smith via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">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 dir="ltr"><div class="gmail_default" style="font-size:small">Checked into GIT 0042-Add-openEXR-format-for-<wbr>background-render.patch from randrik15 (or 0044 from randrik14) <br></div><div class="gmail_default" style="font-size:small">   -- this adds EXR Sequence as a choice in Settings->Preferences, Performance tab, for Background Rendering File Format</div><div class="gmail_default" style="font-size:small">Checked into GIT 0063-libvpx-disable-examples-<wbr>and-unit-tests.patchfrom randrik15 (or 0065 from randrik14)</div><div class="gmail_default" style="font-size:small">   -- this disables building unit-tests and examples in libvpx, thus saving quite a lot of disk space and some time <br></div><div class="gmail_default" style="font-size:small">   -- this required a change to the "multibit" compile patch to apply that patch correctly to thirdparty/Makefile<br></div></div><br><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">
Maybe it would be better to introduce the Cinelerra-CV method, in<span class="gmail_default" style="font-size:small"> </span>which you test single patch (or at least on a single feature), and<br>
then the result of the tests is discussed and possibly implemented.<span class="gmail_default" style="font-size:small"> </span>Only after that we move on to other patches....<br>
What do you think?<br></blockquote><div><span class="gmail_default" style="font-size:small">It is hard to keep up with Andrew's changes, but glad to have them so CinGG improves</span><span class="gmail_default" style="font-size:small"> and keeps up with the library releases.</span></div><div><span class="gmail_default" style="font-size:small">It would be easier to get one at a time though.</span></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">For example as long as I was applying the 0063 patch, I had to check  (1) 0032-Add-multilib-x265-slower-<wbr>compilation-but-you-can-ren.<wbr>patch (initial patch which was checked in as compile_multibit.patch to prevent confusion), (2) 0060-Add-x265-3.5-multilib-<wbr>patch3-should-be-faster-at-<wbr>com.patch (which seemed to remove "make"), (3) 0061-x265-patch3-was-<wbr>malformed.patch (which only seemed to add "make -j 1" back for 32-bit) and (4) 0064-sigh-i-deleted-make-in-<wbr>x265_3.5.patch3-restored.patch (which was such an interesting name !! and replaced "make -j 1 with "make").  Needless to say, I got a little lost.<br></span></div><div></div></div></div></blockquote><div><br></div><div>yeah, sorry ( there is git method for uniting few patches, but I haven't tried it yet.. </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 class="gmail_quote"><div></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">FFmpeg 4.4 update - the freelancer who "supposedly" had a fix for bluray patch2, got Covid and today said he was recuperating but still sent to fix.  Another freelancer who "supposedly" knows ffmpeg, is looking at the problem but does not expect a quick fix.  Bummer.<br></span></div><div></div></div></div></blockquote><div><br></div><div>ow, covid sounds bad ( thankfully programming is one of those activities you can do from home, still... there ususally some need  for food and household items.. </div><div><br></div><div>so,  stay safe! </div><div><br></div><div> </div>