@alalek 👍

you should rather use CAP_PROP_FORMAT. see #5485

Thanks @paroj for your feedback. I went through #5458 and I am confused. The proposal mentions CAP_PROP_CONVERT (not CAP_PROP_FORMAT), but there is no mention thereof in the nightly documentation: http://docs.opencv.org/master/d4/d15/group__videoio__flags__base.html#gaeb8dd9c89c10a5c63c139bf7c4f5704d

Also, I looked at CAP_PROP_FORMAT, but the documentation does not explain how a user is supposed to use this property to set grayscale output. I quickly checked the V4L2 source code and setting this property is not supported.

Can you clarify how I should proceed?

yes, CAP_PROP_CONVERT has unfortunately been only discussed so far and not implemented.

1. turn off CAP_PROP_CONVERT_RGB (default value is true, that means BGR)
   • if source file is grayscale this should be sufficient
2. set CAP_PROP_FORMAT to AV_PIX_FMT_GRAY8 for grayscale conversion
   • alternatively set CAP_PROP_FOURCC to (G,R,E,Y) to be backend agnostic. This is what cap_v4l uses. However with ffmpeg it will require some logic to map to AV_PIX_FMT_GRAY8. As a bonus this would match the VideoWriter API.

Thank you for the clarification. Let me give you my opinion about your suggestion:

1. Setting CAP_PROP_FORMAT to AV_PIX_FMT_GRAY8 is sub-optimal for two reasons: First, it requires the user to import an FFMPEG header to have access to the constant. Second, as somebody already mentioned in fix zero length std::string in putText() #5458, grayscale is very common in computer vision, hence it would be desirable to make this setting backend-neutral. As a user, I would very much appreciate writing the same code both for V4L2 in production and FFMPEG in unit testing.

2. CAP_PROP_FOURCC is already used by FFMPEG to retrieve the codec of the input video. Giving it different semantics for setting than for getting would be confusing, whereas changing the API and using it for setting "desired output format" feels wrong to me.

Do you feel there are other good options except CAP_PROP_CONVERT? I could certainly dedicate some time and implement that for the FFMPEG backend, but given the larger effort, I would rather wait for some momentum to build around it.

unfortunately there is no backend neutral property to achieve this right now. That is exactly why CAP_PROP_CONVERT is needed.

You could let CAP_PROP_CONVERT_RGB=false imply grayscale for FFMPEG, but that would obviously not work for V4L and generally make the situation worse. So I am afraid CAP_PROP_CONVERT is the only clean solution.

@cristiklein, thanks for the contribution! I do not see how the newly added FFMPEG enum values (which are declared in the internal header) relate to the public API. It's quite unsafe solution because we can easily end up with unsynchronized values and then we get very weird results or crashes

@vpisarev, I couldn't agree more! However, if you look at the FFMPEG enum values, they are all unrelated to the public API and can easily end up unsynchronised. Hence, I simply opted for maintaining the existing "style" hoping that that would make my patch more acceptable.

I think we both agree that a proper solution would entail making all FFMPEG enum values relate to their public counterpart.

I believe because standalone ffmpeg wrapper can't use OpenCV's public API headers without additional refactoring (split enums from others things).

jenkins cn please retry a build