CAP_MODE_* enum, is supposed to be used as set(CAP_PROP_MODE, CAP_MODE_YUYV).

However this makes CAP_PROP_MODE ambiguous:

• the cap_libv4l implementation interprets it as "output mode" and returns YUYV images.
• the cap_*1394* implementations interpret it as "transmission mode" and always return BGR images. (even converting gray to BGR)
• the cap_v4l implementation also interprets it as "transmission mode", but treats it read only
• other cap_* implementations do not support CAP_PROP_MODE

looking at the documentation CAP_PROP_MODE we find:

Backend-specific value indicating the current capture mode.

therefore I think the cap_libv4l behavior wrong:

1. the call should result in YUYV transmission frames, but still return BGR
2. the currently available API for selecting output format is CAP_PROP_CONVERT_RGB, which allows to disable conversion and get the transmission format
3. the user actually should not be able to specify the output format at all - even though it may save a memcpy
   1. this would mean we have to move half of the cvtColor API to VideoCapture. CAP_MODE_YUYV implies COLOR_XXXX2YUYV - so CAP_MODE_Lab would make sense as well
   2. lets consider the transmission format is Bayer and the output is RGB. Which demosaicing algorithm should be used? Edge Aware, VNG, the fastest?
   3. Lets consider the user wants GRAY images and the possible transmission formats are MJPEG and YUYV. Which one would be more efficient for VideoCapture to select?

allowing to specify the output format requires a large amount of logic inside VideoCapture which does not belong there.

However there are advantages in adding a API similar to cv::IMREAD_GRAYSCALE to VideoCapture - yet the CAP_MODE_* values are the wrong way to do so.

I suggest removing or deprecating the CAP_MODE_* enum as long as cap_libv4l is still the only implementation understanding it.