Tapo C320WS image stream invalid jpegs.

[digitaltrails]

On the Tapa CS320WS onvifeye is receiving broken jpegs:

I'm going to raise this with TP-Link. In the meantime I will implement a setting that will disable the normal image feed and instead extract one from from video stream. This may actually be better because it will have the same resolution as the video.

[digitaltrails]

@jb1923 are you seeing this issue with the C310?

I'm not seeing it with the C125 or C225.

[jb1923]

No problem with jpgs on my c310

[digitaltrails]

No problem with jpgs on my c310

Glad to hear that, perhaps my issue is actually a config issue. It's been a long time since I last looked at the code or how it's configured, so an error on my part is certainly possible. I will investigate that later.

For now I've implemented and committed a camera_grab_stills_from_video config option (noted in the README.md. That will at least allow me to go ahead and install the camera.

[digitaltrails]

I seen corrupt jpegs and images from a C125 which seem to be because UDP packets are getting dropped. So that's another possibility.

[jb1923]

I was using motion and motion.conf has this option:-

rtsp_uses_tcp

Type: String
Range / Valid values: on off
Default: on

This option specifies the transport method for rtsp cameras. The TCP transport is highly preferred because without this option the rtsp images are frequently corrupted and result in many false positive values and images that appear to be smeared. Off indicates that UDP will be used.

Although I would have thought the video would also be corrupted if udp was a problem. By the way Motion uses 200% of my rpi cpu (decoding the rtsp stream), while using onvifeye, cpu use is negligible.

[digitaltrails]

Although I would have thought the video would also be corrupted if udp was a problem. By the way Motion uses 200% of my rpi cpu (decoding the rtsp stream), while using onvifeye, cpu use is negligible.

Exactly so. When I implemented extracting frames from the video, I found the jpgs were sometimes also corrupted. So I looked at the videos and found they had glitches in them too. It doesn't always occur. Perhaps there is other stuff happening in the network. Perhaps WiFi interference (there are 6 excavators, a couple of bulldozers, and a bunch of other machines working on a development just over my back fence).

[digitaltrails]

By the way Motion uses 200% of my rpi cpu (decoding the rtsp stream), while using onvifeye, cpu use is negligible.

I wanted to avoid recording and analysing continuous feeds. I didn't like the idea of running a rpi server hot 24/7 just in case of rare events. These Tapo cameras with there ONVIF feeds and event detection have turned out to be quite good (at least as far as my needs are concerned). The available ONVIF examples and docs are a bit scattered and sketchy, especially whe python asyncio-io is thrown into the mix, but AI helped make some sense of all of it.

[digitaltrails]

This option specifies the transport method for rtsp cameras.

I found an ffmpeg option rtsp_transport='tcp', so I changed the code to use it. However, I'm not sure what it actually defaults to, and I haven't had a lot of luck getting useful feedback from ffmpeg on what it is actually using. I will just have to try the setting and see if things behave better.