601

(3 replies, posted in Cameras and hardware)

Hi,
You need to use a win32 version of Kinovea for the PS Eye driver to work as it is itself win32 only. Maybe that's your issue? If you are using a recent beta version make sure you use the win32 variant.

You don't need a codec, Kinovea uses an embedded codec library. What version of Kinovea are you using? Try with version 0.8.27 and see if it works. The newer GoPros use an encoding that didn't exist at the time of version 0.8.15.

603

(8 replies, posted in General)

Hi,
Unfortunately it's unlikely that it can faithfully record 1440x1080@200 fps in this version, the bottleneck is during encoding at this point.

It writes 200 fps in the metadata of the file because that's the capture setting, but it's more likely that less than 200 camera frames are stored in the final file for each real time second. The second screenshot shows Drop counter at 768, that's the number of frames that had to be ignored to keep up, and weren't saved in the output. So the resulting file will play back faster than real life and may be choppy in places where frames are skipped.
Next version will have a mode where you can bypass the encoding step entirely and if the output to storage is fast enough it should sustain this kind of frame size and framerate.

604

(35 replies, posted in General)

Hi,

The most critical thing that will impact bandwidth is whether the camera is sending an MJPEG stream or full frames (any other stream format). For 1280x720@100, assuming RGB24 full frames, bandwidth shown in Kinovea should be something like (1280*720*3*100)/(1024*1024) = 263.67MB/s. This is how many bytes per second pass through the primary ring buffer, (not the same as the delay buffer, see diagram below).

So I'm assuming the 1920x1080@50fps giving 20MB/s was an MJPEG stream? (Assuming the framerate is respected by the camera, low light conditions will increase exposure time and decrease framerate automatically, other cameras let you select options that aren't supported and send low fps streams instead).

When using an MJPEG stream, the recording mode "Camera" will pass the MJPEG frames straight to the output, bypassing decompression/compression, so this is the fastest to record. Frames are decoded in a different thread for display.

When using an RGB stream, the frames are uncompressed for display/compositing and then recompressed for output, and this is taking some time. My understanding is that this is the current bottleneck.

I'm not sure about the truncation. I'll have to do my own experiments. Using 0-second delay vs using longer delay shouldn't really make a difference in terms of performance. The frames are sourced from the buffer in the same way. However there might be a laps of time where the buffer isn't full and there is no frame at the expected delay, in which case nothing will be output. Maybe this could explain the truncation and framerate difference?

Next version will have a mode for recording without compression whatsoever. This is only for the "Camera" recording mode at the moment. It increases performance for high bandwidth cameras that send RGB frames like USB 3.0 industrial cameras and possibly newer high end webcams. It takes a ton of space though.

I'm looking at options on how to improve the workflow. I think this self-training use-case is very interesting and Kinovea should support it. The difficult part is that bottlenecks vary depending people's machines, cameras, and over time as hardware and connection standards evolve.

Here is a diagram of the flow of frames during capture and recording [ edit: removed the link, this is very much obsolete now ] I did a while ago. Hopefully not too cryptic. In the diagram the "performance path" is when you select recording mode "Camera", and the WYSIWYG path is when you select "Display".

605

(35 replies, posted in General)

laskowskimaciej wrote:

And one more - is it possible to NOT showing the centre of the circle? (marked as "+")

At the moment it's not possible to remove it, but you're right, it should be optional.

crnkoj wrote:

Hey is it possible to use more than 2 cameras at once for simultaneous recording, couldnt really find the option anywhere.

No, it's not possible. There is currently no plan to add this in the near future.

606

(35 replies, posted in General)

Regarding USB it also has to do with USB root hubs. The USB port the camera is plugged into should ultimately be on its own controller so it can have the current and bandwidth for itself instead of sharing it with the other camera.

Yeah there is a heuristic when loading a file when both screens are already filled. Maybe the menu View > Invert video positions could help, it will swap the screens around, but it's not mapped to a shortcut key at the moment, sorry.

I think this relates to the behavior of the settings under Windows > Control panel > Region > Administrative > "Language for non-Unicode programs". Can you confirm if you guys have different values for this option? And if so, which one works?

One of the library for opening files doesn't have full support of Unicode and when it reads a file name it decodes it using a specific codepage, and I think this is where it may or may not work depending on whether that codepage is appropriate for the system locale.

