Change libdc1394 library to support the desired camera
When it comes to free software, one of the arguments “for” is the ability to make changes to the code yourself. It seems to me personally that the end user does not care about this opportunity. And the matter can be not only in the absence of programming skills, but also simply in the lack of understanding that this is possible.
In this article I will briefly describe my experience of “finishing” the libdc1394 library for myself, or rather, for the camera with which I work. I suppose that the article may be interesting to those people who have never done anything themselves in third-party libraries and those who have to deal with firewire cameras in Linux.
The culprit of the celebration is the Flir infrared camera A40. The camera connects to the computer via the IEEE 1394 interface (hereinafter firewire). The manufacturer offers drivers for Windows, but does not support Linux. When connected to a computer, you can make sure that the camera is “visible” to the system, but you can only work with it at a low level.
The libdc1394 library provides high-level functions for working with a camera in Linux and supports any cameras that follow the IIDC / DCAM specification. With the use of this library written many programs working with cameras. This library does not “see” the connected A40 camera. Therefore, the first task is to determine the symptoms and possibilities. What can we learn about the camera?
')
It is logical to check the camera for compliance with the specifications. And it’s best to do it yourself, and not to trust the library. For this, the gscanbus program and the specification text are used. First of all, I tried to read the name of the camera and the manufacturer of the ROM. The information in the ROM is stored in blocks of 32 bits or, in other words, in quadlets (4 bytes). Address offsets are also indicated in quadlets. At first, it is confusing. For example, if we read the value of a , which is an offset, then in order to apply it in the gscanbus program, we need to add the value 4 * a to the base address.
After successfully reading the name of the camera and the manufacturer, it became obvious that the camera somehow, but meets the IIDC 1.30 specification. And here a natural question arises - why then the library libdc1394 cannot work with this camera? The specification defines several exact values. These values are checked by libdc1394 library when searching for cameras connected to a computer. One of these values is unit_spec_ID, equal to 0x00A02D. The A40 camera unit_spec_ID is 0x407F. Knowing this, the programmer needs to change the condition being checked in the library, and now she sees the connected camera.
A similar research procedure is conducted with supported formats. The camera feed returned zeros for supported formats and an error for unsupported ones. According to the specification, zeros indicate a lack of support.
After changing all the if'of it turned out that the picture comes, but "broken."
A survey of friends and Google could not help me. Working with a camera on firewire in Linux is not a very popular topic. It is worth adding that I saw how this camera worked under Linux on one computer. Unfortunately, I did not have access to it, I could not compare configurations and I had to reinvent the wheel. But I was sure that it was possible to invent a bicycle and that it would ride!
At this stage I had to study in detail the work of libdc1394 based on its sources. And at some point I paid attention to either the size of the packets received from the camera, or I peered at the contents of the resulting image in a hex editor and suspected something and turned to the size of the packets. It turned out that the camera, in addition to the data of the image itself, sends 40 additional bytes. At that moment everything became clear. Before sending a frame, the user must go through the packets that make up the frame, remove the extra 40 bytes from each packet and put the pieces together. The result is an image.
Wishing I send to the description of specific implementation with code pieces . Although Habr's policy does not welcome the reprinting of the material in other sources, the text that I wrote in English follows the link, as well as different from this article.
Unfortunately, the libdc1394 library developers do not want to support cameras that do not fully meet the specifications. My suggestions to add changes to the official code were ignored. And this means that when a new version of the library is released, its interface can change dramatically and camera support will have to be re-introduced.
In conclusion, I would like to say “fi” to companies that do not follow specifications and standards. And also I wish good luck to all who will encounter difficulties when working with video in Linux. Remember that if your camera “cannot be found,” then you may still be able to work with it after making changes to the libdc1394 library.
UPD. Transferred to "Linux for all."
UPD 1. Reliable Swiss hosting Origo ordered to live long. Unfortunately, the original wiki – page has not been preserved, but the libdc1394-flir patch itself has been posted on the githab
In this article I will briefly describe my experience of “finishing” the libdc1394 library for myself, or rather, for the camera with which I work. I suppose that the article may be interesting to those people who have never done anything themselves in third-party libraries and those who have to deal with firewire cameras in Linux.
The culprit of the celebration is the Flir infrared camera A40. The camera connects to the computer via the IEEE 1394 interface (hereinafter firewire). The manufacturer offers drivers for Windows, but does not support Linux. When connected to a computer, you can make sure that the camera is “visible” to the system, but you can only work with it at a low level.
The libdc1394 library provides high-level functions for working with a camera in Linux and supports any cameras that follow the IIDC / DCAM specification. With the use of this library written many programs working with cameras. This library does not “see” the connected A40 camera. Therefore, the first task is to determine the symptoms and possibilities. What can we learn about the camera?
')
It is logical to check the camera for compliance with the specifications. And it’s best to do it yourself, and not to trust the library. For this, the gscanbus program and the specification text are used. First of all, I tried to read the name of the camera and the manufacturer of the ROM. The information in the ROM is stored in blocks of 32 bits or, in other words, in quadlets (4 bytes). Address offsets are also indicated in quadlets. At first, it is confusing. For example, if we read the value of a , which is an offset, then in order to apply it in the gscanbus program, we need to add the value 4 * a to the base address.
After successfully reading the name of the camera and the manufacturer, it became obvious that the camera somehow, but meets the IIDC 1.30 specification. And here a natural question arises - why then the library libdc1394 cannot work with this camera? The specification defines several exact values. These values are checked by libdc1394 library when searching for cameras connected to a computer. One of these values is unit_spec_ID, equal to 0x00A02D. The A40 camera unit_spec_ID is 0x407F. Knowing this, the programmer needs to change the condition being checked in the library, and now she sees the connected camera.
A similar research procedure is conducted with supported formats. The camera feed returned zeros for supported formats and an error for unsupported ones. According to the specification, zeros indicate a lack of support.
After changing all the if'of it turned out that the picture comes, but "broken."
A survey of friends and Google could not help me. Working with a camera on firewire in Linux is not a very popular topic. It is worth adding that I saw how this camera worked under Linux on one computer. Unfortunately, I did not have access to it, I could not compare configurations and I had to reinvent the wheel. But I was sure that it was possible to invent a bicycle and that it would ride!
At this stage I had to study in detail the work of libdc1394 based on its sources. And at some point I paid attention to either the size of the packets received from the camera, or I peered at the contents of the resulting image in a hex editor and suspected something and turned to the size of the packets. It turned out that the camera, in addition to the data of the image itself, sends 40 additional bytes. At that moment everything became clear. Before sending a frame, the user must go through the packets that make up the frame, remove the extra 40 bytes from each packet and put the pieces together. The result is an image.
Wishing I send to the description of specific implementation with code pieces . Although Habr's policy does not welcome the reprinting of the material in other sources, the text that I wrote in English follows the link, as well as different from this article.
Unfortunately, the libdc1394 library developers do not want to support cameras that do not fully meet the specifications. My suggestions to add changes to the official code were ignored. And this means that when a new version of the library is released, its interface can change dramatically and camera support will have to be re-introduced.
In conclusion, I would like to say “fi” to companies that do not follow specifications and standards. And also I wish good luck to all who will encounter difficulties when working with video in Linux. Remember that if your camera “cannot be found,” then you may still be able to work with it after making changes to the libdc1394 library.
UPD. Transferred to "Linux for all."
UPD 1. Reliable Swiss hosting Origo ordered to live long. Unfortunately, the original wiki – page has not been preserved, but the libdc1394-flir patch itself has been posted on the githab
Source: https://habr.com/ru/post/86230/
All Articles