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;
}
}
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.
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.