ramsafin / lirs_ros_video_streaming Goto Github PK

ReadFrame on some cameras results in zero size buffers.
Here's the line where a zero size frame is created.

V4L2 controls API is needed to be able to change such properties as gain, exposure, etc.
See controls v4l2 docs for more info.

How it may work:

...
lirs::V4L2Capture capture("/dev/video0", ...);  // standard controls are utilized

capture.Set(ControlEnumWhatever, value);  // change control

Some controls require the streaming to be restarted (including new v4l2 buffers allocation).

Move v4l2 utils functions into the separate header file.
They are located at V4L2VideoCapture.cpp.

V4L2Utils structure is in lirs::utils namespace and should be renamed to the V4L2 structure inside this namespace. The reason is that the name is too long and inconvenient to use.

This issue is closely related to #5 and #6 where parameters of video capture can be changed in runtime. Those parameters include v4l2 controls (e.g. gain, saturation, whitebalance, etc.), frame resolution and frame rate (streaming process needs to be reloaded), and others.

Parameters could be changed either via service calls or dynamic reconfigure.

As Google C++ Style Guide suggests placing static functions inside some class is meaningless. Prefer creating a namespace instead.

Captured frames are published with the generated timestamp (ROS Time). However, for better synchornization, for example, when using two cameras for disparity map construction it is better if timestamps reflect real frames captured time.
[This question on stackoverflow] (https://stackoverflow.com/questions/10266451/where-does-v4l2-buffer-timestamp-value-starts-counting) demonstates that v4l2 drivers do not use realtime clock, so it should be converted somehow.

Dequeued v4l2 buffers may have zero size (bytesused field) as it mentioned in #8. Thus, to correctly detect if it is corrupted it must be checked using V4L2_BUF_FLAG_ERROR.

Most of the v4l2 cameras allow to choose different frame size, however some of the devices lack of this functionality. That is why, in case of large frame size and image format conversion load on CPU may become huge. So, in order to avoid issues related to large frame size, image downsampling functionality would be helpful.

Some of the ROS properties coming from launch files are ignored (i.e. pixel format).

Exception occurred during the process of initializing/capturing from v4l device are needed to be properly processed.

In case of EINTR dequerying of the buffers should be repeated as fast as possible without returning from the method. See this line.

Let's consider the code:

...
lirs::V4L2VideoCapture capture("/dev/video0", ...);
if (capture.IsOpened()) {
    capture.StartStreaming();
    // formats, frame, etc. rate are negotiated, buffers are allocated
    capture.Set(lirs::CaptureParams::FPS, 60);   // change the frame
}

In the code above frame rate is being changed during streaming process.
Currently, this change will be ignored. However, it is expected to change streaming frame rate in runtime. See v4l2 Buffer docs for more info on how it should be handled.