Camera recordings have motion artifacts and are pixelated

[lancej]

I am new to HA and am trying monitor and record a few camera streams. (I am also using it for automation.) I am using 3 Tapo cameras (1920/x1080) with ONVIF integration. I am able to get motion detection, live streams, and I can record streams. But the recorded streams suffer from severe motion artifacts, but are otherwise crisp (i.e., when there is no motion.) The artifacts are similar to what is discussed in these recent HA threads:

RTSP camera pixelated view in GUI, but normal in ffmpeg

Hi Folks! I’m having an issue with my Tapo camera, which supports ONVIF and RTSP. When I stream the feed using ffplay or ffmpeg directly, the image is sharp and clean. However, when I add the same camera to Home Assistant via either: The ONVIF integration The Generic Camera (FFmpeg) …the stream becomes very pixelated with artifacts. At first, I thought this might be due to **ffmpeg or CPU usage ** on my Home Assistant host. But to rule that out, I logged into the host and recorded the RTSP…

Lovelace camera stream artifacts and pixelated view

Hello, I have problem with viewing camera stream in home assistant gui: on PC via webbrowser on Android phone app When there is a motion in the stream I all get are strange artifacts. At first I thought it’s a problem with camera or RTSP stream, but accessing RTSP provides a cristal clear & sharp image. Also “Download snapshot” from lovelace gives me a clear image. I’ve tried with direct RTSP from camera and re-streamed from Frigate, different codecs, resolution etc. So I guess we can it c…

But in my case, I don’t believe it is the stream per se or the rendering in lovelace. I think it is related to the recording of the streams. I base this on experiments I performed and reported in the first thread above:

1. The file is bad when copied to another PC and played – so it is in the file.

2. A file made from an RTSP stream on another PC (with VLC) and copied to HA plays fine in HA.

3. The live streams in HA have no motion artifacts. And only lag by about a 1/2 second.

My first question is does any of this sound familiar and is there a direction I should look in to fix it?

I saw WebRTC/go2RTC mentioned in the above threads and fixing on of the posted problems, but I’m not sure that this is the same as what I am experiencing. Does this sound like a problem go2RTC addresses? If it is, I have more specific go2RTC questions.

Any advice will be welcome – thanks in advance.

[CerebralBypass]

Hey I’m having the same issue with my Tapo C520WS. The streams are smooth, no lagging whatsoever but recordings are completely useless, it’s so bad you can’t even make out a person.

CPU isn’t bothered much by it and writing happens to an SSD. Camera is connected to ethernet and has a very solid connection … Not sure how to move forward either.

[lancej]

Maybe we can learn something by how our systems are similar vs different. I am running HA in a VM (VirtualBox under Ubuntu) on an N100 mini-pc w/ 16G ram and a 512G SSD. There is almost nothing else running there. I have three Tapo cameras – a C210, C310, and C320. I do not have SD cards installed on the cameras. I am using all of them in 1920x1080 mode. I am using ONVIF integration for them in HA. I have the recording problem on the main stream and on the much lower resolution sub-stream.

I have done a little debugging and believe that that the problem is the recording, not the network, not the camera, and not the HA playback. I am not sure this is true of the posts I quoted. Those threads (started by the same person) appear to report the solution was WebRTC/go2RTC. I believe the poster was using Frigate.

One clue I found was that the “bad recording” (recorded by HA) showed a frame rate of 9.83fps. But Tapo says that the camera (C310) is fixed at 15fps. That suggests dropped frames. If key frames are dropped, then the motion artifacts could be severe (like what I saw). But I captured the recording exchange in wireshark and saw it was using RTP over TCP so it should not have dropped anything.

[lancej]

I got WebRTC/go2RTC working. It did not solve the problem. I didn’t realize when I started that WebRTC creates no devices or entities. Instead it creates a custom WebRTC card for your dashboard, which is supposed to be lower latency. While it seems incrementally faster than the ONVIF live streams, it did nothing to fix new recordings – they still have serious motion artifacts. Perhaps there is a way of using WebRTC/go2RTC to effect better recordings, but I have not found it.

[lancej]

I’m on to something – I think it is specifically related to the Tapo cameras (at least in my case). I tried it with a Chinese SimiCam at the same resolution/rate, and its HA recordings did not have the motion artifacts.

There was another difference between the two cameras. When I recorded the Tapo stream using ffmpeg, I got lots of warnings like:

[aac @ 0x635c69ada840] Queue input is backward in time
[mp4 @ 0x635c69979b00] Non-monotonic DTS in output stream 0:0; previous: 840247, current: 819300; changing to 840248. This may result in incorrect timestamps in the output file.
[mp4 @ 0x635c69979b00] Non-monotonic DTS in output stream 0:0; previous: 840248, current: 823800; changing to 840249. This may result in incorrect timestamps in the output file.
[mp4 @ 0x635c69979b00] Non-monotonic DTS in output stream 0:0; previous: 840249, current: 828300; changing to 840250. This may result in incorrect timestamps in the output file.
[mp4 @ 0x635c69979b00] Non-monotonic DTS in output stream 0:0; previous: 840250, current: 837390; changing to 840251. This may result in incorrect timestamps in the output file.

The ffmpeg command was:

ffmpeg -fflags +genpts -rtsp_transport tcp -i rtsp://user:[email protected]:554/stream1 -t 10 -vcodec copy -f mp4 out.mp4

The SimiCam file, when recorded using ffmpeg the same way, issued no such warning. But both files (Tapo and SimiCam) played back without motion artifacts, although there was some jerkiness to the Tapo file. This suggests that ffmpeg may have corrected for the time order, but HA might not have.

Perhaps there is a way to either the go2RTC streams, or to parameterize ffmpeg in the HA camera integration to fix the problem.

[lancej]

I found a solution for my Tapo cameras. The short answer: I set the RTSP transport to UDP instead of TCP. With that, the motion artifacts went away.

More detail: This was not necessary with the SimiCam – only with the Tapos (I have three different kinds: C210, C310, C320, and they all need it).

I found this using ffmpeg as I showed above by changing the -rtsp_transport from tcp to udp. This made the non-monotonic warnings go away.

Also, as a test to ensure that wifi really was not the problem (I has pretty proven it wasn’t earlier), I connected via Ethernet (C310) and got the same behavior.

[lancej]

@CerebralBypass, you might want to look at what worked for me since it seems to be specific to Tapo cameras – maybe it will work for you. It would be good for me to know.