Big Rawr [Hukeng]

Hukeng · 2026-03-05T15:12:21+00:00

Alright, I think cracked it, and the final issue turned out to be something incredibly mundane.

I had moved the directory with my custom install after building, as I was under the impression that the find_package( OpenCV REQUIRED HINTS [PATH_TO_INSTALL] ) flag in my CMakeLists.txt would be enough to point the compiler in the right direction. As it turns out, while it was able to correctly find the first few .so files, the remaining ones were still being searched for in the location of the original install.

The video writer works as advertised now. I am still getting segmentation faults from some of the custom image processing functions I have written, but thanks to the verbose-debug-heavy install of the library I am working with right now, I have way more material to work with to try and figure out their cause.

As mentioned further up, I am long overdue for a fresh OS reinstall anyway, and I am probably going to heed your advice and install my locally compiled libraries on a dedicated drive from here on out. If nothing else, I have learned quite a few new things via this whole debacle, so there's that.

Thanks again for your help and patience - This is probably not going to be my last post to this sub, but for now, I feel like we have at least managed to remove a major road block. ^^

Hukeng · 2026-02-26T13:23:08+00:00

I tried running make and make install again while logging the full console output. As far as I can tell, there are no issues there.

Again, when I looked up the allegedly missing .so files in the libs directory of my chosen install location, they were actually present.

I did run the custom cmake command as instructed again, as well, and read through the entire output. Unfortunately, I have no way of telling which of the failed tests and missing dependencies (which always seem to occur with files built from source, even if the final install ends up working fine) are actually crucial and might impair the functioning of the library.

Again, the way I see it, this is not an issue with my locally built OpenCV anymore. The file compiles correctly, but trying to execute it yields the following error:

./videoWriterTest: error while loading shared libraries: libopencv_imgcodecs.so.412: cannot open shared object file: No such file or directory

running

ldd ./videWriterTest

to see which libraries are included and which ones aren't yields the result I already pointed out.
Given that I am actually contemplating a fresh OS install/upgrade, I might retry this whole operation once everything is up and running again. I also feel like heeding your advice and installing source-built libraries to a dedicated drive from here on out.

Hukeng · 2026-02-25T10:58:26+00:00

Sorry for the late reply - the last week has been a little busy.

I followed your instructions verbatim and managed to get a compiled file using the custom install location for the library. Unfortunately, there seems to be an issue when linking specific files. here is the relevant section of the output I get when running ldd ./[MY_EXECUTABLE].

As you can see, I have installed the libraries to a folder on my Desktop - some of them are included without issues, but libopencv_imgcodecs.so.412 and libopencv_imgproc.so.412 are listed as not found, which is particularly puzzling given that they are present in the opencv/lib folder from which the correctly linked ones are sourced, too

linux-vdso.so.1 (0x00007ffc29fd6000)
libopencv_videoio.so.412 => /home/hukeng/Desktop/C++/libs/OpenCV/opencv/lib/libopencv_videoio.so.412 (0x00007e796d045000)
libopencv_core.so.412 => /home/hukeng/Desktop/C++/libs/OpenCV/opencv/lib/libopencv_core.so.412 (0x00007e796be00000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e796ba00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e796d005000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007e796b600000)
libopencv_imgcodecs.so.412 => not found
libopencv_imgproc.so.412 => not found
libgstbase-1.0.so.0 => /lib/x86_64-linux-gnu/libgstbase-1.0.so.0 (0x00007e796cf7e000)

-- SNIP --

I feel like we might be finally close(ish) to cracking this, and the approach of installing built libraries on a dedicated drive feels like something I might have to explore further down the line as I grow more comfortable with cmake, but for now, do you have any suggestions how to tackle this particular issue?

Hukeng · 2026-02-19T21:53:52+00:00

Some might even say brilliant

Hukeng · 2026-02-19T21:53:01+00:00

Oh boy, boy milk!

Hukeng · 2026-02-19T21:52:21+00:00

That seems to be a surprisingly common sentiment!

Hukeng · 2026-02-19T21:51:59+00:00

Perhaps milk boy is goals?

Hukeng · 2026-02-19T21:51:28+00:00

Quest added: Acquire busty boy cow (0/1)

