kasa stream not functioning

[fiveangle]

I have a Kasa EC70 that ive been using with Frigate with a proxy https://github.com/kevdog114/kasa-cam-rtsp-streamer which uses a very simple method to collect/republish the stream:

#!/bin/sh
echo "Starting camera proxy."
echo " URL: $APP_CAM_URL"
echo " OUT: $APP_RTSP_URL"

curl "$APP_CAM_URL"  -k --ignore-content-length \
       	--output - | \
	ffmpeg -y -i - \
	-s 480x270 \
	-c:v copy -c:a copy \
	-f rtsp -rtsp_transport tcp $APP_RTSP_URL

That container publishes to a mediamtx container, which then frigate connects to directly. It's been working fine enough, but has no retry logic (or hadn't: kevdog114/kasa-cam-rtsp-streamer#1) . But any hiccup, and the streams would drop until re-kicked).

I had tried to get to work with the go2rtc builtin to Frigate a while back with no luck, but figured I'd give it another try. Unfortunately, still no love. Frigate ver is 1.9.9 (fa580c5). Also tried latest release: no better. So tried to recreate the curl=>ffmpeg pipeline that the working container uses, but within frigate/go2rtc but was not successful. Attempting various iterations of moving double-quotes and single-quotes around didn't change much.

Here's my attempt to recreate the functionality of the working setup within go2rtc by setting the go2rtc section in frigate for this camera to:

  hallway: exec:curl "https://davejohnson3000%40gmail.com:Hdw8p8qyNGwVnQe8L%21@192.168.50.12:19443/https/stream/mixed?video=h264&audio=g711"
    -k --no-progress-meter --ignore-content-length --output - |
    ffmpeg -hide_banner -y -i - -s 1920x10080 -c:v copy -c:a copy
    -f rtsp -rtsp_transport tcp {{output}}

But always got various 'command not foumd' type of entries in the log. So I figured it's high time to drop in here and see if we can't solve this within go2rtc directly.

All attempts to configure a "kasa://" camera stream in go2rtc would just not connect, and I'd watch Firgate keep re-spinnng it's ffmpeg proces.

-=dave

[AlexxIT]

All attempts to configure a "kasa://" camera stream in go2rtc would just not connect, and I'd watch Firgate keep re-spinnng it's ffmpeg proces.

I think it is best to get this camera to work using the kasa protocol. Your statement "just not connect" doesn't sound very clear.

[fiveangle]

I would have expanded if I had more. The only info go2rtc provides is:

i/o timeout

And that's only the error that is presented when clicking the "stream" option. There is zero entries in the log.

So when I said, "just not connect", I couldn't be any clearer. It's as if it isn't even attempting to connect.

[fiveangle]

streams:
  hallway:
    - kasa://davejohnson3000%40gmail.com:b64pass@192.168.1.12:19443/https/stream/mixed?video=h264&audio=g711

[fiveangle]

On the older version included in frigate, it does generate log entries like so, approx every 10s:

[rtsp] error=streams: Get "https://davejohnson3000@gmail.com:***@192.168.1.12:19443/https/stream/mixed?video=h264&audio=g711": dial tcp 192.168.1.12:19443: i/o timeout stream=hallway

[fiveangle]

And in case it is of use, this is info from ffmpeg on the "working" scenario…

Starting camera proxy...
 URL: https://***:***@192.168.50.12:19443/https/stream/mixed?video=h264&audio=g711
 OUT: rtsp://192.168.50.26:28554/kasa
