<br><br>On Tuesday, June 29, 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">Andrew, ok thank you.  It does not look like ffmpeg 4.4 is going to make it in this month.</div><div class="gmail_default" style="font-size:small">I am going to create new AppImages tomorrow because of the gang bug which is  too serious and has no workaround.<br></div></div></div></blockquote><div><br></div><div>no problems, I looked at bdwrite but it demands root and I am not yet root on this tablet. m2ts was created still... so, does this 'cut tail with ff 4.4 bug' exist for you in all resolutions/framerates as allowed by bd creation window? </div><div><br></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 dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><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"><div>also added two old (1996/8) h263 codecs - it theory they should be good for low-cpu decoding (on emulated computers for example), but apparently h263 without 'p' only good at few pre-defined resolutions? </div></blockquote><div><span class="gmail_default" style="font-size:small">Did not even know h263 existed.  I will test today since it is something I can actually do!</span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div>sorry for not making progress on more important issues - I fiddled around with overlayframe.h - but I can't see my addons working? Either bug in code or I translated those blend modes wrongly.. </div></blockquote><div><span class="gmail_default" style="font-size:small">No problem, everyone should just work on what is fun and interesting for them.  This bug has workarounds</span></div><div><span class="gmail_default" style="font-size:small">that are usable but tedious so we will have to tolerate that and it has existed for a long time.</span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div>there also two ffmpeg-4.4 patches recently added to git - they apply with patch -p1 yet not with git apply patch (misformatted patch).. Adds avc intra 300/480 if compiled against last x264 (15 june 2021) <br></div></blockquote><div><span class="gmail_default" style="font-size:small">For some reason, I did not make the connection that the new x264 required ffmpeg 4.4 and I tried to  upgrade</span></div><div><span class="gmail_default" style="font-size:small">to it yesterday.  But IMPORTANT QUESTION, the "stable" version, which is what we have always used in the past</span></div><div><span class="gmail_default" style="font-size:small">is dated around June 13th.  Would it not be better to continue that policy instead of using June 15?</span> <span class="gmail_default" style="font-size:small">  See</span></div><div><span class="gmail_default" style="font-size:small">attached and note the box in upper left hand corner saying "stable".</span></div><div></div></div></div></blockquote><div><br></div><div><br></div><div>in theory stable should provide stable(ish) api, but I just wanted to see if I can make this feature (new avcintra modes) works here.. </div><div><br></div><div>I think even ff-4.3 should be compatible with new x264, but w/o new features... </div><div><br></div><div>of course you can check out stable branch of x264... and test with this/ff-4.3 instead... I just  jump ahead of locomotive sometimes</div>