451 Reply by joan

(42 replies, posted in General)

Dr.Dank wrote:

Something I didn't mention in my last post is that some of the videos only play until about halfway through. Converting to .mp4 seems to get around that problem, too.

vbendus reported a similar issue here: https://www.kinovea.org/en/forum/viewtopic.php?id=960

Are the video filmed with the default camera app on the iPhone or something else?

Go to forum: General

452 Reply by joan

(20 replies, posted in Cameras and hardware)

If you are used to version 0.8.15 note that the cameras now have their own tab in the explorer panel on the left. Instead of the old way of opening a capture screen first and selecting the source from its settings, you open the camera explorer and launch a camera from there (list or thumbnail) or drag and drop it to a capture screen.

Go to forum: Cameras and hardware

453 Reply by joan

(42 replies, posted in General)

Thanks for the sample, I can reproduce the issue right away. Already when advancing in the video there is a problem in the timestamps. It looks like after some point the timestamp is repeated and the next one is skipped. I'm not sure where this is coming from. I get the timestamp from the video decoding library.

As a temporary work around you could use the Tools > Linear kinematics window to export the data instead of Export to spreadsheet. The Linear kinematics window is newer and eventually the Export to spreadsheet function will be re-implemented on top of it. However this only lets you export one measurement at a time.

Another bug I see is that you have set a time origin but the trajectory times are still relative to the beginning of the video.

Go to forum: General

454 Reply by joan

(20 replies, posted in Cameras and hardware)

First of all please confirm you are using Kinovea 0.9.3 because the old 0.8.15 doesn't support the Pylon SDK.
The current version 0.9.3 is built against Pylon SDK 6.0. I haven't tested it against their latest 6.1.
Go to the log (menu Help > Open log folder, then open log.txt), in the first few lines after an empty space where the program restarts, you should find the camera initializations. There should be something like this:

932 - DEBUG - [Main] - RootKernel - Loading camera managers.
990 - INFO  - [Main] - CameraTypeManager - Initialized Basler camera manager.
...

If you have an error message instead of this please post it here or post the log or send the log at joan at kinovea dot org.
If you don't have an error message, can you see the thumbnail of the camera in the camera explorer?

Go to forum: Cameras and hardware

455 Reply by joan

(17 replies, posted in General)

I'm not sure what you mean by a pause of 9ms to 20ms, at 30 frames per second the frame interval is 33ms. Is the pause only when you replay the file now? Is it always at the same point in the video or does it change? Does the video speed decrease on its own?

Go to forum: General

456 Reply by joan

(36 replies, posted in General)

It's only to capture video at this point.

Go to forum: General

457 Reply by joan

(17 replies, posted in General)

Yeah, in one of the logs there is for example this:

Frame #100. Conversion/Encoding: ~1.010 ms. Write: ~1.890 ms.
Frame #200. Conversion/Encoding: ~0.790 ms. Write: ~1.750 ms.
Frame #300. Conversion/Encoding: ~1.480 ms. Write: ~1.680 ms.
Frame #400. Conversion/Encoding: ~1.580 ms. Write: ~1.960 ms.
Frame #500. Conversion/Encoding: ~0.850 ms. Write: ~1.590 ms.
Frame #600. Conversion/Encoding: ~1.430 ms. Write: ~39.580 ms.
Frame #700. Conversion/Encoding: ~0.830 ms. Write: ~1.730 ms.
Frame #800. Conversion/Encoding: ~0.920 ms. Write: ~1.730 ms.
Frame #900. Conversion/Encoding: ~0.830 ms. Write: ~85.980 ms.
Frame #1000. Conversion/Encoding: ~1.030 ms. Write: ~7.390 ms.

The last number is the average write time in milliseconds over 100 frames. But the most likely where it's 39 or 85 is that there is a single frame that was blocked for several seconds for some reason. I've seen the same pattern when I put the target directory on the system drive.

Go to forum: General

458 Reply by joan

(17 replies, posted in General)

So in the final recording there is a period of time where the time or frame counter advances but the image stays the same? Interesting. In that case that would mean the frames were duplicated at the source and the freezing would already exist either at the Pylon library level or the camera…

