-
-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(webcam): add support for go2rtc webrtc #1651
Conversation
Signed-off-by: Stefan Dej <[email protected]>
Signed-off-by: Stefan Dej <[email protected]>
Language file analysis report:
|
Thanks for this! Amazing work as always! |
@meteyou I haven't tried this yet, my build environment is still stuck on 2.4.1 when I did my last set of PRs. Do can you send me an alpha build with this in I can test it out for you? Thanks |
The builds for PRs should be available inside the checks. Just hit |
@mryel00 thanks I did not know this! wow! testing now! |
I am using frigate / go2rtc behind an ssl, so need it load wss. at the moment when I try this I am seeing.
the url I that I set in the settings was
|
moving to the direct URL.
I think there is still an issue when using HTTPS or WSS |
Also just sitting there streaming I am seeing this. Seems like its terminating after a few minutes, if I am using the stream.html that go2rtc provides I dont see such a problem.
|
on the left is the mainsail window, on the right is the same stream URL loaded in a browser directly. Untitled.Project.mp4 |
Signed-off-by: Stefan Dej <[email protected]>
Language file analysis report:
|
@vajonam thx for the report. i pushed a fix for that. please can you doublecheck, if it works with and without ssl? you only have to open mainsail with ssl and mainsail will also switch the webcam url to ssl (both have to be SSL or without SSL. mixed is not allowed in the browser) |
@meteyou thanks the commit has fixed the ssl/non ssl issue. Both works However the periodic disconnection is still an issue. This is a non issue when using the html from go2rtc. I suspect there is some other issue that closes the websocket? Other webrtc instances (same stream on home assistant, or frigate itself) do not show this disconnection. I had posted a video about the disconnects. |
This is what the console logs show during the Werbrtc socket disconnections.
|
Signed-off-by: Stefan Dej <[email protected]>
@vajonam i pushed a fix. pls double-check it, if it fix the disconnecting issue. |
Language file analysis report:
|
testing it now. |
@meteyou still one error. but the disconnects and reconnects still seem to be around that has not fixed the issue.
|
I am re testing. Sometimes the PWA is cached am messed up my testing. I am still testing to see if the connections cause the stream to restart. |
Signed-off-by: Stefan Dej <[email protected]>
Language file analysis report:
|
@meteyou. The tag for the video tag worked. However the disconnection of the stream is still happening. I will contact you on discord, as I would like to send you the video privately. |
@meteyou I was doing some more digging and I can see the following errors on go2rtc only from mainsail.
Apparently missing the |
Websocket is a browser internal package/lib and I use the identical implementation as in the example file. |
Okay. I will investigate. There are 2 reverse proxies, one in the frigate software itself that proxies go2rtc, then for me to apply ssl to that connection. as far as I know until know I have enabled WSS support for both (otherwise it wouldn't even connect) I will keep searching! |
@vajonam I just checked the go2rtc version that frigate is using. It seems like they are still on v1.2 that got released in february. They will update it with frigate v0.13. |
I am running |
ok. that sounds like the 1 minute cycle and could be the issue. |
I bypassed that 1st frigate provided nginx (less control over), and then on my SSL reverse proxy added
so far up for a more than a minute or so. this might be a good idea to point out timeout / disconnection issues in the docs. |
@vajonam i don't think that these settings in the second reverse proxy can fix the first one. i think these settings have to be made directly in the first one. but I just realized that I still have to write the docs in general... |
@meteyou I think you misunderstood me (we are both saying the same time) the only way to get it work with frigate provided go2rtc is bypass its nginx, because it too late if that is used. (expose port directly on that container) , and then if doing any other reverse proxy maybe apply the settings |
Signed-off-by: Stefan Dej <[email protected]>
Language file analysis report:
|
FWIW, in Fluidd I ended up porting the full WebRTC functionality in stream.html to add support for this, which seems to have fixed the issues @vajonam was experiencing. I am considering porting the rest of the code so that it would support not just WebRTC but the whole thing (that would mean keeping "webrtc-go2rtc" camera type as legacy and adding a new "go2rtc", or something like that). That way all users would need to do is supply the full stream.html address and we will handle it on our side. |
thx for this information. but the issue from @vajonam is a wrong reverse proxy (which i said from the beginning, but he rather switched to fluidd and left out functions to avoid his misconfig, pls check the comments above). I will now merge this streamer-client so that we can use it to run tests for crowsnest. I can't say at the moment whether we will then go deeper into go2rtc or drop it in the future... The situation with the RPI5 without HW encoder is very bad and we have to look in all directions... |
To be clear, yes the reverse proxy was an environment issue, which did cause reconnects that I was reporting. But I found other issues specific to iOS and Safari that were addressed in the rewrite. |
@vajonam if you mean the reconnect issue in your second PR in fluidd (fluidd-core/fluidd#1257), that's exactly why i have the reconnect in my implementation. that's why i didn't want to remove it... if you mean another issue, pls explain it... |
This was manifested as an issue that was only happening on iOS, where the connection would stall and freeze and not reconnect. It was specific to how the state change of the peer connection socket was handled on disconnected state. I looked at the stream.html that didn't have this issue and started looking for the differences, I did add a commit for this on the branc that addressed this issue. This was then refactored by @pedrolamas |
Specifically this is what helped the issue on iOS. |
thx for this link! it looks like i missed this in this implementation. i also use this in the "camera-streamer" implementation. i think i should add this also here... |
Signed-off-by: Stefan Dej <[email protected]>
…ected streams Signed-off-by: Stefan Dej <[email protected]>
Signed-off-by: Stefan Dej <[email protected]>
Language file analysis report:
|
Description
This PR add support for go2rtc webrtc streams.
Related Tickets & Documents
fixes #1396
Mobile & Desktop Screenshots/Recordings
none
[optional] Are there any post-deployment tasks we need to perform?