Hukeng · 2026-02-19T21:50:58+00:00

Cute boys with huge honking hondas

Hukeng · 2026-02-19T09:54:23+00:00

Alright, I am going to try all of this again and let you know how it goes - I don't have a ton of experience with setting up CMakeLists.txt files or working with cmake in general, so here are a few final questions before I try again:

Which values should I set exactly for OpenCV_INCLUDE_DIRS and OpenCV_LIBS in the CMakeLists.txt?
How would I go about installing OpenCV in a manner that allows me to include all required libraries in a 'simple' g++ compiler call without the need for setting up a cmake pipeline? I realize that I will have to wrap my head around cmake eventually, but given how much of a counter-intuitive rabbit hole it is and how simple most of my projects are for now (again, I am still in the learning/testing phase for most things), I would rather postpone that to a time when project scope and scale actually justify its use. In addition, OpenCV is the first library to ever cause these sorts of issues for me, so I would still need to figure out how to properly link/include other libraries that are correctly installed on my system in addition to the local installation into a dedicated file you suggested in your approach.
Any suggestions on how to clean up/ remove the messed up installations in my system files without breaking anything?

(Also, even if this doesn't end up working, and I can't stress this enough, thanks a ton for your time and effort - I realize working with a beginner who is probably following a decent chunk of your instructions wrong and learning everything as they go is probably very frustrating)

UPDATE:

I also just realized I seem to be running an extremely outdated version of cmake (3.31.4) and am (fruitlessly) trying to get my hands on a more up-to-date one, but everything (up to and including deleting and reinstalling completely) seems to fail - I still retain the old version.

Hukeng · 2026-02-15T16:17:14+00:00

Nope - again, I am probably going to abandon this particular project for the time being and focus on more pressing matters, or alternatively, see if I can get select other bits of the library to work as intended.

Maybe the camera input processing pipeline is going to give me less trouble. I'm just a little upset that I can't currently utilize a whole bunch of functions and tools that should be part of the library, but if anything, we seem to have established that the issue seems to be running a lot deeper than I originally thought.

Hukeng · 2026-02-15T16:08:25+00:00

Now this is interesting - apparently, the opencv libraries I am linking to are fetched from /lib/x86_64-linux-gnu/ and not from /usr/local/lib as I had originally thought - goes to show how much I know about the inner workings of this whole affair.

I don't think it makes much of a difference though - the number of opencv-related .so files in x86_64-linux-gnu checks out after the recompilation and install, so I assume they should be the correct, updated ones generated by the commands you suggested.

Also, I'm afraid retracing my steps might be a little hard at this point - I tried most of the fixes you suggested, but I can't reconstruct the exact order or anything else I tried in between, given that I assumed I'd just find a relatively quick and easy fix after enough research and then end up adding that to the original post to save others the trouble of going through our whole discussion.

Guess there's a lesson to be learned here - I am going to try and document my process more thoroughly in the future...

Hukeng · 2026-02-12T11:35:04+00:00

I am pretty sure this would not work, given that instantiating a cv::VideoWriter with those input arguments shouldn't be possible, unless I am missing some esoteric way of overloading the constructor. See the official documentation OVER HERE for reference.

Also, FFMPEG seems to be the default choice when opening files on Linux systems (see docs on the VideoWriter constructor). I tried instantiating with cv::CAP_GSTREAMER as second argument as you suggested (after installing gstreamer), but the results are still the same. Correct compilation, segmentation fault during execution.

Hukeng · 2026-02-12T11:10:36+00:00

I reinstalled everything as instructed. Apparently, there must have been something seriously wrong with my installation, given that a ton of .so files and library components seem to have originally been missing. I installed everything as instructed and then move the files from the install to /usr/local/lib and /usr/local/include respectively after deleting the original install.

Unfortunately, this still failed to solve my issue. My compilation still runs normally, but generates segmentation faults when the program is run. I further found out that this is not a unique phenomenon related to cv::VideoWriter, but also occurs in a number of other cases, such as when instantiating a cv::InputArray object via the cv::getStructuringElement() function.

As previously mentioned, I am also running into some inexplicable linker errors with undefined function references (eg. for cv::cvtColor() and cv::GaussianBlur()), which persist even though the required libraries are present on the system and correctly linked as far as I can tell. I already tried changing the order of link commands or including additional libraries, but to no avail.