Attempt 1/10 to publish stream...
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 10.3.1 (Alpine 10.3.1_git20210424) 20210424
  configuration: --prefix=/usr --enable-avresample --enable-avfilter --enable-gnutls --enable-gpl --enable-libass --enable-libmp3lame --enable-libvorbis --enable-libvpx --enable-libxvid --enable-libx264 --enable-libx265 --enable-libtheora --enable-libv4l2 --enable-libdav1d --enable-postproc --enable-pic --enable-pthreads --enable-shared --enable-libxcb --enable-libsrt --enable-libssh --enable-libvidstab --disable-stripping --disable-static --disable-librtmp --enable-vaapi --enable-vdpau --enable-libopus --enable-vulkan --enable-libsoxr --enable-libwebp --enable-libaom --disable-debug
  libavutil      56. 70.100 / 56. 70.100
  libavcodec     58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter     7.110.100 /  7.110.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
Input #0, h264, from 'pipe:':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: h264 (Main), yuv420p(progressive), 1920x1080, 15 fps, 15 tbr, 1200k tbn, 30 tbc
Output #0, rtsp, to 'rtsp://192.168.50.26:28554/kasa':
  Metadata:
    encoder         : Lavf58.76.100
  Stream #0:0: Video: h264 (Main), yuv420p(progressive), 1920x1080, q=2-31, 15 fps, 15 tbr, 90k tbn, 15 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
[rtsp @ 0x7615f3efd380] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly

[fiveangle]

I can also give you access to the camera via tailscale if it would be helpful

[AlexxIT]

Yes, I was just about to ask you for access. You can send it to Telegram.

[TheRealFalseReality]

I think the firmware updated and now requires authentication. I updated firmware recently and now, no stream. I had to re-authenticate using kasa credentials for my kasa power strips.

[fiveangle]

I can reach out via telegram to setup ovpn access for you sometime next week (I'm heading off for the 3-day weekend now) but I was able to make slightly more progress… apparently with "kasa" URI, go2rtc does nothing with the camera feed (?) so doesn't attempt to connect at all, because I grabbed a pcap trace between go2rtc and the camera and it was completely empty.

So I added the ffmpeg line in the config below to remux the video stream (not sure why that's necessary):

streams:
  hallway:
    - kasa://webFriendlyKasaAccountEmailString:base64encodedKasaPasswd@192.168.1.12:19443/https/stream/mixed?video=h264&audio=g711
    - ffmpeg:hallway#video=copy

Then clicked the "stream" link, and it got the following error:

Unsupported Auth: Basic realm="smarthome@tp-link.com"

I've attached pcap traces of the working "hack" (curl | ffmpeg => rtsp to mediamtx proxy), auth session and the session with the above ffmpeg video copy mux that results in the auth log error.

2035-go2rtc_kasa_pcaps.zip

[AlexxIT]

No need for a VPN. Go2rtc has built-in sharing technologies:
https://github.com/AlexxIT/go2rtc/blob/master/internal/pinggy/README.md

Your error means incorrect login/password.

[fiveangle]

Your error means incorrect login/password.

Clearly. The question isn't what the error msg means. The question is why the error is present when the credentials are correct. ffmpeg method requires password auth field to be UTF-8 encoded, and functions correctly. Documentation of go2rtc states it requires base64 encoded password field. Identical password base64-encoded fails as above in go2rtc while succeeds when UTF-8 encoided and passed to ffmpeg. Prior to opening this issue, I even confirmed the base64 encoding of passwd field using both GNU coreutils 9.7 base64, and Darwin 25.2.0 base64 with same result.

Could it be go2rtc handling of the password field -- while it may honor http protocol -- may be slightly different from how ffmpeg handles the same password field, resulting in the behavior difference ? That is what I suspected, and why I provided pcap of both, but reviewing myself, I see you cannot determine the difference due to HTTPS.

Where to go from here ?

[AlexxIT]

The go language has a fairly strict URL validator. It complies with the specification and may not pass things that other applications like curl, FFmpeg or VLC pass.

I can look at your camera. You don't need to set up a VPN.
https://github.com/AlexxIT/go2rtc/blob/master/internal/pinggy/README.md

[fiveangle]

Things have gotten incredibly busy. Will try to make time for this in the next week or 2. Thx for your patience.