Fixed trailing whitespace

@jveitchmichaelis , could you please add test case here: https://github.com/opencv/opencv/blob/master/modules/videoio/test/test_gstreamer.cpp

Is this patch applicable to 3.4 branch too? If yes, please rebase your branch there and change pull request target to 3.4 branch. We will merge it to master later (see https://github.com/opencv/opencv/wiki/Branches).

@mshabunin No problem. I've rebased to 3.4, I'll add some tests too.

The main differences I can see were some checks for a particular version of gstreamer that are no longer in master. I added support for writing 16-bit frames with Gstreamer, but perhaps it makes sense to split that into another commit and leave this one only for capture.

At a minimum I can add a testcase like:

make_tuple("video/x-raw, format=GRAY16_LE", Size(640, 480), Size(640, 480), COLOR_GRAY2RGB),

Would that be sufficient?

I added support for writing 16-bit frames with Gstreamer, but perhaps it makes sense to split that into another commit and leave this one only for capture.

I agree.

At a minimum I can add a testcase like:
...
Would that be sufficient?

Yes, at minimum. It would be better to test handling of CV_CAP_PROP_CONVERT_RGB property too and verify actual 16-bit image capturing. But we can add it in later PRs.

@mshabunin I've added two test cases. I also limited the scope of the PR to capture only, as suggested. There is:

• A test case to check the default behaviour for CONVERT_RGB
• An additional case for the existing suite, however..

One issue that I've noticed is that CAP_GSTREAMER doesn't follow the convention that capture pipelines should return 3-channel 8-bit images by default i.e. convert_rgb is ignored. Most of the outputs here (e.g. GRAY8, and all the YUV variants) return a single channel image and rely on the user to convert to colour. The existing test cases also (incorrectly) enforces this behaviour.

I've raised that in #14084

Seems to be an issue with the linux debug CI too: https://pullrequest.opencv.org/buildbot/builders/precommit_linux64_no_opt/builds/19060

I added support for writing 16-bit frames with Gstreamer, but perhaps it makes sense to split that into another commit and leave this one only for capture.

@jveitchmichaelis, we'd be happy to test a patch for writing, please create a PR when you get a chance. We looked at doing it, but it's not obvious how we could automatically determine a pipeline is Y16, seems like we'd need a property.

@mshabunin OK, I'll take a look at this again. I've not had a chance recently. So I'll change it so that 16 bit is only supported for manual pipelines.

@joshdoe sure, will do! It will probably be doable based on the output codec. Relatively few formats actually support 16 bit output per channel, so you could infer on that plus the pixel format I think.

@joshdoe sure, will do! It will probably be doable based on the output codec. Relatively few formats actually support 16 bit output per channel, so you could infer on that plus the pixel format I think.

@jveitchmichaelis Great, thanks. I recently added Y16 support to the GStreamer DirectShow source because I was testing a FLIR Boson thermal camera, but in this case we're using a Camera Link source (https://github.com/joshdoe/gst-plugins-vision).

I've modified this to apply against master, as I couldn't easily get the 3.4 branch built. I removed the CONVERT_RGB bits as suggested by @mshabunin , and changed the tests a bit to check depth on all formats, and convert 16->8 for GRAY16_LE. My branch is joshdoe/opencv/y16_gstreamer_master. I also rebased this to 3.4, but haven't been able to test it: joshdoe/opencv/y16_gstreamer_3.4.

Note the authorship changed to me, but I added Co-author as @jveitchmichaelis , I'm fine if this is flipped.

@jveitchmichaelis The PR diverged with 3.4. Could you rebase and fix conflicts.
@mshabunin What is the PR status? Are there open items? Could we merge it after rebase and conflicts fix?

@asmorkalov , I think #18694 is more compact and implements the same feature, so we can close this one. #18535 implements Y16 support in VideoWriter.

I'll second the implementation in #18694 as it's cleaner, though I tested writing (from #18535) and reading for both of these implementations and they passed.

Apologies, this feel through the cracks - feel free to go with whichever implementation you feel fits best.