1 Reply by arnopluk

(36 replies, posted in General)

Hello danielbenja,

Google translate version:
Esto se parece al error que describí aquí: https://www.kinovea.org/en/forum/viewto … 4204#p4204
Quizás esto te ayude.
Solución 1: Habilite el acceso al micrófono (en Windows-Settings-Privacy-Microphone).
Solución 2: Desactivar el dispositivo de entrada de audio en su conjunto (en Windows-Settings-Audio).

English version:
This looks like the bug I described here: https://www.kinovea.org/en/forum/viewto … 4204#p4204

arnopluk wrote:

PROBLEM
In Windows privacy settings you can disable access to the microphone. When this is the case, Kinovea 0.9.1 crashes when you try to open the 'settings' menu. The fact that you cannot enter the 'settings' menu, makes it impossible to properly work with Kinovea.
The error from JIT that is reported is posted (in Dutch) in the Github link above. The logfile shows no error.

Workaround 1: Enable access to the microphone (in Windows-Settings-Privacy-Microphone).
Workaround 2: Disabling the audio input-device as a whole (in Windows-Settings-Audio).

Maybe this helps you.

Go to forum: General

2 Reply by arnopluk

(8 replies, posted in Bug reports)

Thanks for the quick reply and fix!

Go to forum: Bug reports

3 Reply by arnopluk

(8 replies, posted in Bug reports)

Below an example of part of my tool. The points in this image are 200 pixels from origin, the textdistance and radius is also set to 200.
https://www.dropbox.com/s/z66fl6uo7effx … e.png?dl=0

Go to forum: Bug reports

4 Reply by arnopluk

(8 replies, posted in Bug reports)

Hi Joan,
Thanks again for the updates:

