You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
Hi,
The first number on each log line is the total milliseconds since application startup.
The interface will be visible and fully responsive when you get to about this line:
797 - DEBUG - [Main] - FileBrowserUserInterface - Application is idle in FileBrowserUserInterface.
(So in this case a hot start, 0.797 seconds).
I made a change a few days ago that I think could help with this. I'll send you a message.
As an example, on my machine it takes ~2200 ms to get to this line on a cold start.
Hi,
I'm no expert in ffmpeg command line. The issue I believe here is that the timestamp of the first frame in the output file is non-zero, possibly negative. Kinovea definitely doesn't like that. There is an attempt at handling these in the next version but I tried your command and I still have the same issue as you.
Maybe there is a way to change the PTS of the output frames. Otherwise I think you'll need to transcode in order to turn that first frame into a keyframe. I'm not sure you can cut at that exact frame without transcoding since the decoder will always miss some data for it and would likely have to start at the next keyframe.
Not sure why the quality would degrade with -g, maybe it's using the same bitrate as in the original but now all frames are fully encoded so it degrades them to keep the bitrate promise.
I don't have a C922 but the configuration dialog should look approximately like this:
If you don't see Exposure, something must have gone wrong while looking for the properties. Maybe the driver is not up to date?
Make sure you set the exposure appropriately. For 60 fps you will need to set it lower than 16.6... ms. (Note: depending on the driver and some other things I'm not too clear about, this is sometimes displayed as an arbitrary number instead of milliseconds).
If you do not need to record the delayed stream, go to Preferences > Capture > Recording and make sure the option is set to "Camera". (Limitation that should be fixed soon).
When you say you are only able to record at 30 fps, do you mean that you cannot set the framerate higher in the camera configuration dialog, or that the "Signal" value in the infobar doesn't go higher than 30 fps, or that the resulting file looks to only have 30 frames per second even if it's marked as 60 fps?
Thanks for the log. Wow, 30 second cold start... That is horrendous indeed.
The reason hot start is faster is because all the DLLs and the .NET framework itself are already loaded in memory. I can see in the log that for each group of DLL loaded (the core application, the video modules, the camera modules, etc.) there is a big jump each time.
Now as far as I'm aware there could be two reasons as to why loading the assemblies the first time around is so slow.
1. The machine could still be loading other applications in the background at that point. This should be easy enough to test by waiting longer before attempting to start Kinovea, but frankly, I don't think this would cause multi-second loading times per DLL.
2. A resident antivirus is deeply scanning each DLL prior to letting them load to memory. That would be my best guess.
Do you happen to have McAfee or something of the sort installed?
I went ahead and started implementing the simplest option possible, and I realized I had already wrote that code a long time ago, I just had to flip a flag to enable it. (Barring some rounding issues I need to check).
So unless any counter-argument surfaces, this will be the new timecode format:
[h:][mm:]ss.mm[m]
Details:
- We always show the seconds.
- We only show minutes and hours if needed. (Based on the current time, not the total time).
- We show milliseconds if the framerate is over 100 fps.
- The separator between seconds and fractions of seconds is now a dot instead of a colon. (Follows ISO 8601). I now realize this may have been the most confusing thing about the old format.
This is much more convenient to use! Why nobody ever mentioned this? Sorry if I missed it.
There is still one shortcoming, when the video is over 1000 fps, milliseconds just won't cut it. And this is becoming more and more common, even from Kinovea's own capture screen. The work around at the moment will be to use the "Total microseconds" format. (Edit: or I'll just grab the log10 of the framerate to get the number of fractional digits required).
Edit2: ok the number of fractional digits is now proportional to the magnitude of the framerate so if you have a video filmed at 15 000 fps or whatever you won't loose any precision.
Hello,
Would love some feedback on the timecode format.
Considering the primary use case for Kinovea is short clips of under a minute, I feel the default timecode format is needlessly verbose and illegible.
I am considering the following options:
1. Automatically adjust to the magnitude of the video length.
- If the video is less than an hour, don't show the hours section.
- If the video is less than a minute, don't show the minutes section.
- Then, do as it is now: always show seconds and show hundredth or milliseconds depending on number of frames per second.
I didn't do this initially because I feared it wouldn't be clear what the values would be, but I don't think it's a valid concern anymore. This could also be made optional with a new option in preferences to force a fixed length timecode.
2. New formats options with max unit.
- You would tell the maximum unit you want to see.
- Currently this would be Hours, and there would be additional options for Minutes and Seconds.
- If you select Seconds and the video is more than a minute, it would still show seconds. (ex: 70 seconds).
Maybe there is a way to combine these two approaches.
High speed cameras are also more and more affordable and people use Kinovea with videos where the entire action happens in less than one second, so maybe there are also more options to have for this use-case.
Comments & ideas appreciated!
all the videos that are recorded from the display are sped up to about 120% of realtime.
Hi, it is a limitation of the performance of recording delayed video in 0.8.27. The speed up is because the recording process missed some frames. It should be fixed in the next version.
Assuming you are using 0.8.27.
There are two main things that will impact tracking "stickiness": the size of the search boxes and the use of markers.
When you use the regular track tool by right clicking an object and doing Track Path, you'll see the two tracking boxes. These can be resized from the track tool configuration dialog. You want the inner box to be tight around the object you are tracking so it doesn't pick background. The outer box is the search region, size this one based on the speed of motion or framerate, that is how much displacement the object can undergo in one frame.
The tracking on other tools like angle also uses these boxes but they are hidden. You can configure them from Preferences > Drawing > Tracking. So what you can do is use a normal track tool to figure out appropriate box sizes and then use that here.
Using markers will greatly improve precision and reduce loosing the tracking. It's pretty much mandatory for tracking joint angles properly.
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.
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.
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".
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.
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.
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.
Kinovea - Forums → Posts by joan