Issue 1:
System information (version)

OpenCV: 3.4.5

Operating System / Platform: Ubuntu 16.04

Compiler: GCC/G++ & CMake

Cuda: 9.2

Detailed description

According to the Official sample by #video_reader.cpp, I have been tried to run this example with the version range OpenCV 3.4.5 to 4.0.1, but all of the version seem not to be work perfectly. I am using AWS EC2 instance which provided Tesla K80 GPU with CUDA 9.2/9.1 support. I don't know whatever this problem is bugging by OpenCV or AWS EC2 Instance, but I have researched any related issues like #6231 also not yet fixed.

Since this #sample are demonstrate CPU and CUDA methods, the CPU method is working perfectly (I just change the "cv::imshow("CPU", frame)" to "cv::imwrite(name, frame)"), but not CUDA.

Also, I can confirm the CUDA and NVCUVID are enabled with CMake. Sorry for my stupid question.

Steps to reproduce

OpenCV Build Information:

-- Video I/O:
-- DC1394: YES (ver 2.2.4)
-- FFMPEG: YES
-- avcodec: YES (ver 56.60.100)
-- avformat: YES (ver 56.40.101)
-- avutil: YES (ver 54.31.100)
-- swscale: YES (ver 3.1.101)
-- avresample: YES (ver 2.1.0)
-- GStreamer:
-- base: YES (ver 1.8.3)
-- video: YES (ver 1.8.3)
-- app: YES (ver 1.8.3)
-- riff: YES (ver 1.8.3)
-- pbutils: YES (ver 1.8.3)
-- libv4l/libv4l2: 1.10.0 / 1.10.0
-- v4l/v4l2: linux/videodev2.h
--
-- Parallel framework: pthreads
--
-- Trace: YES (with Intel ITT)
--
-- Other third-party libraries:
-- Intel IPP: 2019.0.0 Gold [2019.0.0]
-- at: /home/ubuntu/opencv/opencv-3.4.5/release/3rdparty/ippicv/ippicv_lnx/icv
-- Intel IPP IW: sources (2019.0.0)
-- at: /home/ubuntu/opencv/opencv-3.4.5/release/3rdparty/ippicv/ippicv_lnx/iw
-- Eigen: NO
-- Custom HAL: NO
-- Protobuf: build (3.5.1)
--
-- NVIDIA CUDA: YES (ver 9.0, CUFFT CUBLAS NVCUVID FAST_MATH)
-- NVIDIA GPU arch: 30 35 37 50 52 60 61 70
-- NVIDIA PTX archs:
--
-- OpenCL: YES (no extra features)
-- Include path: /home/ubuntu/opencv/opencv-3.4.5/3rdparty/include/opencl/1.2
-- Link libraries: Dynamic load
--
-- Python 3:
-- Interpreter: /usr/bin/python3 (ver 3.5.2)
-- Libraries: /usr/lib/x86_64-linux-gnu/libpython3.5m.so (ver 3.5.2)
-- numpy: /usr/local/lib/python3.5/dist-packages/numpy/core/include (ver 1.15.4)
-- install path: /usr/lib/python3/dist-packages/cv2/python-3.5
--
-- Python (for build): /usr/bin/python2.7

Trigger problem:

cv::Mat frame;
cv::VideoCapture reader(fname);

cv::cuda::GpuMat d_frame;
cv::Ptr<cv::cudacodec::VideoReader> d_reader = cv::cudacodec::createVideoReader(fname);
.........................................................................
for (;;)
{
tm.reset(); tm.start();
if (!reader.read(frame))
break;
tm.stop();
cpu_times.push_back(tm.getTimeMilli());
cpu_frame_count++;

const std::string name("./test.jpg");
cv::imwrite(name, frame);
if (cv::waitKey(3) > 0)
break;
}

for (;;) {
tm.reset(); tm.start();
if (!d_reader->nextFrame(d_frame))
break;
tm.stop();
gpu_times.push_back(tm.getTimeMilli());
gpu_frame_count++;

const std::string name("./test_cuda.jpg");
cv::imwrite(name, d_frame); // This line trigger the getMat_ problem.

if (cv::waitKey(3) >= 0)
break;
}

Error log:

terminate called after throwing an instance of 'cv::Exception'
what(): OpenCV(3.4.5) /home/ubuntu/opencv/opencv-3.4.5/modules/core/src/matrix_wrap.cpp:118: error: (-213:The function/feature is not implemented) You should explicitly call download method for cuda::GpuMat object in function 'getMat_'

Aborted (core dumped)

Issue 2:
Transferred from http://code.opencv.org/issues/3571

|| Goncalo Lopes on 2014-02-25 13:52
|| Priority: Normal
|| Affected: None
|| Category: build/install
|| Tracker: Feature
|| Difficulty:
|| PR:
|| Platform: None / None

Automatically generate C interface to replace legacy API

OpenCV now provides automatically generated wrappers for a number of languages: Python, Java, Matlab. However, there are many other environments that benefit from interfacing with OpenCV.

Up to now, an easy solution to interoperate with OpenCV was to use the C API. The reason for this is that C still has a more standard ABI than C++ from a cross-platform point of view and many more languages support interoping with C than they do with C++.

Now that the C interface to OpenCV will be deprecated, this option will no longer be available. However, it seems that it would not be so hard to automatically generate a new C interface from C++ headers in exactly the same way as other wrappers are generated. This would provide a standard native C interface that other environments could easily interop with and would be automatically kept up to date with latest C++ features.

History

Dinar Ahmatnurov on 2014-03-04 10:49

Roman, what do you think?
- Assignee set to Roman Donchenko
- Category set to build/install

Dinar Ahmatnurov on 2014-03-05 17:23

- Status changed from New to Open

Alexander Duda on 2014-11-03 23:14

I am not sure if this is very helpful because an automated generated C API would be very cumbersome to use. Think of all the constructors, deconstructors, overloaded methods, templates etc. Nevertheless, I believe this C-Layer would be very beneficial for additional language bindings (have a look at https://github.com/Itseez/opencv_contrib/pull/116).

Goncalo Lopes on 2015-03-06 17:52

As you point out with the Ruby bindings example, most language bindings already have to generate this intermediate C interface anyway. Why not simply make it standard so that people can avoid duplicating this step over and over again (with possible errors cropping up?).

It's true that C can be extremely cumbersome, but often its the only way to make interop possible at all...
(Ruby, D, many others... as stated in http://queue.acm.org/detail.cfm?id=2543971 - "The industry has spent the past 30 years building CPUs optimized for running languages such as C, because people who needed fast code used C (because people who designed processors optimized them for C, because...")