Search options (Page 60 of 135)

Are you working with AVCHD / H.264 videos perhaps ? There are several issues with them that haven't been addressed yet.

Depending on the flavor of the encoder and the parameters used, they are more or less critical. Sometimes the working zone in/out points can't be set properly.

Upcoming in Kinovea
The configuration dialog now shows the various available stream formats (RGB24, MJPG, H264, etc.). On the C920, this allows the use of the streams that are compressed on-board by the camera, decreasing the bandwidth requirements.

For some specific stream formats (currently RGB24 and MJPG), the DirectShow's Intelligent Connect is not used and the plumbing is done manually. This has proven to be more reliable.

The vendor-specific exposure property from Logitech is now supported, allowing the configuration by 100µs increments instead of the default DirectShow property which is imprecise and badly supported by Logitech cameras. On the C920 the minimum value is 300µs.

A new capture pipeline has been implemented and integrated to streamline capture and recording.

For the MJPEG stream of the C920 and other cameras, the frames received are only decompressed for the preview. When recording they are directly pushed to the final file. The recording is given higher priority than the preview where a frame drop is not catastrophic. This greatly increases the throughput. I am able to record the full 1920x1080 @ 30 fps on my machine. We are still doing tests with Milan for the dual record scenario.

MJPEG is probably going to become the application perferred codec for output. It is simpler to implement and debug, mature JPEG libraries can be used, and its intraframe-only compression scheme makes it more suitable for frame-by-frame playback.

Thanks for the report.
Many cards from AVerMedia are advertised as "DirectShow compatible" which seems to be in contrast to other brands. Do you have any experience with these ?

Hi,

You can export the calibration parameters from within the calibration dialog using menu File > Save. The default directory is under "CameraCalibration" in the application data directory. Then from the second PC open a video, open the calibration dialog again and do File > Open and point it to the xml file.

To be clear, when you "Open" or "Save" it uses Kinovea format. When you "Import" it imports Agisoft Lens format. You can also directly reuse the Agisoft file and import it from the second PC.
You need to open/import it for each video.

The same file can be used for the same camera as long as the camera configuration doesn't change focal length, aspect ratio, etc.

For example on the PS3Eye there are two zoom positions by turning the ring.
On the GoPro depending on the configuration you can end up in Wide or Medium, 170° and 127° respectively I think. A different file is needed.

Technically each camera unit will have slightly different values. For example one of the computed parameters is the center of the lens relatively to the center of the sensor. It will not be exactly the same from one camera to the next.

That being said, the error introduced by these microscopic differences is probably less than the error of the calibration process itself, and less than the error introduced during coordinates digitization. So it may be fine to reuse a file created for a different camera unit unless you are already in an extremely controlled setting.

I'll gladly publish contributed calibration files on a dedicated page on the site so we can share them and experiment. Send them to joan at kinovea dot org and add details on the configuration with which they were created. If you validate that they also work at other configurations please mention it as well.

With regards to flipping, it's a known difficulty with DirectShow. Some formats needs to be flipped, others not.

Currently the code assumes the image is flipped (as it should for RGB24) and during the creation of the bitmap it inverts it. As it works on other machines I believe that assumption is correct but maybe there is another filter upstream that makes a faulty conversion…

Ooh, very interesting :-)

I am deep into the capture code these days so this case is of utmost interest.

Basically it should work like this :
1. The camera driver exposes a number of formats that it supports, usually what the camera can source.
2. The capture code creates a "Sample Grabber" specifying format RGB24.
3. The capture code calls DirectShow to connect the camera driver to the sample grabber, and DirectShow adds the necessary converters inbetween (the path to go from source to destination might have several steps).
4. During capture, samples are grabbed in RGB24, a Bitmap object is created with the sample inside, and the bitmap is sent downstream to the rest of the code.

In 1, the source format from the driver can be RGB24 already, but usually it's in some form of YUV format like YUY2, I420 (a list here). It may also be in a compressed format if the camera has on-board compression (MJPEG or H.264).

What might happen is that DirectShow cannot find the proper color space converter to go from the YUV format to RGB24, but normally if there is no match the connection fails entirely.
Another possibility is that it can find the proper color conversion chain but somewhere something is interpreting the source wrongly.

I think I still have a working PS3Eye, I'll also see if I can find something.
I don't know if the CodeLabs driver is based on the Microsoft UVC driver like for most cameras, I'll check that later.

If you want to start to investigate, you can download GraphStudioNext. Add your camera and look at the properties of the output pin.

Some more experimentations on my side…

Drivers
On Windows 7 there are two capable drivers giving slightly different options.
The Microsoft driver that installs itself by default, and the Logitech driver that must be installed manually.

The MS driver provides the stream in YUY2 (an uncompressed format), MJPG and H264.
The Logitech driver provides RGB24, I420 (two uncompressed formats), MJPG and H264. (These options will be available for selection in the next version). I haven't yet found what the actual native uncompressed format of the camera is.

However there is a catch, the official Logitech driver provides the H.264 stream in an unusual way (on a secondary pin of the DirectShow filter), which makes it invisible to Kinovea and to the majority of DirectShow based capture applications.

On the upside, when using the Logitech driver, it is possible to get and set the exposure duration with 100µs granularity, with a lowest value at 300µs.

Both drivers lie to some degree with the list of framerates they support. For example when using MJPG output, the drivers report that they support 7 framerates, from 5 to 30 fps, but whatever we choose, it will always use 30 fps.

DirectShow internals
When we connect to the camera, there is some black magic done by DirectShow to find a suitable decoder for the camera output down to the application. DirectShow will search the installed codecs on the computer and look for the best ones to complete the connection.

This means that when the camera is outputting H264 for example, there is a specific codec that is selected to provide the decoding. It may be a third party codec installed as part of another application or one provided with Windows. The performance of this codec has a direct impact on performance and image quality.

The problem is that codecs register themselves with a "merit" value that changes their likelihood of being selected.
More tests are needed to see if it would be practical to try to bypass this system completely or find a set of known-to-work-well codecs for various camera output formats, or at least detect which codec ends up being used.