search

nadjieb / cpp-mjpeg-streamer

C++ MJPEG over HTTP Library
MIT License
135 stars 39 forks source link

"revents != POLLWRNORM\n" (publisher.hpp/153 line) #41

Open david-the-stranger opened 10 months ago

david-the-stranger commented 10 months ago

After connecting more than the maximum number of connections from other users' browsers until access is no longer possible, and then reconnecting (F5) from the existing connected browser, a runtime error with the message "revents != POLLWRNORM\n" occurs. image

The location is line 153 of publisher.hpp. Is there an appropriate solution when excessive connection requests occur from different users?

kamalnadjieb commented 10 months ago

Hi @youngbolee ,

I will check and try to reproduce the error this weekend (Bangkok/Jakarta time). Meanwhile, could you please tell me the detailed step-by-step on how to reproduce the runtime error?

Thank you.

david-the-stranger commented 10 months ago

Thanks to you(@kamalnadjieb) for the quick comment. :) First, I created 4 stream channels using "c++-mjpeg-streamer". After that, I connected 4 streams in Chrome and 4 streams in Firefox and 4 streams in Firefox Nightly, Additionally.(p.s: During the FireFox Nightly phase, the server has already silently crashed) Then, I attempted to connect 4 streams from Edge, and all 4 connections failed. Afterwards, when I press F5 in Chrome to reconnect, "c++-mjpeg-streamer" throws an exception.

kamalnadjieb commented 10 months ago

Hi @david-the-stranger ,

I've tried to reproduce the runtime error that you've experienced but I didn't get the error.

The c++ code that I use to test the streams

#include <opencv2/opencv.hpp>

#include <nadjieb/mjpeg_streamer.hpp>

using MJPEGStreamer = nadjieb::MJPEGStreamer;

int main() {
    cv::VideoCapture cap(0);
    if (!cap.isOpened()) {
        std::cerr << "VideoCapture not opened\n";
        exit(EXIT_FAILURE);
    }

    std::vector<int> params = {cv::IMWRITE_JPEG_QUALITY, 90};

    MJPEGStreamer streamer;
    streamer.start(8080);

    while (streamer.isRunning()) {
        cv::Mat frame;
        cap >> frame;
        if (frame.empty()) {
            std::cerr << "frame not grabbed\n";
            exit(EXIT_FAILURE);
        }

        std::vector<uchar> buff_bgr;
        cv::imencode(".jpg", frame, buff_bgr, params);
        streamer.publish("/bgr1", std::string(buff_bgr.begin(), buff_bgr.end()));
        streamer.publish("/bgr2", std::string(buff_bgr.begin(), buff_bgr.end()));
        streamer.publish("/bgr3", std::string(buff_bgr.begin(), buff_bgr.end()));
        streamer.publish("/bgr4", std::string(buff_bgr.begin(), buff_bgr.end()));

        std::this_thread::sleep_for(std::chrono::milliseconds(10));
    }

    streamer.stop();
}

index.html

<html>

<body>
  <img src="http://localhost:8080/bgr1">
  <img src="http://localhost:8080/bgr2">
  <img src="http://localhost:8080/bgr3">
  <img src="http://localhost:8080/bgr4">
</body>

</html>

I run my program on macOS Intel machine and open the index.html file on all below browsers at the same time and still work just fine although a bit laggy:

Could you specify the environment when the runtime error happened? Thank you.

david-the-stranger commented 9 months ago

Hi, @kamalnadjieb

Sorry for the late reply. After struggling with my broken iPhone yesterday, I came back with the new iPhone 15. :) . Anyway, When I ran your codes, I panicked for a moment when I saw that it worked well in all the browsers listed below.

So, I compared and analyzed the your code and the code I used. My existing html written with CSS and JavaScript looked somewhat complicated, but the important difference was simple. I did not use localhost or 127.0.0.1 as the mjpeg stream URL, but used the ip-address provided by the router's DHCP. And I want to show the mjpeg stream to the outside, so I need this method. Of course, using Real Ip-Adress shouldn't be a problem, but unlucky, I realized that the error I experienced occurs when browsers such as Firefox-Nightly try to connect by updating HTTP URL for the Real-Ip Address internally to HTTPS. Since I am a beginner in web development, I could not have predicted that something like this would happen. The issue of updating to HTTPS is the first step in the process before a problem occurs. There are still questions about the next steps, but I don't think I can handle them anymore. I apologize for causing issue over something trivial. The easiest solution is to tell users not to use some browsers.. Nevertheless, if you want to reproduce this problem again, I think you can reproduce it without difficulty in a Windows 11 environment. Thank you for your interest.