Add CV_16UC1/GRAY16_LE support to GStreamer backend for VideoWriter#18535
Add CV_16UC1/GRAY16_LE support to GStreamer backend for VideoWriter#18535alalek merged 5 commits intoopencv:masterfrom
Conversation
|
@joshdoe Thanks for the patch! It's very cool that you bring test with the new feature, but there is issue with Actual pipeline initialization is delayed till the first frame. It means that |
|
@asmorkalov thanks for taking a look at this. Do you think I should get rid of all autodetection from first frame, or make it optional based on if |
69abe4b to
e1a8fc0
Compare
|
I think I've done what you asked. If you don't like the auto-detection option, that can easily be removed. |
41bc9eb to
fff866d
Compare
|
I'm getting failures on the buildbot with the tests I've implemented, however locally with Win64 VS2019 I have no issues. I'm trying to build now on Ubuntu 16.04. |
|
Tests are passing for me in Ubuntu 16.04 as well. Not sure how to replicate the failures from the buildbot. |
|
I see the problem now. The buildbot builds the GStreamer backend as a plugin, and I've been building it statically. I've just tried building it as a plugin, and hit a compilation error. From the looks of it, the way plugins are defined, there's no way to pass arbitrary parameters, that is, not all entries from
Maybe @mshabunin could give some input on the way forward. Thanks. |
|
@joshdoe Let me check the plugin issue with teammates. and I'll come back. |
|
@joshdoe I discussed the situation with @alalek , @vpisarev and core team members and we propose |
|
@asmorkalov trying to do this now. There's no state for the |
fff866d to
7378aa0
Compare
|
@asmorkalov I've taken a stab at this, seems to work on my end, let's see what the buildbot thinks. |
7378aa0 to
7468782
Compare
|
@asmorkalov Builds are passing now after I fixed some warnings in the FFMPEG backend. Do review my API changes, not sure if this is the best way to handle it or not. |
asmorkalov
left a comment
There was a problem hiding this comment.
Looks good in general. Please address several local remarks.
| // generate a noise frame | ||
| Size frame_size(320, 240); | ||
| Mat frame = Mat::zeros(frame_size, CV_16U); | ||
| cv::randu(frame, 0, 65535); |
There was a problem hiding this comment.
Please use theRNG(); as random generator to get reproducible results.
There was a problem hiding this comment.
cv::randu() uses cv::theRNG() internally, so code is fine here.
There was a problem hiding this comment.
I'm not sure why the numbers have to be reproducible, as I'm simply comparing what I've generated to what I read back in. If this change request still stands, would I do it like this?
cv::theRNG().state = 123456;
cv::randu(frame, 0, 65535);
There was a problem hiding this comment.
Not needed.
theRNG() initial state is initialized by OpenCV test framework (using the same value) before calling of each test case body.
BTW, initial theRNG() state is configurable through command-line (however this mode is not used widely). Test data should not rely on its value.
|
|
||
| // generate a noise frame | ||
| Size frame_size(320, 240); | ||
| Mat frame = Mat::zeros(frame_size, CV_16U); |
There was a problem hiding this comment.
Mat::zeros() call is ambiguous as you fill the mat with random values.
There was a problem hiding this comment.
Mat::zeros()call is ambiguous as you fill the mat with random values.
Not correct.
zeros
fill with zeros values.
There was a problem hiding this comment.
Ambiguous isn't the right word to use, but since all the values get overwritten immediately, it is unnecessary to initialize to zero, even if it is a very fast operation. I've changed this to simply Mat(frame_size, CV_16U)
There was a problem hiding this comment.
Sorry for my English, ambiguous is not the right word. I mean redundant.
| Mat written_frame(frame_size, CV_16U); | ||
| std::ifstream fs(temp_file, std::ios::in | std::ios::binary); | ||
| fs.read((char*)written_frame.ptr(0), frame_size.width * frame_size.height * 2); | ||
| ASSERT_TRUE(fs); |
There was a problem hiding this comment.
I think it should be before read call.
There was a problem hiding this comment.
I believe this assertion ensures that .read() call is successful (it is really necessary).
There was a problem hiding this comment.
I did some tests, I could put an assertion both before and after .read(), however the second assertion will catch the same issue that the first assertion would, that is if a file is missing or can't be opened. I left this as is for now.
| std::vector<int> vint_params; | ||
| for (const auto& param : params.getAll()) | ||
| { | ||
| vint_params.push_back(param.key); | ||
| vint_params.push_back(param.value); | ||
| } | ||
| int* c_params = &vint_params[0]; | ||
| size_t n_params = vint_params.size() / 2; |
There was a problem hiding this comment.
I propose to extract this code as method of VideoWriterParameters class. E.g. return std::vector and pass it's content to C code as plain C array with size. We can potentially optimized the class behavior without plugins code modification.
There was a problem hiding this comment.
Ok I added getIntVector().
| // compare to make sure it's identical | ||
| Mat diff; | ||
| absdiff(frame, written_frame, diff); | ||
| Scalar total = sum(diff); | ||
| ASSERT_EQ(total[0], 0); |
There was a problem hiding this comment.
Please use this for "identity" checks:
EXPECT_EQ(0, cv::norm(frame, written_frame, NORM_INF));
7468782 to
77d12cb
Compare
asmorkalov
left a comment
There was a problem hiding this comment.
Looks good to me. Please squash the commits and I think we can merge the patch.
@asmorkalov Squash all three? I thought it might be useful to keep the plugin API change as a separate one, maybe squash the two GStreamer-specific ones? |
|
Yes, dedicated commit for API change is good idea. Thanks. |
There was a problem hiding this comment.
Loading/using of existed FFmpeg plugin on Windows is broken:
[ INFO:0] global C:\build\precommit_windows64\opencv\modules\videoio\src\backend_plugin.cpp (211) cv::impl::PluginBackend::PluginBackend Video I/O: plugin is incompatible: C:\build\precommit_windows64\build\bin\Release\opencv_videoio_ffmpeg451_64.dll
...
[ RUN ] videoio/videoio_ffmpeg.write_big/0, where GetParam() = ("", "avi", 4096x4096)
[ SKIP ] FFmpeg backend was not found
[ OK ] videoio/videoio_ffmpeg.write_big/0 (0 ms)
I will take a look how to fix this on this week.
This will allow arbitrary parameters to be passed to plugin backends
This introduces a new property VIDEOWRITER_PROP_DEPTH, which defaults to CV_8U, but for GStreamer can be set to CV_16U. Also, fix another test to not fail if plugin isn't found, copying logic from the read_write test.
|
@alalek looks like any existing plugin will fail with the I also squashed the two GStreamer-specific commits. |
77d12cb to
ba4a822
Compare
alalek
left a comment
There was a problem hiding this comment.
LGTM 👍
Thank you for contribution!
Add CV_16UC1/GRAY16_LE support to GStreamer backend for VideoWriter * videoio(backend): add Writer_open_with_params to plugin API This will allow arbitrary parameters to be passed to plugin backends * videoio(gstreamer): add GRAY16_LE/CV_16UC1 writing support to GStreamer This introduces a new property VIDEOWRITER_PROP_DEPTH, which defaults to CV_8U, but for GStreamer can be set to CV_16U. Also, fix another test to not fail if plugin isn't found, copying logic from the read_write test. * videoio(plugin): fix handling plugins with previous API level * videoio: coding style * fix warning
See #14035 for a companion PR to add CV_16UC1/GRAY16_LE capture support. I'm new to test writing, but added one that seems to make sense. I'm not clear if all PRs are still supposed to be based off 3.4, but I ran into roadblocks trying to build 3.4 at all, master just worked so easily.
Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.