stream without any timeout?

[muellerto]

Currently I use a WebRtcStreamer object on my webpage like this:

    webRtcServer0 = new WebRtcStreamer("video0", location.protocol + "//" + location.hostname + ":8000");
    webRtcServer0.connect("rtsp://...", "", "rtptransport=tcp&timeout=60");

and then I have a video tag:

    <video id="video0" width="400" height="275" controls muted playsinline></video>

In the connect line there's a timeout parameter. And when the timeout is reached the connection stops. So this is a planned interruption. But the use case I have has no planned interruption. I need to see cameras as long as they send frames, even for months.

I tried the following:

• no timeout parameter -> then a default is used (probably 60)
• specify 0, -1, undefined, null or NaN -> this kills indeed the webrtc-streamer process
• specify a very big number -> this does not work, the connection fails

My conclusion is a timeout must be an integer in the interval of 1 ... 65535 minutes which means maximum 45 days.

Question: Is there really no way to get a longer timeout or a truly unlimited connection? Or do I have to handle the planned interruption and reconnect myself?

Update: my experiments show that a value of 65535 (FFFF, the biggest two-byte unsigned integer) is accepted but doesn't work as expected. The connection stops already after an hour. This means that the biggest value is much less, probably 32767 minutes (22 days). Will check that.

Update: even 10000 doesn't work. The connection stops already after an hour. So what's the longest timeout possible???

[mpromonet]

Hi @muellerto
If the connection is closing, there should have a problem.
It might be your rtsp server neither send RR packet, nor implement the classic RTSP get parametrer keep alive.
Best regards
Michel

[muellerto]

My RTSP streams are generated endlessly from MP4 videos by FFMPEG and the mediamtx tool. They don't break up after an hour. Indeed they worked already for more than 24h correctly.

I follow another strategy now: disconnect and (re)connect in short intervals, 2 minutes only. I do this using two <video> tags per stream (same size, same position on the webpage, different IDs) - at a given time there's always one hidden and the other one visible.

When the visible one streamed a video for 2 minutes I create a new WebRtcServer object in background for the hidden <video> tag and let it open a new connection for the same stream. When this has been established I make the visible <video> tag hidden and the hidden one visible, then I disconnect and forget the old WebRtcServer object. This doesn't even flicker. Perhaps I can optimize the interval a bit, 10 minutes or even 20.

Currently I'm watching the webrtc-streamer process in a longer test, how it handles so many disconnects and connects, memory behavior and so on.

[mpromonet]

Hi @muellerto
You may look to logs when it disconnect, maybe my assumption of rr report or keepalive are wrong. I guess there is some logs indicating reason.
I was understanding that connection breaks between rtspserver and rtspclient in webrtc-streamer but it may also be between webrtc-streamer and browser which is not impacted by timeout parameter.
I guess you can understand this from log, but you can also use the same client https://github.com/mpromonet/live555helper and see it the connection ends or not. This rtspclient based on live555 is also used in https://github.com/mpromonet/rtsp2web that use websocket between server and browser.
Best regards
Michel

[muellerto]

Yesterday I started an over night test which stopped after about six hours. The webrtc-streamer process terminated without any message.

So I started it again this morning using --verbose and it stopped suddenly after only some minutes. Note: this test contains 12 local RTSP streams. Each stream is endless and has different video contents but no audio (this should simulate traffic cameras). After 2 minutes the webpage disconnects and reopens all streams, this is intended. But somehow it stopped the webrtc-streamer process. (Yesterday it survived some hundred cycles!) My RTSP streams are still good, VLC shows them perfectly.

The stdout log of webrtc-streamer shows nothing special:

Version:v0.8.15-dirty/Windows-AMD64 civetweb@v1.16 webrtc@60ccc50215-dirty live555helper@2678635
nullLogger level:3
HTTP Listen at 0.0.0.0:8000

That's all, including the crash.

The stderr log is attached. I guess the first number on each line means "seconds from start", so "125" means 2 minutes and 5 seconds, this would be the first closing of the connections. But what then? I don't get a clue here.

2.log.gz

[mpromonet]

Hi @muellerto

From your log it seems, lots of frames are drop because timestamp is not increasing. The ffmpeg decompressor didnot support it, I did not check if B frame are now supported, at the end, decompression fails, probably error could be better managed. I reset the decoder in case of error in 3b31e48

Anyway you could try the option -o, that avoid decompression.

Best Regards,
Michel.

[muellerto]

Better! Especially the parameter -o reduces the CPU load a lot (one browser showing 12 videos caused 10% load, with -o it's about 1%). But webtrc-streamer still crashes after less than an hour.

Today I got a number of real traffic cameras producing native RTSP streams which belong to the intended use case I develop for. I'll see if this brings new informations.

Update: the webrtc-streamer crash I had was still with my webpage which closed and reopened the connections after 2 minutes. When I instead specify 10000 minutes as timeout the connections do not stop after 60 minutes. With -o I have now running connections for more than 2 hours and they are still alive ...