RTSP: Fix timestamp reset after reconnect

[seydx]

When a new client connects and requests a different track (e.g., first client wants video only, second client wants video+audio), go2rtc performs a reconnect. Some cameras (e.g., Tapo via ONVIF) reset their RTP timestamps to 0 after reconnect, which causes existing clients to receive packets with much lower timestamps than before.

Error in ffmpeg:

[null] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1051 >= 0

This causes ffmpeg to skip frames until it reaches the last valid PTS.

Solution

Detect timestamp resets (when timestamp == 0 after having received packets before) and apply a constant offset to maintain timestamp continuity for existing clients.

Testing

# Terminal 1: First client (video only)
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://localhost:8554/camera?video" -f null -

# Terminal 2: Second client (video+audio) - triggers reconnect
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://localhost:8554/camera" -f null -

Expected: No "non monotonically increasing dts" errors in first client.