Implement V4L2 drivers to capture frames

[Rishikesh38]

Developing and implementing Video for Linux 2 (V4L2) drivers to capture frames, converts the frames to RGB, enhancing the functionality for seamless video frame acquisition in our project.

DoD: 1) The V4L2 driver should be able to successfully capture frames from the designated video source without encountering glitches or errors. Verify that the captured frames are of the expected resolution and format. 2) Implement code to convert the captured frames from their original format to RGB. Ensure that the RGB conversion does not introduce color artifacts or distortions. 3) Address and mitigate potential issues, including but not limited to: Blur Frames: Implement measures to reduce blurriness in captured frames. Blank Frames: Identify and handle cases where frames appear blank or contain no meaningful data. Startup/Warmup Frames: Implement mechanisms to handle frames captured during the startup or warm-up phase, ensuring they do not negatively impact the video stream. 4) Conduct thorough performance testing to ensure the driver operates reliably under various conditions. Assess the driver's performance with different video sources and lighting conditions to validate its robustness.

Blockers : Might get blur frames, blank frames, startup/warmup frames issue. The testing of this code can only be done when the sockets are implemented. So the above mentioned tested will be covered in here

[Rishikesh38]

I successfully implemented V4L2 drivers for capturing frames from a C270 web camera. The adapted code, integrates V4L2 API functionalities and includes features such as manual exposure control, continuous color transformation, and memory mapping for efficient frame capture. The camera drivers will be tested and validated for reliable image acquisition, in this issue here. The commits 92d7f02, f9840a9 and 966cde6 has the implementation of camera drivers .c and .h files.

[Rishikesh38]

I mentioned earlier that testing would be conducted on the socket programming issue (here). However, for writing wiki on V4L2 drivers, I had to ensure the functionality of the drivers before diving into socket programming. In this process, I utilized the drivers to capture images. Instead of sending these images over a socket to a client for verification, I opted for a local approach. I implemented a mechanism where the images captured by my drivers were dumped to the local file system. I then verified the functionality by confirming that the images were successfully captured and stored. NOTE : that these same drivers will be employed for capturing frames in the subsequent socket programming implementation.

The implementation can be found at commit d391cb8 Only see the testing_camera_drivers, because the server directory is for socket image transfer implementation which is still in progress. Within the testing_camera_drivers directory, there is a make file. To test the camera drivers, execute the "make" command, which generated an executable for the drivers. Following that, run "./camera_app" resulting in the capture and dumping of 30 frames into the "frames" directory(I am dumping 30 frames just to test the drivers). Below, I've included a frame that I capture for reference: here