Could you send me a log file at joan at kinovea dot org? There is timing info while recording that could be interesting to analyze to see if there is a spike visible.

Other things to check:

- What version of Pylon have you installed, the module is based on Pylon 6.0.

- You can try to add a camera simulator in Kinovea by doing Manual connection in the camera explorer panel and changing the camera type. Then you can change the image size and framerate to match the real camera and see if the same problem occurs.

- It's also possible to add a camera emulator from Basler. In the Pylon viewer you can go to menu Help > Get help, and then to Software > pylon Camera software suite > Camera emulation and then under "Enabling Camera Emulation in the pylon API" they describe how to add camera emulators. Basically you need to add an environment variable in Windows named "PYLON_CAMEMU" with a value corresponding to how many emulators you want. When you do that they will appear in Kinovea as normal cameras and you can change the settings. The framerate probably won't really go as high as the real camera though.

Go to forum: General

459 Reply by joan

(17 replies, posted in General)

Thanks. And the drop counter in the info bar stays at 0 or it increases?

To summarize, the problem is that the display for the live camera (delayed) freezes for a moment, although the corresponding recorded file doesn't show a jump between frames. Is this correct?

One thing that can cause lower performance is when the target folder for recording files is on the same drive as Windows, as the system is regularly writing into its own files sometimes it competes for drive access. When I do this on my machine the live image freezes every 10 seconds or so and the drop counter increases. As soon as I move the target to another drive it works. (Both drives are SSD).

Go to forum: General

460 Reply by joan

(17 replies, posted in General)

Hi,
Please add more details: which version of Kinovea, which recording mode are you using (Preferences > Capture > Recording), whether you use record uncompressed video or not, which stream format in camera properties, whether you use delay in the viewer, what is the "Load" percentage in the info bar above the capture screen?

Go to forum: General

461 Reply by joan

(42 replies, posted in General)

I published a new version and changed the links in the original post. This update addresses a few important points, mainly 1. the crash at launch when installed over version 0.9.1 and 2. the inability to increase the memory buffer in the player.

Please continue to report any problem here.
Thanks!

Go to forum: General

462 Reply by joan

(7 replies, posted in Bug reports)

Stepping frame by frame in debug, the timing info inside the file is fairly consistent with having just 59 frames, somehow the last 20 frames or so are not reachable by normal means.

Is there a player where it fully works? I think the file is broken. When I open in VLC it just freezes on the first frame. In media player classic it shows the entire video but the timeline jumps back at zero halfway through. In the Windows 10 media app it shows the whole video but the timeline reaches the end after maybe a third of the video so seeking with the timeline is even worse. In the classic Windows Media Player the timeline is also completely confused. Some of these players may have less strict requirements on frame-to-timestamp coherence when they just want to playback the video. For frame by frame and accurate time computation Kinovea needs more consistency.

Did you use a particular application or mode on the phone to record it or did you modify it afterwards to trim the endpoints or other post-process? Like maybe a pre-roll or slo-mo feature?

Go to forum: Bug reports

463 Reply by joan

(7 replies, posted in Bug reports)

It's interesting to compare the behavior with version 0.8.15 which used a different way to get the timestamps. In that version the duration is computed wrong and the video goes all the way but then it loops back before the stated duration and the playhead continues and never loops back. It also completely breaks the working zone selector.

Go to forum: Bug reports

464 Reply by joan

(17 replies, posted in Cameras and hardware)

I have uploaded the firmware Waheeden shared with me at the following:

fix_frame_rate.zip

And the original firmware in case things go wrong:

standard_version_not_fix_the_frame_rate.rar

There are instructions inside on how to proceed. I haven't had time to try it myself yet.

Go to forum: Cameras and hardware

465 Reply by joan

(7 replies, posted in Bug reports)

Thanks for the sample.
It is one of those files where the first frame of the video has a negative timestamp, this throws off some calculations… Can you share what camera or process has generated the file?
It's probably fixable but needs care to not break other things in the process.

Go to forum: Bug reports