[CinCV TNG] OGV from recordmydesktop and Cinelerra's world -> errors/crashes

Good Guy good1.2guy at gmail.com
Wed Oct 26 21:59:23 CEST 2016


this is "round off error".  It always is possible in a finite system (all
computers).  It is possible to minimize the probability of a round off
error, but the issue can never be completely eliminated.  In this case,
ZoomBar::update_clocks() is updating the text boxes with the current
selection.   I created an example and captured it in the debugger, with the
following results (suitably trimmed of irrelevant debug output)

Run till exit from #0  LocalSession::get_selectionend (this=0x73e23a0,
highlight_only=1) at localsession.C:422
Value returned is $10 = 12.283999999999999
Run till exit from #0  LocalSession::get_selectionstart (this=0x73e23a0,
highlight_only=1) at localsession.C:408
length_value->update_position(mwindow->edl->local_session->get_selectionend(1)
-
Value returned is $11 = 4.7839999999999998

note that neither are "exact", but both are very close.  The normalized
mantissa of a double variable is 49 bits, which can represent 49 *
log(2)/log(10) = 14.75 digits.  The debugger output is over-specified to
help with the issues of round off errors, and is showing 16 fraction digits
(53+ bits).  Anyhow, these are subtracted for the selection duration, and
the result is used to update the selection length textbox as:

LengthTextBox::update_position (this=0x545f410,
new_position=7.4999999999999991) at zoombar.C:632

this is converted to the selected time units via Units::totext, and because
the current format is set to TIME_HMS, this code is used to display the
result:

176             case TIME_HMS: {
177                     seconds = fabs(seconds);
178                     hour = seconds/3600;
179                     minute = seconds/60 - hour*60;
180                     second = seconds - (hour*3600 + minute*60);
181                     seconds -= (int64_t)seconds;
182                     thousandths = (int64_t)(seconds*1000) % 1000;
183                     sprintf(text, "%d:%02d:%02d.%03d",
184                             (int)hour, minute, second, thousandths);
185                     break; }

Because all of these calculations use truncation (round down), the reuslt
is that it displays:
(gdb) p text
$21 = 0x5460a44 "0:00:07.499"

It is fairly common to try to round the least significant digit when
displaying a number.  Since there are always 3 significant digits in the
fraction, line 177 could be changed to:
177                     seconds = fabs(seconds) + 0.5e-3;
which will cause the fraction to be rounded to the nearest digit, instead
of rounded down.

Since you have put such effort into this, I will add these rounding
constants... but I have to say, it only moves the issue to another spot
(which may be less likely in fact to be an issue), but the problem is
inherent to all computers.  We all live with round off error.


gg


On Wed, Oct 26, 2016 at 11:06 AM, igor_ubuntu <sitelve at gmail.com> wrote:

>
>>
> 2016-10-26 18:01 GMT+03:00 Einar R√ľnkaru <einarrunkaru at gmail.com>:
>
>> On 10/26/2016 03:39 PM, Good Guy wrote:
>>
>>> It may be because the align cursor on frames setting is applied.  The
>>> cursor alignment is adding a frame in cases where the selection is not
>>> already frame aligned (this is a guess).
>>> gg
>>>
>>
>> 'align cursor on frames' cuts tracks to equival length.
>>
>> Einar
>>
>
> The same situation and without the settings "align cursor on frames"
> Look this screencast https://www.datafilehost.com/d/508b3520
> It shows strange behavior and a unstable calculation of selection length.
> I did not yet check your recent changes in git.
>
>
> _______________________________________________
> Cinelerra mailing list
> Cinelerra at lists.cinelerra-cv.org
> http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cinelerra-cv.org/pipermail/cinelerra/attachments/20161026/6bd63dd1/attachment.html>


More information about the Cinelerra mailing list