-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Regression in v0.20.3 for proxying ondemand rtsp stream on wyze cams with wz_mini_hacks #1292
Comments
Hello, please post server logs with |
Sorry about that, here you go. Thanks!
|
Noticed there is v0.20.4 out, I tested that and issue remains:
|
Thanks for posting the log, the issue has been fixed and the fix will be included in the next release. In the meanwhile, you can test the fix by using this nightly release: (link removed) |
Thanks, I can confirm the nightly release fixes the issue! |
fixed in v0.21.0. |
This issue is being locked automatically because it has been closed for more than 6 months. |
Which version are you using?
v0.20.3
Which operating system are you using?
Linux
Describe the issue
I use rtsp-simple-server to proxy some wyze rtsp feeds (using wz_mini_hacks). This works fine with v.0.20.2 but in 0.20.3 I get the following error:
v0.20.3
2022/12/10 18:36:39 INF [path wyzetwo] [rtsp source] started
2022/12/10 18:36:39 INF [path wyzetwo] [rtsp source] ERR: unable to parse track 2: invalid clock (16000)
2022/12/10 18:36:44 INF [path wyzetwo] [rtsp source] ERR: unable to parse track 2: invalid clock (16000)
2022/12/10 18:36:49 INF [path wyzetwo] [rtsp source] stopped
2022/12/10 18:36:49 INF [RTSP] [conn 192.168.0.xxx:xxxxx] closed (source of path 'wyzetwo' has timed out)
In 0.20.2 the log shows
2022/12/10 18:37:19 INF [path wyzetwo] [rtsp source] started
2022/12/10 18:37:20 INF [path wyzetwo] [rtsp source] ready: 2 tracks (H264, Generic)
2022/12/10 18:37:20 INF [RTSP] [session 735049277] created by 192.168.x.x:xxxxx
2022/12/10 18:37:20 INF [RTSP] [session 735049277] is reading from path 'wyzetwo', with TCP, 1 track (H264)
Describe how to replicate the issue
The docker repository doesn't seem to be updated with the latest version yet so this was tested using the amd64 linux binary directly.
My configuration yaml has the following entry:
wyzetwo:
source: rtsp://xxx:[email protected]:8554/unicast
sourceOnDemand: yes
This is a simple ondemand proxy feed, I am using TinyCam on android as a client.
I noticed in the release notes some changes to the clock rate detection, I'm not sure what this means or I need to update my YAML configuration to reflect this update. Rolling back to 20.2 has fixed it for the time being.
This issue seems to only impact the rtsp feeds from wyze cameras using wz_mini_hacks. I tested the rtsp feed using a Eufy camera and a Xiaomi camera using fang-hacks and both are fine. There might be something non-standard about the feed coming from the wyze (wz_mini_hacks) cameras. I do not have currently have a wyze camera with the old rtsp firmware installed to test that unfortunately.
Did you attach the server logs?
yes, see above
Did you attach a network dump?
no
The text was updated successfully, but these errors were encountered: