Some times go2rtc serves only audio to webrtc consumer

[felipecrs]

For some reason this happens some times, I was able to capture a video demonstrating the issue:

video_2022-11-17_16-55-25.mp4

Video with full quality: https://1drv.ms/v/s!AntpCaY1YjnMi6EVW_i6yy6p2utDUg?e=js4gUj

[AlexxIT]

This is related to #65. Your stream starts from only audio consumer. You can't request new track from RTSP after play command. There is should be some restart logic.

[felipecrs]

Right. That would make sense. The only consumer who requests only audio in my streams is go2rtc itself so it can transcode to another format.

[felipecrs]

Ok, just to update: I found a way to reliably reproduce the error on my end (I just need to restart a bunch of cameras). If you need something like logs or so, let me know, and I can capture.

[AlexxIT]

This situation is very easy to reproduce. It's not a bug. These are limitations of the current capabilities of go2rtc.
Once an RTSP stream is started, you cannot change its number of tracks. But this can be improved by restarting the stream. Not easy.

[felipecrs]

@AlexxIT another thing which I noticed:

chrome_rHzokzXsbj.mp4

I think this is not normal, is it? So many active connections which don't seem to disappear automatically.

[NickM-27]

I've seen that before. It was common before #39 was merged. At this point I haven't seen it since then.

[felipecrs]

Hm... just to be clear I'm using the latest version 0.1-rc.3.

Once an RTSP stream is started, you cannot change its number of tracks.

Since who is initiating the RTSP stream is go2rtc itself (because of the self-links with ffmpeg:stream_name), I think go2rtc can be smart enough not to try to initiate a stream if that incoming stream isn't yet ready. Or maybe my understanding is not correct. EDIT: the next idea is better, I think.

Another idea which I have is for go2rtc to somehow block the stream entirely if the dependent source isn't available. Something like:

streams:
  camera.morro:
    - rtsp://admin:admin@192.168.1.34:6554/stream_1
    - ffmpeg:camera.morro#audio=aac

The camera.morro is used as source in the second source, therefore, there is an implied dependency on the first source by the second source. Go2rtc could understand this dependency, and when source 1 timesout or stops working for whatever reason, it should not try to serve from source 2 and instead keep waiting for the first stream to be available again. Maybe it could even reply back to the consumer with a useful error code, like "503 (service unavailable)" or something like it.

[AlexxIT]

Source 2 will always fail if source 1 fail.

[AlexxIT]

Probably fixed in v0.1-rc.5

[felipecrs]

On a quick test, it seems to be fixed indeed. Thank you very much!