<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, August 3, 2021, Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com" target="_blank">gamberucci.andrea@gmail.com</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">The difference between appimage and build is that the former uses<br>
ffmpeg-4.3 and the latter ffmpeg-4.4. There is a small difference<br>
between the 2 renders, see mediainfo test-1.txt (appimage) and<br>
test-2.txt (build). It seems that ffmpeg-4.3 is more accurate. The<br>
real video source has 7500 frame (5min 0sec at 25 fps)!</blockquote><div><br></div><div><br></div><div>yeah, it seems last or 1 or 2 sec of stream is lost (</div><div><br></div><div>bad... </div><div><br></div><div>i'll look into ffmpeg's mail list and other projects to see if there anything easy enough to fix. </div></blockquote><div><div style="font-size:small" class="gmail_default"></div><br></div><div><br></div><div>I tried to slightly alter condition in FFStream::encode_frame</div></blockquote><div><span class="gmail_default" style="font-size:small"><b>The Bad News</b>:  In testing the attached patch, I could not find a difference in the video before and after or even with 4.3 versus 4.4.  I think <b>Andrea</b> needs to test this because he has a definitive case that shows the problem. I tested 3 cases but they are all little files -- I think I did some the drop of the last frames a couple of days ago, but I was concentrating on testing something else at the time and had to keep focus on what I was doing.</span> <br></div><div><div style="font-size:small" class="gmail_default"><b>The Good News:</b> Just a guess but if the root cause is found, it could conceivably be the problem with the bluray patch2 which was dropping the last few frames.<br></div><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>now it does not display flush errors at the end of encoding... if encode was much faster than timeline fps (still with 4.4)</div><div><br></div><div>problem is, for me encoded avi/mov actually have correct number of frames, i checked with mediainfo and internal cingg info window.. but i am on 32-bit arm machine... </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><br></div><div>for now it seems upgrade to 4.4 still not good idea... </div></blockquote></blockquote><div><span class="gmail_default" style="font-size:small">More testing needed -- I was really hoping to get 4.4 in the July 31 upgrade but was waiting to hear back from the freelancer on a bluray patch 2 fix  -- probably a good thing we held off.</span> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
PS: I think most users don't look at the messages on the terminal:<br>
appimage you have to specify it if you want to run from shell. If you<br>
compile from terminal, having multiple messages should not be a<br>
problem. In my opinion we can leave the messages without hiding them.<br></blockquote></blockquote></blockquote><div><span class="gmail_default" style="font-size:small">The messages do come in handy so I suppose it is better to leave them.  It is just now with AppImage, a lot of the users might just be typing in the executable from a terminal window instead of just clicking on an icon.</span> <br></div></div></div>