These days, we have been working on dynamic library testing. H has written a written dynamic library-the library of the preprocessing module. The video processing project must be connected to the actual situation for testing.
Requirements:
1. Connect the actual camera, read the real-time data stream, and save it to the dual-loop linked list;
2. Test the functional effects of Background Modeling;
3. Pre-processing the four data (image) display results;
4. Test the real-time processing of multi-camera display.
I have been writing the camera data receiving module a few days ago, and the writing is still smooth, because I have written DVR multi-channel data receiving for projects I have done before, in addition, the real-time data of the Network Camera is read separately, so it is done in a day and the original image is displayed as normal.
Since H gave the interface documentation instructions, it took a whole day to directly call the dynamic library and update the background interface, and test the pre-processing module and display with opencv, in the evening, I wrote a dual-channel display for the next day, but it also showed that it was normal. However, I found a serious error in the afternoon. After running for a while, the program crashed and got depressed for several days, I tested many methods, which is also the biggest headache in the test program. In the end, it was found that the memcpy function accepted the inconsistency between the target and the source data size. The main reason should be that the device transmitted the size of the image and the image frame changed. I don't know why, (It may be because hikvision DVR is not compatible with hikvision cameras ). There was another interruption later, because it may have been deleted twice at the same time. Due to thread synchronization problems, the lock was added, and no problem was found. However, I used the copy constructor and it was no problem.
Problems found and summary of the test procedure:
1. First, you need to understand the functions of the program you write and understand the implementation requirements of the code you test;
2. analyze several classes and structures in your code to understand the functions, interface implementation, and logical structure;
3. Perform segmentation tests and perform module-based detection. Otherwise, it will be very troublesome;
4. Program pointers are very troublesome. You need to know what your pointers are doing, transfer between special classes, and record them well. Otherwise, release will lead to unexpected errors, and there will be no results during debugging for half a day;
5. Pay attention to initialization issues, otherwise it will be as depressing as 4;
6. IDE prompts are very important. Do not discard every error interrupt message. It may be the point where you want to modify it. This is my reason. I didn't pay attention to the vs interrupt prompt for errors. I was depressed for half a day, there is really no way to check the vs interruption error, which is indeed the reason;
7. In the end, the mentality is very important. Don't be impatient. Take it easy. I believe it will solve the problem. I can't think of it, But I may come up with it later.
I would like to share my experiences with this test library. Thank you.