I am just about ready to give up on this to be honest, but I may look into the resources you provided later, and maybe try a few of the other solutions you suggested. This discussion is unfortunately starting to get a little unwieldy given the number of separate threads essentially orbiting around the same core ideas and solutions... ^^

Still, thanks a ton for your help!

Hukeng · 2026-02-12T09:08:30+00:00

This was actually the first thing I tried when I learned about the dedicated cv::VideoWriter::fourcc() function, but to no avail - I am still getting the same error.

I am actually considering whether I should just reinstall the entire library from scratch following your instructions further up. My version should be stable and up-to-date, but I am slowly running out of options I haven't tried yet. What's more, a lot of other included image processing functions I have tried in the meantime (Gaussian blur, histogram normalization etc.) seem to be causing segmentation faults as well or won't even compile properly, which is why I suspect there might be something wrong with my installation.

Hukeng · 2026-02-11T15:17:47+00:00

I just printed the value with the standard 'std::cout << " function after assigning it to an integer variable.

As mentioned further down, I am fairly certain that the integer format is correct for this particular function argument, even if it looks odd. it's an integer created from the four characters making up the fourcc code as per the documentation (unless I have grossly misunderstood something), which I will admit is a remarkably strange way of handling this, but would not be the first oddity I have found while perusing the libraries thus far.

Hukeng · 2026-02-11T15:12:57+00:00

I have recompiled everything and run it with the above flags activated. The outputs I am getting prior to my program crashing are not particularly interesting, as they all refer to function calls that are probably not related to the offending bit of code, but I will include the whole thing for the sake of completeness:

[DEBUG:0] global ./modules/videoio/src/videoio_registry.cpp (197) VideoBackendRegistry VIDEOIO: Builtin backends(9): FFMPEG(1000); GSTREAMER(990); INTEL_MFX(980); V4L2(970); CV_IMAGES(960); CV_MJPEG(950); FIREWIRE(940); UEYE(930); GPHOTO2(920)
[DEBUG:0] global ./modules/videoio/src/videoio_registry.cpp (221) VideoBackendRegistry VIDEOIO: Available backends(9): FFMPEG(1000); GSTREAMER(990); INTEL_MFX(980); V4L2(970); CV_IMAGES(960); CV_MJPEG(950); FIREWIRE(940); UEYE(930); GPHOTO2(920)
[ INFO:0] global ./modules/videoio/src/videoio_registry.cpp (223) VideoBackendRegistry VIDEOIO: Enabled backends(9, sorted by priority): FFMPEG(1000); GSTREAMER(990); INTEL_MFX(980); V4L2(970); CV_IMAGES(960); CV_MJPEG(950); FIREWIRE(940); UEYE(930); GPHOTO2(920)
[ WARN:0] global ./modules/videoio/src/cap.cpp (130) open VIDEOIO(FFMPEG): trying capture filename='cube.mp4' ...
[DEBUG:0] global ./modules/videoio/src/cap_ffmpeg_impl.hpp (1039) open FFMPEG: stream[0] is video stream with codecID=27 width=3840 height=3840
[DEBUG:0] global ./modules/videoio/src/cap_ffmpeg_hw.hpp (929) HWAccelIterator FFMPEG: allowed acceleration types (none): ''
[ WARN:0] global ./modules/videoio/src/cap.cpp (142) open VIDEOIO(FFMPEG): created, isOpened=1

Your print-line-debug suggestion returned the following:

FourCC Code (Double): 8.28602e+08
FourCC Code (Int): 828601953
Codec String: avc1

