Changing the libdc1394 library to support the desired camera
When it comes to free software, one of the pros is the ability to make changes to the code yourself. It seems to me personally that the end user does not care much about such an opportunity. And it can be not only the lack of programming skills, but simply the lack of understanding that this is possible.
In this article, I will briefly describe my experience of “completing” the libdc1394 library for myself, or rather, for the camera with which I work. I suppose that the article may be of interest to those people who themselves have never edited anything 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 is connected 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 the camera in Linux and supports any cameras that follow the IIDC / DCAM specification. Using this library, many programs have been written that work with cameras. It is this library that "does not see" the connected A40 camera. Therefore, the first task is to identify the symptoms and possibilities. What can we learn about the camera?
It is logical to check the camera for compliance with the specification. And it’s best to do it yourself, and not trust the library. The gscanbus program and the specification text are used for this . First of all, I tried to read the name of the camera and the manufacturer from the ROM. Information in ROM is stored in blocks of 32 bits or, in other words, quadlets (4 bytes). Address offsets are also indicated in quadlets. At first, this is confusing. For example, if we read the value of a , which is the offset, then 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 apparent that the camera somehow meets the IIDC 1.30 specification. And here a logical question arises - why, then, the libdc1394 library cannot work with this camera? The specification defines several precise values. These values are checked by the libdc1394 library when iterating through cameras connected to a computer. One of these values is unit_spec_ID, which is 0x00A02D. The camera A40 unit_spec_ID is 0x407F. Knowing this, the programmer needs to change the checked condition in the library, and now she already sees the connected camera.
A similar research procedure is carried out with supported formats. The base camera returned zeros for supported formats and an error for unsupported ones. By specification, zeros indicate a lack of support.
After changing all if'of it turned out that the picture is coming, but “broken”.
A survey of acquaintances and Google could not help me in any way. Working with a firewire camera 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 either to the size of the packets received from the camera, or I peered at the contents of the resulting image in a hexadecimal editor and suspected something and turned to the packet sizes. It turned out that the camera, in addition to the data of the picture itself, sends another 40 additional bytes. At that moment, everything became clear. Before sending a frame to the user, it is necessary to go through the packets that make up the frame, remove the extra 40 bytes from each packet, and put everything together. As a result, we get an image.
I want to send to the description of a specific implementation with pieces of code. Although Habr’s policy does not welcome reprinting of material in other sources, the text that I wrote in English and also different from this article is by reference.
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 express “fi” to manufacturers who do not follow specifications and standards. I also wish good luck to everyone who encounters difficulties when working with video in Linux. Remember that if your camera “cannot be found”, then perhaps you can still work with it after making changes to the libdc1394 library.
UPD Moved to "Linux for all."
UPD 1. Reliable Swiss hosting Origo ordered to live long. Unfortunately, the original wiki page was not preserved, but the libdc1394-flir patch was posted on the github
In this article, I will briefly describe my experience of “completing” the libdc1394 library for myself, or rather, for the camera with which I work. I suppose that the article may be of interest to those people who themselves have never edited anything 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 is connected 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 the camera in Linux and supports any cameras that follow the IIDC / DCAM specification. Using this library, many programs have been written that work with cameras. It is this library that "does not see" the connected A40 camera. Therefore, the first task is to identify the symptoms and possibilities. What can we learn about the camera?
It is logical to check the camera for compliance with the specification. And it’s best to do it yourself, and not trust the library. The gscanbus program and the specification text are used for this . First of all, I tried to read the name of the camera and the manufacturer from the ROM. Information in ROM is stored in blocks of 32 bits or, in other words, quadlets (4 bytes). Address offsets are also indicated in quadlets. At first, this is confusing. For example, if we read the value of a , which is the offset, then 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 apparent that the camera somehow meets the IIDC 1.30 specification. And here a logical question arises - why, then, the libdc1394 library cannot work with this camera? The specification defines several precise values. These values are checked by the libdc1394 library when iterating through cameras connected to a computer. One of these values is unit_spec_ID, which is 0x00A02D. The camera A40 unit_spec_ID is 0x407F. Knowing this, the programmer needs to change the checked condition in the library, and now she already sees the connected camera.
A similar research procedure is carried out with supported formats. The base camera returned zeros for supported formats and an error for unsupported ones. By specification, zeros indicate a lack of support.
After changing all if'of it turned out that the picture is coming, but “broken”.
A survey of acquaintances and Google could not help me in any way. Working with a firewire camera 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 either to the size of the packets received from the camera, or I peered at the contents of the resulting image in a hexadecimal editor and suspected something and turned to the packet sizes. It turned out that the camera, in addition to the data of the picture itself, sends another 40 additional bytes. At that moment, everything became clear. Before sending a frame to the user, it is necessary to go through the packets that make up the frame, remove the extra 40 bytes from each packet, and put everything together. As a result, we get an image.
I want to send to the description of a specific implementation with pieces of code. Although Habr’s policy does not welcome reprinting of material in other sources, the text that I wrote in English and also different from this article is by reference.
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 express “fi” to manufacturers who do not follow specifications and standards. I also wish good luck to everyone who encounters difficulties when working with video in Linux. Remember that if your camera “cannot be found”, then perhaps you can still work with it after making changes to the libdc1394 library.
UPD Moved to "Linux for all."
UPD 1. Reliable Swiss hosting Origo ordered to live long. Unfortunately, the original wiki page was not preserved, but the libdc1394-flir patch was posted on the github