[Cin] Cinepack encoding - very slow!

[Andrew Randrianasulu]

В сообщении от 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!