Search options (Page 40 of 133)

Yeah, it's strange. I had seen these AMCap screenshots.

Here is what I get in AMCap and Graphedit, on multiple computers.

Gain is also not supported. Exposure handling is sketchy.

My guess is @fajitas source video isn't MJPEG but H.264 so when asking for a specific time it lands on a non-keyframe, and the output is created with the first frame having missing reconstruction information and possibly a weird decoding timestamp if the file has B-frames (bi-directional prediction, info to rebuild the frame is stored in both adjacent keyframes). This trips Kinovea up. In any case I don't see how to turn this random frame into a full keyframe in the output without transcoding somehow...

In the next version there is a way to import a sequence of images as if it was a video, if they are named correctly like image001.png, image002.png, image003.png, etc. FFMpeg should be able to export that. Maybe an avenue to explore.

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.

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?

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.

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.