В сообщении от Tuesday 29 October 2019 01:25:52 Phyllis Smith написал(а):
Andrew:
I tried cinepack encoder, it was single-threaded, and for 720x400 movie fragment (25 sec) encoding was finished in 16 min, with nearly 4Ghz AMD processor!
Well, gg is adding the cinepak.qt opt file even though it is very slow. He ran the profiler (prof2) included in the CinGG git, and discovered that 89% of the time was spent in "avpriv_do_elbg" - an error minimization loop. Here is that code:
/* This loop evaluate the actual Voronoi partition. It is the most costly part of the algorithm. */ for (i=0; i < numpoints; i++) { best_dist = distance_limited(elbg->points + i*elbg->dim, elbg->codebook + best_idx*elbg->dim, dim, INT_MAX); for (k=0; k < elbg->numCB; k++) { dist = distance_limited(elbg->points + i*elbg->dim, elbg->codebook + k*elbg->dim, dim, best_dist); if (dist < best_dist) { best_dist = dist; best_idx = k; } }
Just out of curiocity I found this thread: https://forum.videohelp.com/threads/388428-Cinepak-video-encoding and there someone said official Cinepack encoder was also able to run very slowly :} ------------ Also, unlike Msv1, it has in its vfw and qt implementations, a bug where if you go above a certain bitrate it will slow encoding to a crawl (sometimes freezing altogether). ------------ :} so, may be not going into high-bitrate territory will save some time?
Also, I tried dca/MLP/truehd audio encoders from ffmpeg, but they all require 'strict=-2", and I got few BOOBYs along the way:
BOOBY! cin(_Z5boobyv+0x2f) [0x881369f] cin(_ZN13BC_WindowBase8draw_boxEiiiiP9BC_Pixmap+0x27) [0x8826767] cin(_ZN10BC_TextBox4drawEi+0x79) [0x87fe789] cin(_ZN16BC_ScrollTextBox6updateEPKc+0xd5) [0x8806e25] cin(_ZN15FFOptionsDialog17handle_done_eventEi+0x122) [0x8565ad2] cin(_ZN15BC_DialogThread3runEv+0xe9) [0x87b8d49] cin(_ZN6Thread10entrypointEPv+0x3f) [0x883bf1f] /lib/libpthread.so.0(+0x66f2) [0xf753e6f2] /lib/libc.so.6(clone+0x6e) [0xf70021ee]
Bummer on hitting the "Booby Trap". Neither gg nor I can catch this and this time he could not determine the cause and thinks it might have to do with the order in which the popup box is closed. If you produce it again and remember the order of the closure and how closed like clicking on the red X or the window x, let us know the steps to reproduce. GG does not want these boobies around.
May be you already fixed those :}
Trying to stop such ultralong encode via pressing single red X near rendering progress bar in main CinGG window not resulted in immediate stopping, it was doing something for few more minutes, I watched output file still growing with du -h file, but then end result was viewable in mplayer:
Yes, the above is true. The reason is probably that cinepak codec error minimization loop is so intensive, that it is busy and does not allow for handling the interruption.
Yeah, not much can be done about this .... Thanks!