How Do I Stop A Bullet Camera From Moving / Shifting?


We use a bullet camera to generate a timelapse video. Some days it seems as if the camera changes position during the day. See

I know wind can be a factor, but not yesterday (calm). Any tips on what can cause this?

Best regards
Jon Ivar

Without knowing how the camera is mounted, and likely seeing some pics, it's hard to give anything other than very generic advice.

It looks like you're using some software to put the images together, add overlay, and possibly even resample the images. Have you looked at the raw images from the camera to verify the movement is in the camera and not in the post-process?

Any minute thermal expansion or contraction can shift the FoV. Like Brian K mentions, it is hard to diagnose without a deeper look at the mounting surface, but any kind of freezing/thawing on the mount itself or even things like heaters or blowers warming the chassis up can be a source.

Also: is the ground itself moving? Snow loads accumulating on the pole/mount structure?

Fixing the issue is probably not difficult once the root cause is found.

It would appear after having viewed the video several times that the issue is electronic, not physical. You do have a minute shift of some articles, but one has to really look closely to see it. By the way, nice application and great view.

IMHO, this is not caused by camera motion, as Mark says.

If it WAS camera motion we would expect the effect to be greater in the foreground than the background. Instead it seems to be shifting across the frame irrespective of depth.

Best guess?

The integration of multi-exposure WDR frames is causing the shift.

That is if it has true WDR. :)

Otherwise maybe a H.264 Codec effect?

Thank you for you feedback. The camera is the Axis P1428-E (4K), WDR (not true) disabled.

For another location, same camera, same day, same application see Same shifting problem.

And last, a Basler BIP-2500 camera with alu housing, same day, same application. Rock solid - no shifting. See

Shifting seems connected to the P1428.

Assuming you are using h.264, can you use an MJPEG stream for a day?

Encoding with H.264 allows much more variation in method, which could conceivably not be perfectly decoded by the time lapse software. Axis ZipStream is a good example of this.

Even if it still does it, this will make it much easier analyze because there will be only full frames to deal with.

The timelapse video is created with ffmpeg using snapshots from the P1428. See and to see the shifts in the source stills/snapshots. Snapshots are downloaded using http://x.x.x.x/axis-cgi/jpg/image.cgi.

Thanks, that helps a lot.

In the case of those two images at least, the shift is just one pixel left to right. Looking closely at object edges, IMHO, there is anti-aliasing processing being performed. Depending where the algorithm picks up an edge this could conceivably cause an apparent shift. maybe.

Its hard to tell because even though the compression is set very low, at the pixel level the compression artifacts make it difficult to know what is the scene changing vs random noise.

Do you have a adjustment for sharpness? Another wild guess, but maybe the anti-aliasing can be indirectly controlled by setting this lower.

Is the compression set as low as it can, and/or is their any other image processing going on that you can temporarily disable?