It seems that the documentation for the custom tools has been moved? The link you provided above (http://www.kinovea.org/en/creating-a-custom-tool/) is dead now.

In the newest version (0.9.1) some changes have been made to the custom tooling.
Two changes I have seen so far:

1. New way of creating points (old way still works):

<Points>
    <Point name="Origin centre" value="200;200" color="#FFFF00" />
</Points>

2. The example and explanation above about the '<DefaultOptions>' don't work any more in 0.9.1.
Options can now be declared separately and given a 'default' status in the following way:

<Options>
    <Option key="15deg" label="15 degrees"  default="true"  hidden="false" />
    <Option key="30deg" label="30 degrees"  default="false"  hidden="false" />
    <Option key="showLabel" label="Show labels"  default="false"  hidden="false" />
</Options>

Options can also be combined now (don't know if that was already the case):

optionGroup="showLabel|15deg" <!-- Shows if showLabel option AND 15deg option are both selected -->
optionGroup="showLabel|30deg" <!-- Shows if showLabel option AND 30deg option are both selected -->

One question I have left:

1. Position of the text for angles

There is now a "textDistance" attribute on the angle node.

<Angle origin="1" leg1="2" leg2="3" signed="true" ccw="true" supplementary="false" radius="0" textDistance="40" tenth="true"/>

What is the unit of 'textDistance' and 'radius'? If I have segments of 200 pixels long and radius and textDistance set to 200; the radius and text are displayed at +/-55% of the line segments.

Go to forum: Bug reports

5 Topic by arnopluk

(1 replies, posted in Bug reports)

I posted this issue also on Github (https://github.com/Kinovea/Kinovea/issues/5), but since more people are using the forum I thought I post it also here:

PROBLEM
In Windows privacy settings you can disable access to the microphone. When this is the case, Kinovea 0.9.1 crashes when you try to open the 'settings' menu. The fact that you cannot enter the 'settings' menu, makes it impossible to properly work with Kinovea.
The error from JIT that is reported is posted (in Dutch) in the Github link above. The logfile shows no error.

Workaround 1: Enable access to the microphone (in Windows-Settings-Privacy-Microphone).
Workaround 2: Disabling the audio input-device as a whole (in Windows-Settings-Audio).

Possible solution? Extra checks on audio device when opening PreferencePanel.

Go to forum: Bug reports

6 Reply by arnopluk

(9 replies, posted in Bug reports)

I added a flag to the ValueChanged event from the Nud to prevent it from recursively updating the slider.

I created a Pull request in Github for the changes I made in the code. Please feel free to check and comment on it.

Go to forum: Bug reports

7 Reply by arnopluk

(9 replies, posted in Bug reports)

I agree that seconds is a more natural setting for delay. Lets try to make that work.

I hadn't considered the usecase 'capture latency' (or synchronisation) for the delay. This would indeed be better with a logarithmic scale (or maybe this is fixed by using the nud?).

I think I narrowed the problem down to a loop in updating values:

SldrDelay_ValueChanged
--> calls: presenter.View_DelayChanged
--> calls: DelayChanged
--> calls: view.UpdateDelay (with delay in seconds recalculated from pipeline frequency)
--> calls: UpdateDelayLabel
--> changes: nudDelay.Value , so calls: NudDelay_ValueChanged
--> changes: sldrDelay.Value , so calls: SldrDelay_ValueChanged (with delay recalculated from a different framerate)

Go to forum: Bug reports

8 Reply by arnopluk

(9 replies, posted in Bug reports)

Thank you for the update. It works perfect for me now!

In 0.8.25 I proposed a fix to update the delay when changing delay with the hotkeys. This doesn't work anymore (seems to be due to the nud), setting the delay in the slider is also very buggy because of this.
The old fix should be removed. I'm working on a new fix (using sldrDelay.Force(value) works for the hotkeys, but not for the nud).

In my opinion the nud should have a fixed maximum (now calculated from framerate, so changing over time?), and maybe everything should be in frames instead of seconds for the nud?

Next to that, I would suggest to change the slider for the delay to a linear slider.

Go to forum: Bug reports

9 Reply by arnopluk

(9 replies, posted in Bug reports)

Hi Joan,
I just noticed that you have updated the build environment to something feasible. Thank you very much for that. I immediately tried the latest Kinovea version from github!
The recording results from the delayed video stream are indeed much better. I now get the expected 30 fps recording. However, unfortunately the display framerate is very low (1 fps). From the logfile I get

CaptureScreen - Nominal camera framerate: 0 fps, Monitor framerate: 59 fps, Custom display framerate: 30 fps, Final display framerate: 1 fps.

The cameraGrabber.Framerate == 0 for some reason, I haven't found where that info comes from.
If I change the code in Kinovea.ScreenManager.CaptureScreen.Connect2() (line 609-611) it works for IP camera's, but I don't know enough about the details to say this is an actual fix:

double slowFramerate = Math.Min(displayFramerate, monitorFramerate);
double framerate = cameraGrabber.Framerate;
if (framerate == 0)
    framerate = pipelineManager.Frequency;
if (framerate != 0)
    slowFramerate = Math.Min(slowFramerate, framerate);
// slowFramerate = Math.Min(slowFramerate, cameraGrabber.Framerate);
slowFramerate = Math.Max(slowFramerate, 1);

Go to forum: Bug reports

10 Reply by arnopluk

(9 replies, posted in Bug reports)

Hello Joan,

The 'signal' field shows 29.9-30.1 fps received, so that seems to be okay (camera is even capable of 1080p50). If I record the video stream directly in Kinovea, it records the correct 30 fps, so the harddisk is also not the bottleneck.

Good to hear that you are working on the delayed recording for the next version. Do you have any idea when the newest version would become available? I would love to test the new delay features.

Go to forum: Bug reports

11 Topic by arnopluk

(9 replies, posted in Bug reports)

Hello Joan,

Recently I stumbled upon some strange things with the timing of the delay. I'm using Kinovea 0.8.27 with an IP camera 1080p30.
When I open the video stream there is an initial delay of around 0.3 second, because an IP stream is not 100% realtime (this is expected behaviour). The reported framerate is 'stable' at 29.9-30.1 fps. Display framerate is set at 30 fps.

Now when I increase the delay to 1800 frames (60sec @30 fps), the actual delay in the video is around 85 seconds.
https://i.ibb.co/WWLkqGV/Kinovea-Delay-issue.png

When I record the delayed stream, I get around 21 fps recorded (so the playback is way too fast).

If I now change the display framerate from 30 fps to 21 fps (and reset the delay to 60s@21fps==1260 frames), the actual delay in the video is the correct 60 seconds. and playback of a new recording is at normal speed.

Proposal for 3 changes:
1. Indicate the actual display framerate in the statusbar on top of the video.
2. Fix the delay slider timing+frames to the actual display framerate, so the reported delay is correct.
3. Set the correct fps (actual display fps) in the header of the recorded video.

Go to forum: Bug reports

12 Topic by arnopluk

(8 replies, posted in Bug reports)

Hello Joan,

I'm playing around with the custom tools, a very nice feature of Kinovea! I'm using Kinovea 0.8.26 64bit.
Unfortunately, I couldn't find that much documentation about the xml format of the files. So far, I've run into a couple of things I can't get a grip on right now:

  • Is it possible to specify the position of labels for angles (like 'radius')?

  • With 'optionGroup' you can specify options which can be selected by the user. Can you specify the default options which are used? (In Human Model 2 I found the keyword 'DefaultOptions', but no example how to use it.)

  • I would like to have 2 constraints in effect for my handle: 1. Fixed length ('DistanceToPoint') and 2. Rotation in steps of 5 degrees ('RotationSteps'). However, only the constraint that is configured last, is used by Kinovea.

  • Is it possible to lock handles so they can't be changed by the user?
    For example: Lock the angle-to-vertical of a certain line, while allowing a user to change its length.

  • Can the position of annotation in the capture screen be saved?
    For example: Default annotation in a fixed-camera setup.

  • (edit) How can I make my own icons for the custom tools?

Regards,
Arno

Go to forum: Bug reports

13 Reply by arnopluk

(4 replies, posted in Ideas and feature requests)

+1 for this feature request:
Support for h264 streams (through VLC backend?) would be a huge improvement of Kinovea, since all modern ip-camera's stream h264 instead of MJPEG.

Go to forum: Ideas and feature requests

14 Topic by arnopluk

(1 replies, posted in Bug reports)

I am using a live camera feed with maximum delay (15s 1280x720@30fps). When I record from the live feed and I open the video for playback in a second window, the maximum delay is cut in half (7,5s 1280x720@30fps).
The slider and the text don't update and the delayed stream freezes (for 7,5s). This can be resolved by clicking inside the slider.
When closing the second (playback)window, the maximum delay goes to 15s again, but the video freezes again for 7,5s (buffering the feed of 7,5-15s).

My main issue lies in the fact that the maximum delay is cut in half, the GUI updating is not that important.

(If I find some more time to look into this issue, I will also post some log-files).

Go to forum: Bug reports

15 Reply by arnopluk

(44 replies, posted in General)

Hello Joan,

Thank you for the great work on Kinovea so far. I am very interested in the 0.8.26 version of Kinovea, since it solves two issues I have been dealing with: 64bit buffer for delay; and recording of buffered video.

Next to those issues, I have found a small bug in the implementation of the hotkeys (in all versions I've tested):
When you use the keyboard to increase or decrease the delay, the GUI updates, but the actual delay isn't changed. In the code (below), the value is changed and the control is invalidated, but a 'ValueChanged' event is lacking.

In CaptureScreenView.cs (Ln 380-388):

                case CaptureScreenCommands.IncreaseDelay:
                    sldrDelay.Value = sldrDelay.Value + 1;
                    sldrDelay.Invalidate();
                    break;
                case CaptureScreenCommands.DecreaseDelay:
                    sldrDelay.Value = sldrDelay.Value - 1;
                    sldrDelay.Invalidate();
                    break;

Unfortunately, I can't get source code compiled in Visual Studio Community 2017 (.NET 4.7), so I can't propose a (tested) fix for this.

In SliderLogScale.cs (Ln 58-68):

        public double Value
        {
            get { return val;}
            set 
            {
                val = Math.Min(Math.Max(value, min), max);
                ValueChanged(this, EventArgs.Empty);                       // Changed
                Remap();
            }
        }

Kind Regards, Arno

Go to forum: General