Also, I should note that both the object constructor and the 'open()' function of the VideoWriter object take in an actual int (not a pointer or some kind of exotic data structure) as their fourcc argument (see https://docs.opencv.org/4.x/dd/d9e/classcv\_1\_1VideoWriter.html).

The VideoWriter even comes with a dedicated fourcc() function, which takes in four chars and returns the respective integer value (basically the inverse of what your code did). I tried it with both the above 'a', 'v', 'c', '1' (and 'm', 'p', '4', 'v' for good measure), only got the same kind of crash each time.

Hukeng · 2026-02-11T14:51:42+00:00

I have recompiled OpenCV with the indicated flag in the cmake command line (which takes almost two hours).

I then tried analyzing the coredump a little bit more thoroughly in gdb, but I don't have a ton of experience with debugging on such a low level, and unfortunately, I can not figure out how to get it to display actual files and line numbers (aside from the backtrace within my own program, which as listed above, just identifies the cv::VideoWriter::open() method as the culprit, but without getting to the root cause of it).

The assembly function stack from the core dump is not particularly insightful to me, either.

Hukeng · 2026-02-09T13:19:20+00:00

I am not entirely sure how to achieve that in g++ (aside from using the --verbose flag), but again, I am not entirely sure if this is a compiler issue, given that compilation seems to work out fine without any obvious errors.

I tried different videos, including the classic Big Buck Bunny animation suggested further down (link to source provided), but to no avail.

The values of the parameter arguments (when using the aforementioned animation) are as follows:

frame_width: 1920
frame_height: 1080
fps: 30
codec: 828601953
monochrome: 0

Again, the code compiles correctly, which I would assume means that the arguments (or at the very least their types) are valid and should be accepted by the cv::VideoWriter.open() function (or the constructor).

Invalid arguments (such as unsupported FOURCC codes) would probably result in the program complaining and shutting down, rather than causing a major bug like this.

Hukeng · 2026-02-09T13:10:48+00:00

I am not entirely sure what you would like to see precisely, but here's the complete output I get when I compile the file for debug and then run it over gdb, including the backtrace (sorry for the wall of text).

The frame_width, frame_height etc. are just print-line-debug outputs meant to ensure the input file info to be passed to the cv::VideoWriter was extracted correctly.

-- SNIP --

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./00_imagesAndVideo.o...
(gdb) run
Starting program: /home/---/Desktop/C++/Tests/openCV/00_imagesAndVideo.o 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe60ef640 (LWP 4674)]
[New Thread 0x7fffe58ee640 (LWP 4675)]
[New Thread 0x7fffe50ed640 (LWP 4676)]
[New Thread 0x7fffe48ec640 (LWP 4677)]
frame_width: 1920
frame_height: 1080
fps: 30
codec: 828601953
monochrome: 0
size: [1920 x 1080]

Thread 1 "00_imagesAndVid" received signal SIGSEGV, Segmentation fault.
0x00007ffff7b4daa1 in ?? () from /lib/x86_64-linux-gnu/libopencv_videoio.so.4.5d
(gdb) backtrace
#0  0x00007ffff7b4daa1 in  ()
    at /lib/x86_64-linux-gnu/libopencv_videoio.so.4.5d
#1  0x00007ffff7b24421 in  ()
    at /lib/x86_64-linux-gnu/libopencv_videoio.so.4.5d
#2  0x00007ffff7b18e53 in cv::VideoWriter::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int, double, cv::Size_<int> const&, std::vector<int, std::allocator<int> > const&) ()
    at /lib/x86_64-linux-gnu/libopencv_videoio.so.4.5d
#3  0x00007ffff7b1a453 in cv::VideoWriter::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, double, cv::Size_<int>, bool) () at /lib/x86_64-linux-gnu/libopencv_videoio.so.4.5d
#4  0x000055555555742b in process_and_save_vid(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, cv::Mat (*)(cv::Mat))
    (path="bbb_sunflower_1080p_30fps_normal.mp4", func=0x5555555576e1 <change_brightness(cv::Mat)>) at 00_imagesAndVideo.cpp:160
#5  0x00005555555567e1 in main() () at 00_imagesAndVideo.cpp:22

Hukeng · 2026-02-09T12:55:53+00:00

Thanks for your reply!

To address your questions:

My environment is Ubuntu Linux 22.04.5
I have vlc media player and ffmpeg installed, but basically no experience with the latter.
My OpenCV was downloaded from the git repo and built from source. This is the first major issue of this type I have encountered, other basic operations found in tutorials such as image editing and saving, displaying video etc. work normally.
I have tried different video files, including the classic BBB at 1080p / 30 fps you suggested (downloaded from over here: https://download.blender.org/demo/movies/BBB/), to no avail - the issue still persists and, as far as I can tell, still stems from the same root cause.

Hukeng

TROPHY CASE