[Cin] Cinepack encoding - very slow!

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


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20191028/ff4589a1/attachment.html>