Thanks for the contribution! Could you point me the case where per-frame memory layout differs from the video one. Is it specific to GStreamer version or some codec/camera ?

Hey @asmorkalov. I just experienced this with a proprietary camera that gave odd widths and no padding. GStreamer, if not explicitly indicated otherwise, assumes the stride will be a multiple of 4 bytes, which wasn't true for this camera. So the way I communicated the correct stride was using the video meta. I created a dirty mock element that causes this same effect. Consider the following video capture app:

#include <opencv2/opencv.hpp>

using namespace cv;
int main(int argc, char** argv )
{
  cv::VideoCapture cap(
     "oddsrc ! video/x-raw,width=321,height=240,format=BGR ! appsink", cv::CAP_GSTREAMER);
  cv::namedWindow("Display Image", WINDOW_AUTOSIZE );

  while(1){
    cv::Mat frame;
    cap >> frame;

    imshow("Display Image", frame);
    waitKey(33);
  }

  cap.release();
  return 0;
}

The oddsrc camera element will create BGR images with a 321 pixels width and no padding, resulting in a 963 (321*3) bytes stride. With the master branch, Gstreamer automatically computes a 964 stride, resulting in image artifacts:
gstreamer_video_capture_gst_buffer_map.png

On the other hand, if one uses video_frame_map (as in the PR), the correct stride is considered and the image is properly displayed:
gstreamer_video_capture_frame_map.png

To verify this yourself, you can build the oddsrc by downloading the contents of gstoddsrc.c and building as

gcc gstoddsrc.c `pkg-config --cflags --libs gstreamer-1.0 gstreamer-base-1.0 gstreamer-video-1.0` -shared -o libgstoddsrc.so

Thanks a lot for the contribution. The patch works for me and looks very reasonable. 5 cents from my side:

• To reproduce the issue need to build the plugin with -fPIC option and add plugin folder to GST_PLUGIN_PATH environment variable.
• I tried to reproduce the issue with videotestsrc. "videotestsrc pattern=\"checkers-8\" ! video/x-raw,width=321,height=240,format=BGR ! appsink" Generates accurate images and does not trigger the issue. It looks like it announce correct frame meta from the very beginning.
• It'll be great to contribute the oddsrc as videotestsrc option to GStreamer to have it as test solution everywhere. What do you think?

Test system: Ubuntu 18.04. GStreamer 1.14.5. OpenCV cannot convert YUV with odd width. All branches tested manually.

Image size: [321 x 360] step:321
terminate called after throwing an instance of 'cv::Exception'
  what():  OpenCV(4.5.5-dev) /mnt/projects/Projects/OpenCV/opencv-master/modules/imgproc/src/color.simd_helpers.hpp:108: error: (-215:Assertion failed) sz.width % 2 == 0 && sz.height % 3 == 0 in function 'CvtHelper'