Issue 1:
System information (version)

OpenCV => 4.1.2

Operating System / Platform => Linux armv7l

Compiler => GCC 8.3.0

Detailed description

Upon trying to create a VideoCapture or VideoWriter object using the GStreamer backend, the Python interpreter freezes indefinitely.

Steps to reproduce

Compile OpenCV with GStreamer support. May also need to be on an ARM platform.

Open the python3 interpreter.

import cv2 and create a new VideoCapture or VideoWriter object using the GStreamer backend.

Press Ctrl+C.

Errors will appear. After this point, only a kill -9 will stop the process.

Output:

pi@opensight:~ $ python3
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2
>>> x = cv2.VideoCapture(1)
^C
(python3:1013): GStreamer-CRITICAL **: 03:20:46.243:
Trying to dispose element pipeline0, but it is in PAUSED instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

[ WARN:0] global /home/pi/opencv/opencv-4.1.2/modules/videoio/src/cap_gstreamer.cpp (886) open OpenCV | GStreamer warning: unable to start pipeline

(python3:1013): GStreamer-CRITICAL **: 03:20:46.244:
Trying to dispose element videoconvert0, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

[ WARN:0] global /home/pi/opencv/opencv-4.1.2/modules/videoio/src/cap_gstreamer.cpp (480) isPipelinePlaying OpenCV | GStreamer warning: GStreamer: pipeline have not been created

(python3:1013): GStreamer-CRITICAL **: 03:20:46.244:
Trying to dispose element appsink0, but it is in READY instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

Issue 2:
Basically, this is a GSoC project which has not been applied this year:

We want to see some kind of higher level API which can manage DL networks. There are several criterias for now:

Hide asynchronous inference management internally. User just choose the number of requests (what about heterogenous scenario? In example, use both GPU and VPU with specific number of requestst for each other).

Models from https://github.com/opencv/opencv/blob/master/samples/dnn/models.yml should be downloaded automatically in samples. Can we also introduce some kind of new automatically generated classes definitions for them? I.e.:

CV_EXPORTS_W YOLOv3 : public Model {
YOLOv3(const std::string& model = "yolov3.weights", const std::string& config= "yolov3.cfg", int weight = 416, int height = 416, Scalar mean = Scalar(), float scale = 0.00392);
};

User do not need to care about input's preprocessing. We can do it automatically. The base class can find the files (already implemented) or download if there are no (need to do).

class Model : public Net {
Model(const std::string& model, const std::string& config = "", int weight = -1, int height = -1, Scalar mean = Scalar(), float scale = 1.0);

// Overridden version which accepts frame and can make blob.
void setInput();
};

We can add some methods to simplify postprocessing (i.e. detect type of output layer for detection network as we do in object detection samples):

void detect(std::vector<float>& confidences, std::vector<Rect>& boxes, float confThreshold, float nmsThreshold);

So instead doing forward with postprocessing and can just call detect and then manage the predictions (i.e. draw it on the frame).