image 'tearing' on amcrest 3MP dome

Forum for questions and support relating to the 1.34.x releases only.
Post Reply
0ddentity
Posts: 6
Joined: Thu Sep 03, 2020 2:49 am

image 'tearing' on amcrest 3MP dome

Post by 0ddentity »

Hi All,
First post.. been casually running zm for a couple years, all 1.34.xx

Recently bought a 'Amcrest ProHD Outdoor 3MP'/IP3M-956E camera and set it up with 1.34.18 or so. Had it up and running fine for a couple weeks, with 2 monitors - a 'modect' for the main stream (1080/HD I think I had it at) and a 'monitor' at 640x480 for the substream.

Then my root SSD fried (been hot in the garage in CA!) and it was rebuild time. Experiment system, no big deal.

For full disclosure I arbitrarily changed my OS from ubuntu (something 18 I think) to mint (absolute latest ver as of 8/31) for the hell of it. More experimentation.
For installing ZM I do the docker/container method and on doing the docker build i noticed it was now running .20. Great.

I set everything up, but alas I had not recorded my previous monitor configs, but it's not that complicated to find the basics, but hitting just the right ones, sometimes tricky.

But.. now, with the main stream for this camera, it's constantly blurring/tearing - however you say it. Not a problem for the substream, nor the live view through the cam web page so I _assume_ the heat didn't hurt the 'Outdoor / Vandal Dome / IP67 Weatherproof, IK10 Vandal-Proof' camera' and its either a configuration change or some diff in the new version. I haven't been able to hit on the correct camera & zm monitor config.

So a few questions.. thanks for reading if you're still here..
. can a camera substream be ok but the main one suffer from ccd/lens damage? Seems unlikely.
. Is it generally ok to set the camera to max res/frame rate etc and use zm to throttle to the desired res / rate etc?
. any ideas on the above tearing issue (also just random color blocks appearing/moving like an old tv computer game) - it's 'detecting' moving all the time with this visual corruption.

Thanks and sorry for asking things probably already answered. Extra thanks to the developer(s)!!
mikb
Posts: 585
Joined: Mon Mar 25, 2013 12:34 pm

Re: image 'tearing' on amcrest 3MP dome

Post by mikb »

You have the right word for it! Try searching the forum with the phrases "FFMPEG tearing" "FFMPEG smearing" -- this does come up from time to time, and should be fixable.
0ddentity
Posts: 6
Joined: Thu Sep 03, 2020 2:49 am

Re: image 'tearing' on amcrest 3MP dome

Post by 0ddentity »

Thanks for the reply.

Well I found my error - I had the monitors set to UDP, needed to be TCP.

This is a bit of a surprise.. I would have thought realtime devices would be all UDP but there you go.
Also interesting that the cam is streaming on both protocols.. I don't see this as a configurable option on the camera.

One other question I had / should already have known, might be useful to someone - the MAXFPS (max frames per sec monitor option) helptext says "For streaming IP cameras, do not use this field to reduce the frame rate" - but instead use the camer to limit the fps. So configure your cam settings on the cam itself and leave this/these unspecified.

Thanks all..
mikb
Posts: 585
Joined: Mon Mar 25, 2013 12:34 pm

Re: image 'tearing' on amcrest 3MP dome

Post by mikb »

0ddentity wrote: Thu Sep 03, 2020 8:41 pm Well I found my error - I had the monitors set to UDP, needed to be TCP.
UDP is not a reliable transmission method, in that a packet can turn up none, one, or more times. In no particular order related to other packets.

If you accept that behaviour as part of your system design, then it's fine. But there are penalties, e.g. losing a chunk of an MPEG encoded stream, or having corruption, will eventually resolve itself at the next GOP (group of pictures). Meanwhile, chew on some bad data.

That's why TCP was invented. "All your packets in the right order, or your money back" :)
0ddentity
Posts: 6
Joined: Thu Sep 03, 2020 2:49 am

Re: image 'tearing' on amcrest 3MP dome

Post by 0ddentity »

Thanks for the insight! Yeah I know the connectionless/oriented nature of the two protos, I just made a bad assumption that consumer boards like these cams wouldn’t be beefy enough to/attempt to buffer enough to deal with outages/retransmissions. I guess I should rtfm. As always!

Is ‘GOP’ a technical term here? Do they buffer up to a certain point then batch send?

Would then the image corruption be related to packet loss in all likelihood? If so, that’s a lot (?) of loss for a hardwired link.. (I terminated the cable myself but fluke said it was good..)

Is tcp support typically indicative of a more ‘premium’ product or is the norm? My super cheap one is udp

Cheers!
mikb
Posts: 585
Joined: Mon Mar 25, 2013 12:34 pm

Re: image 'tearing' on amcrest 3MP dome

Post by mikb »

0ddentity wrote: Sat Sep 05, 2020 1:10 am Is ‘GOP’ a technical term here? Do they buffer up to a certain point then batch send?

Would then the image corruption be related to packet loss in all likelihood? If so, that’s a lot (?) of loss for a hardwired link.. (I terminated the cable myself but fluke said it was good..)

Is tcp support typically indicative of a more ‘premium’ product or is the norm? My super cheap one is udp

Cheers!
GOP = Group Of Pictures. In an MPEG (and other video streams eg MP4/H264) you can tolerate, a little, some data damage in the stream. It tends to affect most of the rest of the GOP up to the next synchronisation point, at which point the picture will suddenly "pop" nicely clear. The camera doesn't need to buffer up a whole GOP, apart from what is mandated by the encoding on-board (which doesn't need to buffer a whole GOP, usually just enough to work out all the intra-frame compression going on between nearby pictures).

MJPEG (motion jpeg) doesn't suffer from this as each frame is a full JPEG, so any damage is limited to one frame. It's still "motion" to ZM though.

Yes, packet loss or damage, but note, it may not be a wiring fault. Just simply that the camera had a lot to say, and the computer didn't quite receive it all in time, and there's no way to signal whether the computer received the packets, or needed the source to retransmit/slow down. No real flow control if it's just spraying packets at your computer and hoping you catch them all.

VOIP can behave like that. So what if some of the packets don't make it through. It's not important data, right? :)

I don't know if TCP vs UDP is a price point thing for the cameras.
Post Reply