On Friday, August 27, 2021, Andrew Randrianasulu <randrianasulu@gmail.com> wrote:


On Friday, August 27, 2021, Andrea paz via Cin <cin@lists.cinelerra-gg.org> wrote:
Compiled by git also applying the multibit patch. All OK.
Playback and various rendering formats: all OK; except cinepak.qt
which leads to a freeze. I remember it happened also with ffmpeg-4.3.


may be it just encodes _very_ slowly? like 20 min for ~1 min video with  320x200 sized frame... single-threaded... 
 
The "shape wipe" transition doesn't work, I'm not sure but I think it
didn't work before either. The other transitions work fine.


hm, strange.. can you try to debug this a bit (for example was it working in previous appimages/tagged releases?) 



I added the new plugins in expanders.txt; However, I think I broke the
formatting of the file and it gives me a dump at startup. Going back
to the previous expanders.txt gives no problems. I attach
expanders-dump.txt and the dump.


ow, dumps-on-startup  are bad ( (esp. if you can so easily create them, by editing text file). I hope this was something simple, like too small static allocation.... will look into code. 

PS: in plugin.opts i've corrected "dresser" in "deesser". I also
attach this file even though it's just a typo in one word.

For Andrew, who did not see my previous email, I attach the terminal
messages when I tried rendering with ffmpeg-4.4 (test.txt).

thanks 


well, in x265-10 bit encode we still see message about encoding 7499 (not 7500) frames (from x265 library itself) . I hope this is bug in reporting, but can you add some specific image/effect at this very end frame and try to play resulted encode with, say, ffplay? (i think it will freeze last frame on display)