Hi,
The same file fails to load from one drive and loads fine from another or are they different files?
Do you have unicode characters in the file name? Are the other drives network drives or local? Is the path to the file on the other drive very long, like more than 260 characters? Are you on a Mac with Windows emulation/dual boot or on a Virtual machine? What is your Windows version? Is it 32bit or 64bit? Do you see the thumbnails for the files when you navigate to the drive using the built-in explorer?

Could you get to menu Help > Open log folder and send me log.txt and log.txt.1 by mail at joan at kinovea dot org or see if you can locate any relevant error and paste them here?
Thanks

609

(3 replies, posted in Cameras and hardware)

Things to test: right click on the camera thumbnail and do "Forget custom settings".
If that doesn't work, go to Help > Open log folder then go in CameraProfiles and IDS and delete the file there.
Did you plug them back in the same USB ports? It's best to use ports that are on different USB root controllers so each can have the full bandwidth and power.

610

(1 replies, posted in Bug reports)

Please try with the beta version 0.8.27 from the download page. It should detect and rotate the video automatically or you can do it manually from menu Image > Image Rotation.

No it's probably a regression.

Please provide as many details for reproduction: what is the size of the original video, does it fit freely in the screen before the bug or is it forced to fit? Is it forced under its original size? Are you applying rotation manually? Is Kinovea applying rotation automatically? (check the image rotation menu), Do you get the problem with other videos, if not what is different?

Thanks

Reposting my answer in this thread:

When you click the "Manual connection" button the dialog window has fields for user and password.

In the end these get added to the URL like this: http://<user>:<password>@<ipaddress>:<port>/<resourcelocation>

When you click the "Manual connection" button the dialog window has fields for user and password.

In the end these get added to the URL like this: http://<user>:<password>@<ipaddress>:<port>/<resourcelocation>

614

(8 replies, posted in General)

You should be able to change the camera settings from within Kinovea, including exposure duration, framerate, resolution and stream format.

Regarding saving overlaid drawings, it is a regression. When you select the option to record what is displayed, it should paint the drawings on the frame before saving. I'll have to dig where the issue is coming from.

615

(8 replies, posted in General)

Thanks for the extensive feedback! To address some questions (the easy ones smile):

Reiner wrote:

What does Bandwidth in this context really mean?

Bandwidth here is the bandwidth between the camera and Kinovea. It depends on the image size, framerate and stream format. If the camera is configured to stream MJPEG directly, it will have much lower bandwidth. Maybe the ELP camera was configured to send uncompressed frames?

Reiner wrote:

- On my PC starting KINOVEA 64bit needs about 10 seconds. Starting it on a Parallels machine on my MAC, it needs about 1 second.

It should not take 10 seconds. Thanks for reporting this (people might not know what to expect so these types of issues are under-reported).

The first cold start takes about 3 seconds on my machine and the second start about 1.5s. The difference is the .NET framework being already loaded the second time around.

If you open the log, you will see each line starts with a number, it's the time in milliseconds since the start of the program. Can you send me the log or identify if there is a big jump in time and paste the surrounding lines? You have to scroll to find a start point. The first line says "xxx - DEBUG - [Main] - PreferencesManager - Importing preferences." and the first timestamp should be under 500ms.

Reiner wrote:

- In the 2 KINOVEA-setup, both KINOVEA-windows are used in resized position to fit the screen side-by-side. Is there any function available to fit the Video to the acquisition-window?

I am not sure if that's what you are looking for but if you double click the image it will try to fit to the display area.

Reiner wrote:

- is there any possibility to create an overlay that is store simultaneously during acquisition? It would be helpful for a „quick check“ of the performed movement. I.e. „swaying“ during a golf-swing.

I'm not sure to understand what you mean. Can you elaborate?

Reiner wrote:

- is there any chance to set the shutter speed of the camera? I guess, using the PYLON interface it should be possible.

Yes this depends on the camera. It should be shown as "exposure". It should be available on the ELP and the other one, as well as Basler and IDS cameras. Depending on the camera API the number will be in milliseconds (time the shutter stays open) or an arbitrary number.

Reiner wrote:

- would it be possible to rotate the video during ACQUISITION? I actual rotate the CAMERA 90° to better fit the golfer and use a rotate-command-line-option in VLC during playback.

I plan on looking into rotation of the camera stream shortly. I think 180° should be trivial because it doesn't change the aspect ratio. We'll see about the implications of the sideways rotations. (rotating the image is simple but then it breaks features that assume the image size is the same as the source…)