Compiling OpenCV 4 with GStreamer 1.0 support (under Windows)

This is merely a quick summary of the points that differ from another older guide, that handles the same topic:


There is no need to change the system path or set PKG_CONFIG_PATH as indicated in the linked article. Instead set the environment variable GSTREAMER_DIR to the right directory (in my case it is: D:\gstreamer\1.0\x86_64 ), and append D:\gstreamer\1.0\x86_64\bin to the PATH environment variable (not the \lib or \lib\gstreamer-1.0 folders).

cap_gstreamer.cpp does not need to be modified starting with OpenCV 4. It is fully compatible with MSVC 2017 and Windows. (Earlier versions of OpenCV and MSVC may work as well, but I haven’t tested them.)

It is not necessary to change opencv\sources\CMakeLists.txt anymore. Therefore there is no need to download, install or add pkg-config to the system path, either.

OpenCV contains now a file FindGstreamerWindows.cmake that will locate GStreamer, but you still have to set the environment variable GSTREAMER_DIR properly, as mentioned above.

Make sure to select the x64 compiler toolset (or the x86 one), depending on which you need. CMake will only generate projects for one of them.

For example if you use 64 bit Python, then OpenCV should be 64 bit as well.

Search for “gstreamer” and “python” in the CMake GUI, and check that all variables could be filled out correctly, and that GStreamer is enabled. Also search for examples and check BUILD_EXAMPLES, which allows for easier debugging in case something went wrong (see “Resolving issues” below). You might also want to check INSTALL_PYTHON_EXAMPLES, for the same reason.

After you configured everything and no red entries are left, then generated the project files, load the solution in VS2017. Select the Release config, build the ALL_BUILD project, then activate the INSTALL project, and build it to install the Python bindings.

Ideally all these changes would be part of OpenCV itself, currently it looks like a hack specific to GStreamer, which is why I doubt they would accept it as a patch, unchanged.

Resolving issues

Sometimes there can be errors when loading OpenCV and GStreamer from Python, due to path issues, or having provided the wrong libraries to OpenCV, etc.

As a general advice: make sure there are no wrong / old paths set in the environment variable PATH, or other environment variables, such as GSTREAMER_DIR, that point to directories of previous OpenCV / GStreamer files.

(The debugging procedure below is pretty specific to my needs, it should be possible to find a more generic, and easier to follow procedure for everyone, if there is any interest.)

As a more targeted way to trace down the cause, a first good step is to see if GStreamer works from OpenCV in C++. If you successfully compiled OpenCV, open the project samples/cpp/videocapture_basic. From there, open the file videocapture_basic.cpp and find this line: + apiID);

Comment it out, and append these two lines:

cv::String gst_str = "udpsrc port=5200 ! gdpdepay ! rtph264depay ! avdec_h264  ! videoconvert ! appsink sync=false";, cv::CAP_GSTREAMER);

Select videocapture_basic as the start project, then run. It should patiently wait for a stream coming from GStreamer. From another computer, in my case a Raspberry Pi in the local network, provide the stream by executing this console command:

gst-launch-1.0 -v rpicamsrc preview=0 bitrate=2000000 sensor_mode=6 vflip=true ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! udpsink host= port=5200

If a window pops up that displays the video, OpenCV was compiled properly, and GStreamer works well. The next step is doing the same test with the equivalent Python sample.

A likely cause for errors is to have the PATH set up wrong or having started the wrong Python environment / Anaconda / Spyder version (possibly because start menu links are wrong or outdated from other installs). It might also be that Python / Anaconda modify the PATH variable or use other strategies to load DLLs which ultimately cause it to load the wrong ones.

Resolving issues such as loading DLLs that are missing imports, or DLLs that cannot be found, is a lot easier to debug from C++. So, for this kind of error, it should be tried to figure it out with the simple sample project videocapture_basic, with the slight modifications as mentioned above.

A fully functioning DIY bread-board computer

Ben Eater has created an excellent 8-bit computer that is true to the essential architecture of modern computers, yet is simple enough to fit on a few breadboards. It uses DIP-switches and push buttons as inputs, and LEDs and 7-segment displays as (debug) outputs. Even step-wise execution by stepping the computer clock is possible, such that every part of the computer can be observed as it functions and the internal state and memory can be modified by switches.

Continue reading

How pull-up resistors really work

There are many explanations of pull-up or pull-down resistors that gloss a bit too much over the details, keeping you in doubt about how they really work, especially in conjunction with microcontrollers.

To improve our understanding, we will use a simplified schematic that models a microcontroller input-pin connected to a switch and a pull-up resistor. Then we calculate the voltages on the input-pin resulting from a closed or open switch.

Continue reading

Character encoding confusion

HxD will extend character encoding support, and I am looking for the best way to name character encodings. So far, you can only pick between the following four to affect the text display in the editor window:

  • Windows (ANSI)
  • Macintosh

Additionally, in the Search window, Unicode (UCS-2LE) can be selected using a checkbox to override the current editor window encoding. I’d like the character encoding selection to be more uniform, flexible, and clear in future. Continue reading

How to understand raw data in a hex editor?

All data in a computer, including files, is a sequence of numbers. But almost no program shows data in such a raw format, except for hex editors, which can make this concept pretty confusing and abstract. (This actually was one of the motivations for me to write such a program: to understand data and representations better.)

Data encoding, decoding and representation is a big topic, but for many applications of hex editors a few concepts are enough. We’ll start with a brief answer to this question: How do I make sense of (hexadecimal) numbers in a hex editor?

These or similar formulations seem to be popular variations of the above question:

How do you translate hex to English?

Can I change the text to English (or another language)?

What are those ‘random’ numbers on the left in the hex editor?

How do you know if the text representation on the right in a hex editor is valid?

Continue reading

Reading process memory / RAM


One of the most common questions I get regarding HxD is about obtaining source code to understand and reproduce some of its basic functionality. The most frequent points of interest are how the RAM editor reads / writes memory of other running programs (i.e., processes) and how the disk editor reads from / writes to storage media.

Yesterday, when Mohamed A. Mansour, who will teach an Operating Systems class, suggested this information might be useful for his students, I thought it was a good opportunity to start my blog and write it up in a proper way.

This post is about reading memory that belongs to another running program (aka. process), and will be the first in a series of posts about the implementation and design of HxD.

Continue reading