RTSP Client will panic after a long time running

[linw1995]

https://github.com/nareix/joy4/blob/bd41a3b90ff2205431b4a74e4d45d6f63e987519/format/rtsp/client.go#L436-L443

After a long time running (13h+), https://github.com/nareix/joy4/blob/bd41a3b90ff2205431b4a74e4d45d6f63e987519/format/rtsp/client.go#L438 will throw: panic: runtime error: makeslice: len out of range error.

[linw1995]

using it to convert the live RTSP stream into websocket-flv. And it will panic after a long time running.

[lanybass]

解决没？ left := blocklen+4-len(peek) 把这几个打出来看。 我觉得有可能left是负数了

[thenrich]

So after struggling with this issue myself for some time when streaming from some cheap IP cameras I think I've narrowed down the issue to a problem with the keep-alive and my cameras' RTSP implementation.

Since this only occurs after several hours of streaming, it's a challenge to debug.

What I've seen is that the second byte in the RTSP data is normally 0 (channel 0) when the stream is running properly. Then, I stop seeing channel 0 and only see channel 1, which should be the interleaved RTCP messages. After a bunch of these the data length (bytes 3 and 4) is less than peek resulting in the calculation of a negative makeslice.

My guess here is that my cameras are still sending RTCP messages but stop sending on channel 0 because they think my client is no longer listening by not honoring OPTIONS as a keep-alive.

I've changed the OPTIONS method of the keep-alive to GET_PARAMETER which some Googling has shown to be necessary for some RTSP implementations on IP cameras. Ever since this change I've only had some TCP timeout panics instead of makeslice: len out of range.

If this resolves the issue I'll submit a PR for either configurable keepalives or maybe just 2 keepalives to cover both cases.

[cedricve]

I just had the same issue. @thenrich did you find out?