I have a colleague who likes to create classes and put static methods in them, instead of having functions in a namespace. There area already topics about what is better, e.g. Namespace + functions versus static methods on a class.
However, if you have big loop calling one function after the other with 4k lines total, I think you are making some mistakes. Since you seem to be doing image processing, maybe I can help.
Taking a very high-level view of your task, you have a video stream as input, and some detections as output. Very likely you detect something in a frame.
If your detection has a state, i.e., detections depend on results from previous frames, this is already grounds for a class. Saving this in global (albeit namespaced) variables is simply not right in C++. If it doesn't, then your input is no longer a video stream, but an image, and you should design your interfaces in a way that they take an image. Running your code then for several images from a video stream, especially extracting images from the stream, is something that should be separated from the main logic.
Then you say your functions are being called one after another. Very likely, the order matters? If it does, inputs from some functions depend on output from others. This is also a state which could be saved, and again grounds for writing a class. The question how to structure it exactly depends on your exact task. I recommend you take a piece of paper and a pen, and draw a block for each component (function) of your algorithm, as well as your inputs (images, possibly other data) and outputs. Then draw lines what depends on what. This helps for getting an idea how to structure your code.
Finally, a little challenge: Try to make sure none of your functions is longer than 20 lines (you can do 10, but it gets harder). Trying to achieve this has several good effects. First of all, all your logical units (functions) are short and have defined inputs and outputs. Also, that makes them easy to read (a 5-line-function rarely needs much documentation and often speaks for itself) and easy to test and debug. Then, in 4000 lines of code, you should start thinking about unit tests anyway, and short functions are helpful there, I think.
You shouldn't take the 20-line thing as a rule, there are plenty good reason for having longer functions (although usually not many of them). Trying to keep your functions short and to the point is a good goal, however.
Coming back to image processing, in my experience this strategy works very well there. Also tackling your problem from a high-level view and refining it (divide and conquer) can help you producing well-structured and maintainable code.
