BinaryBits's profile - activity

Thank you so much! I tried out your code and it worked perfectly on my machine. I will go ahead and implement your method into my application. I appreciate all the help!

Pklab, thank you for the reply. I added a simple:

if (fileSystem.FileExists(output_file_path))
    {
        logging->WriteLog(output_file_path + " already exists!");
        return false;
    }

Unfortunately though, it doesn't seem to have solved the problem. The output filename has now been confirmed to be unique every time.. are there any known gotchas with VideoWriter that perhaps I'm missing? Since it fails quietly, it's a real pain to figure out why it blew up. I deleted and re-downloaded my OpenCV 3.0 libraries and source in hopes that maybe something was corrupt, to no avail. I appreciate your help on this strange issue.

output_file_path is basically "C:\Users\Test\Desktop\" with the current date and time used for the file name. For example 2015-11-13-15-47-42.avi. So it is different each time VideoWriter is opened.

Here's how I am calling this function (from a thread):

    while (GetMessage(&ThreadMessage, NULL, 0, 0))
{
    Streaming streaming = Streaming();
    if (!streaming.DecodeVideoStream(thread_socket, output_path, thread_id_string))
        break;
}

Hello,

I writing a C++ application for Windows that handles video streaming over sockets. In this program, the main thread listens for connection attempts, and creates a new thread for each client that connects. That new thread essentially takes the data stream of the socket, converts it to a Mat, and then uses a VideoWriter to write each frame to an avi file. This new thread also limits each file to a set number of seconds in length. I've tested using one client and video gets recorded just fine. But the moment I try to create another thread for a second socket, VideoWriter fails to open the output in that new thread. Unfortunately VideoWriter fails quietly (I use writer.IsOpen() to check) so it's tough to trace where exactly it is breaking. I am using x264VFW as my video encoder, with default settings. For this example, the frames being sent over the socket are in grayscale, hence the CV_8UC1.

Here is the method that is called inside each client thread:

bool Streaming::DecodeVideoStream(Socket socket, std::string output_file_path, std::string thread_id)
{
    Size S = Size({ 320, 240 });
    time_t endwait;
    time_t start = time(NULL);
    time_t seconds = 30; 
    endwait = start + seconds;

    VideoWriter writer(output_file_path, CV_FOURCC('x', '2', '6', '4'), 25, S);
    if (!writer.isOpened())
        logging.WriteLog("Failed to create video file: " + output_file_path);

    while (start < endwait)
    {
        Mat  webcamFrame = Mat::zeros(S, CV_8UC1);
        int  frameSize = webcamFrame.total()*webcamFrame.elemSize();

        char* socketData = new char[frameSize];
        memset(socketData, '\0', sizeof(char)*frameSize);

        int packetSize = socket.RecvData(socketData, frameSize);
        if (packetSize > 0)
        {
            writer.write(Mat(S, CV_8UC1, socketData));
        }
        else
        {
            delete[] socketData;
            logging.WriteLog("Recv() returned -1. ", __FUNCTION__);
            logging.WriteLog("Error code: " + std::to_string(WSAGetLastError()), __FUNCTION__);
            return false;
        }
        delete[] socketData;
        start = time(NULL);
    }

    logging.WriteLog(thread_id + " Reached clip time limit.", __FUNCTION__);
    return true;
}

I would greatly appreciate any suggestions, as I do not have much experience with running VideoWriter in multiple threads. Maybe there's something stupid I'm missing.

UPDATE (11/16/2015)

So after a lot of hair pulling, I decided to create a new project with barebones code in it to see if I could reproduce the problem with just the essentials. I have created a pastebin here with the code. It's short and should help give a better picture into what may be going on here.

When I run the code (As shown in the pastebin), I get a familiar output that indicates the first thread managed to create the output file, but the other 4 failed:

Still totally confused, and would appreciate any help. -BinaryBits