Search options (Page 61 of 136)

Thanks for the sample!
I reproduce the problem right away. Unfortunately at the moment I cannot fix it.

It is a unusual file in the sense that it actually has a variable framerate. Basically inside a video file, in addition to the global framerate, each individual frame has a timestamp. Here the video framerate is set to be 4fps, for 5526 frames (23 minutes). What Kinovea does when asked for the next frame is: 1. decode one frame and display it, 2. check the actual frame timestamp, 3. update the frame position in the timeline. This approach works to correct small variations or non integer frame intervals.

It doesn't work with this kind of videos because there aren't really 5526 individual frames. It might be an encoder optimized for screen capture. When the image doesn't change, no frame is saved in the video at all. Whenever the screen does change though, a frame is stored with the proper timestamp. Thus the sequence of timestamps is highly non linear and depends on the content dynamics. But when Kinovea reads the file back, basically being a constant framerate player, it jumps from frame to frame and eats the time gaps in between, giving a much accelerated result.

Please check with version 0.8.23 as the video decoding has been updated.
If the issue is still reproduced, could you send me a short sample for analysis. joan at kinovea dot org.
Thanks

Unfortunately I never got the chance to try and test an HDV camcorder first hand and see what the problem was. Now it seems all manufacturers have stopped producing them years ago, Firewire is no longer supported on new computers, etc…

Hello,
The calibration by line does not have any notion of horizontal or vertical. It maps a 2D distance in pixels to a distance in the specified unit. At the bottom of it it is just a scaling factor from pixels to centimeters or whatever. 2D distances are computed using the usual Euclidean distance.

This can give wrong results if you have a video with rectangular pixels that has not been automatically detected, (video looks squashed or stretched). More commonly, if the plane of motion is not perpendicular to the camera optical axis. For this you can use the perspective coordinate system.

Hi,
Please try this with 0.8.23. Both the dual screen synchronization code and the recording code have changed since.

Note that this type of error:

is specific to the home screen with the thumbnails. It is not super critical. It does hint at a problem, but it might not be related to your issue.

Some more updates

USB topology
If you plan on using several webcams or if you have a lot of other USB devices connected to your computer, it is important to understand a bit about the USB topology to get the best of your system.

I want to write a longer piece about this because it will be best with schematics. In a nutshell, you want to connect each webcam to a separate root hub so that it gets its full bandwidth and power.

USB works with host controllers (piece of hardware), root hubs (one per host controller), regular hubs and devices. A root hub will source several USB ports on the computer. All of these ports will share the bus bandwidth. Cameras need a lot of bandwidth so it's best if you connect them to ports that belong to different root hubs.

Do not bother connecting the camera to a regular hub. The camera will share the bandwidth with other devices on the same root hub in addition to the devices connected downstream to the hub. A bus powered hub will also usually not be able to source enough current to a camera connected downstream.

To better understand a comptuer USB topology, I like to use USB tree viewer, it will show you the whole USB tree from controllers to devices. It also shows low level USB descriptors which can help understand what capabilities are supported by a camera at the USB level, especially for UVC compliant cameras like the C920.

USB 3.0 ports won't provide increased bandwidth to USB 2.0 devices. There is an entire USB 2.0 compatibility lane inside the USB 3.0 pipe.