751 Reply by joan

(2 replies, posted in Français)

A priori non, pas directement compatible. Les flux de type H.264 ne sont pas supportés en capture (Uniquement MJPEG est supporté pour les caméras IP). Il y a des montages possibles avec un soft intermédiaire qui republie le flux localement en MJPEG mais c'est pas forcément génial (latence et recompression à prévoir).

Concernant l'USB il y a possiblité de passer par des adaptateurs USB<->Ethernet. Le flux est capturé à la sortie de la caméra, passe dans le réseau local (cable éthernet ou cablage mural ou CPL), ressort pas loin du PC et revient dans de l'USB avant d'entrer dans le PC. C'est normalement transparent pour les données.

Les ports USB sont effectivement souvent en déficit et il n'y a souvent qu'un seul "root hub" ce qui fait que les appareils sont en compétition pour la bande passante.

Go to forum: Français

752 Reply by joan

(28 replies, posted in General)

Hmm. I was going to write that there was an options in the preferences but I just realized this is still only in the unpublished version. I really need to get it out.

Go to forum: General

753 Reply by joan

(9 replies, posted in Bug reports)

Hmm, I hadn't realized they updated to Pylon 5.

I should have posted a follow-up in this thread anyway, back in November a color Basler camera was lent to me for a few weeks so I could fix the issues. I rewrote the Basler interop layer and we did some testing with Pieter and it worked fine for both of us. This was on the dev version of 0.8.25 which exists for x64 in addition to x86.

I've had trouble to get this version out of the way due to other commitments unfortunately. I see now that they made some major changes and it won't work anymore with Pylon 4, ouch.

The capture system is more or less organized in a plug-in manner, so maybe later we could have a capture module working with Pylon 5 that can be dropped in the install directory so that there is a solution for everyone. For now I think 0.8.25 will ship with Pylon 4 support only, and I'll look into v5 later.

Go to forum: Bug reports

754 Reply by joan

(11 replies, posted in Cameras and hardware)

Super. Thanks for the follow-up.
For the record we continued the discussion off-line and I sent coachmattb a preversion of 0.8.25 with a bug-fix for testing purposes.

For others with this issue (any network camera should have the issue really), a workaround in 0.8.24 should be possible, by going to the global capture preferences in Options > Preferences > Capture, and in "Display synchronization strategy", select "Camera frame signal" instead of "Forced framerate".

Go to forum: Cameras and hardware

755 Reply by joan

(11 replies, posted in Cameras and hardware)

In Kinovea you should use the direct URL to the MJPEG stream, something like http://192.168.0.45:8080/video for IP Webcam app.

There seems to be an issue with the display though, I also can't get a stable stream. Something must be broken…

Go to forum: Cameras and hardware

756 Reply by joan

(4 replies, posted in General)

If you install both using the installer they will share the application data directory and it could create conflicts as the preferences format is not the same.

The usual way to do this is to use the "portable" version for 0.8.24. This way it is completely self-contained and does not interfere.

Go to forum: General

757 Reply by joan

(11 replies, posted in Cameras and hardware)

No, Bluetooth is not involved. Wi-Fi should be turned on on both though.

Use the "Manual connection" button under the camera list and configure from there. The URL information should be found in the mobile app settings or documentation.

A web browser should also be able to connect to the stream, so you might want to test there to pinpoint the origin of the problem.

Go to forum: Cameras and hardware

758 Reply by joan

(6 replies, posted in Cameras and hardware)

By default it will only "see" (as in create a thumbnail for) the cameras that are connected directly to the computer.

For network cameras you have to use the "Manual connection" button under the camera list and configure the camera IP and access URL there.

Go to forum: Cameras and hardware

759 Reply by joan

(6 replies, posted in Cameras and hardware)

As far as I can see the camera streams H.264 which is not supported as an IP camera stream in Kinovea. Only MJPEG streams are supported.

Go to forum: Cameras and hardware

760 Reply by joan

(6 replies, posted in Bug reports)

Ok, that is strange and sounds like a bug. You should be able to see velocity as soon as a trajectory point has two neighbors, before and after, and acceleration as soon as it has four neighbors. So only the first and last points should be "###".

What happens when you display "Position" instead? Do you get anything?
Can you save to a KVA file and send it by mail please? (joan at kinovea dot org), thanks.
Can you right click the trajectory and go into "Data analysis" dialog. Do you get the position over time and other plots there?

Go to forum: Bug reports

761 Reply by joan

(5 replies, posted in Cameras and hardware)

The ELP has some advantages but it definitely has a lower image quality than the C920. There are some sample videos of the ELP at the bottom of the blog post, shot with not ideal lighting (as is often the case).

(I think you should be able to get the Logitech for less than 70€ now, as the price has dropped).

Go to forum: Cameras and hardware

762 Reply by joan

(4 replies, posted in Cameras and hardware)

I can't really comment on whether 480p is enough for your application. Try to find someone with a cheap webcam and see for yourself if it's acceptable.

Regarding gait analysis, one aspect to keep in mind is the USB bandwidth. I have seen at a podiatrics setup a lot of USB peripherals (gait platform, other specific devices, etc.) and it can create issues for the cameras if you want to have two of them streaming at the same time in addition to all the other devices.

Go to forum: Cameras and hardware

763 Reply by joan

(5 replies, posted in Cameras and hardware)

A C920 should give very decent results. You can configure stream, image size, framerate, exposure and gain directly in Kinovea. There is also special code to directly store the MJPEG stream to disk in order to reach peak performance during recording and avoid frame drops.
One drawback is that focus is built for room-scale and degrades a bit if the subject is at 5 meters or more.
I haven't personally tested the C930 but from all I've gathered there is no real advantage as far as filming sport is concerned.

Theoretically the Reflex would give a much better image but I'm not sure it will work at all. Does the HDMI output let you stream the live content seen by the sensor to a TV ? Or is it just to feed back videos previously recorded on the internal storage ? Also, video capture boxes haven't been tested and I haven't had any report that any of them work.

Go to forum: Cameras and hardware

764 Reply by joan

(6 replies, posted in Bug reports)

coxisambo wrote:

The only thing is that when you ask to show measure it shows position and displacement values, but for velocity, acceleration and their components it appear ### instead of numbers.

This usually happens when there aren't enough data points to compute the value. Since velocity and acceleration are derivatives and the data is filtered to remove noise, there is a minimum number of points that needs to be present before and after the position of interest in order to calculate the kinematic quantity at that point.

coxisambo wrote:

The white hand that moves during left button mouse clicked do not allow position the line on to the articular centre, it diminish digitizing precision. A cross or a transparent hand would be better.

Yes, fair point. Note that you can zoom in 600% with CTRL+mouse scroll, which should provide sub-pixel accuracy.

Go to forum: Bug reports

765 Reply by joan

(8 replies, posted in General)

Ah, maybe it wasn't clear enough about what the feature is supposed to do.

The image will not be undistorted, it is the coordinate system that will now take the distortion into account. So if you add a planar or perspective coordinate system, the coordinates used for positions, distances, angles, speed, etc. will be distortion corrected.

If you add lines or grids, you will see them bend along the distortion field.

Rectifying the images in real-time is costly and Kinovea architecture is not suitable for this as it is.

Regarding accuracy there could be arguments in both directions, on one hand it is better to use the actual pixels captured by the sensor for digitizing points rather than use the rectified images that will be interpolated. On the other hand a circular marker will no longer be circular at the image periphery which could limit the accuracy of automated tracking. Currently the philosophy is to respect the original image from the sensor as much as possible.

Go to forum: General