How to capture clear frames of fast moving objects?

Dave Lonsdale said:
Unfortunately, maybe a fully definitive test would need two cameras side by side.
Click to expand...
I can do two cameras side-by-side (well, one-over-the-other) ... my test rig currently has a 5231R-Z and a 5442TM-AS-LED mounted to it. I'm guessing with them not being the same model camera there'd be too many other variables in effect (even if I set the resolution/video settings the same) to make doing a comparison between the two models equal?

About the 5231's processor... the 2nd stream that can do 1080P can only do 7 FPS max when the first stream is set to 60 FPS so it seems like Dahua may have set that based on processor capability?
 
For this use case high frame rate is NOT required and plain silly. Could possibly even use JPEG snapshots.
Let's face it whatever service you upload the video to, is not going to analyse 60fps.
High frame rates, really only help if you want smooth playback, or maximise face angles during a quick head turn, but 60fps is laughable especially for computer video analysis.

You need a fast shutter speeds and open the aperture as much as possible (set manually under exposure if you control the light source), or set exposure to Low Motion Blur, if your camera has that.
For your use case, you really should invest in a decent light source enabling you to shoot with the fastest shutter speed.
 
Last edited:
  • Like
Reactions: Valiant
Mmm... now I see how the setting 7fps arose. Taking on board spammenotinoz' comments, I in any case don’t now know what to suggest that would justify aristobrats’s efforts towards getting the optimum result. What we can say is that ipOsX used his knowledge at the outset of this post to give good advice to satisfy a specific task but the topic has now migrated to CCTV security.

ipOsX, if I use what I think are typical CCTV outline parameters - each 2MP camera recording continuously and stored for one week using say 200GB, I wonder what are the optimum settings that you would recommend? Maybe we could then ask aristobrat to do one more test using those settings in the same camera mounted in the same rig with a similar scene for your critical analysis?
 
Dave, having no personal experience yet of Hikvision recording, I'm not the best person to answer that - other than observing that 200GB seems small for CCTV continuous recording of multiple cameras. You can find any number of CCTV data storage charts online, such as this one, and you can dial in the number of cameras, frame rates, resolution, etc.

As for the noise at 7fps, I'm hoping that @aristobrat will follow up with his latest test videos which would give us more to go on. I don't know how much bandwidth is available but it could be informative to try giving both streams the same fixed bitrate.

Meanwhile, it would be good to hear again from the OP, @bimbombum, to find out if he has made any progress and maybe post some images to illustrate his problem. Arguably, 20fps should be sufficient to give him a clear view of his boxes but much depends on the specification of his monitor and the speed of the boxes - specifically how long the text remains in view.

Dave Lonsdale said:
Mmm... now I see how the setting 7fps arose. Taking on board spammenotinoz' comments, I in any case don’t now know what to suggest that would justify aristobrats’s efforts towards getting the optimum result. What we can say is that ipOsX used his knowledge at the outset of this post to give good advice to satisfy a specific task but the topic has now migrated to CCTV security.

ipOsX, if I use what I think are typical CCTV outline parameters - each 2MP camera recording continuously and stored for one week using say 200GB, I wonder what are the optimum settings that you would recommend? Maybe we could then ask aristobrat to do one more test using those settings in the same camera mounted in the same rig with a similar scene for your critical analysis?
Click to expand...
 
Thanks for the response ipOsX. I guess I wasn't very clear, I currently use 200GB for each of 10 cameras, 2TB in total. Attached is a setting example for one of my cameras. I generally record direct to disc with Blue Iris unless I'm trying to pick out spurious alerts with overlay rectangles and try to use the maximum bit rate setting possible. It's a bigger number for my cameras without h.265 compression, nevertheless giving me 7 - 10 days storage.

Recording continuously, you may notice I send the minimum number of iframes possible. I'm sure you'll say this is rubbish but for all the tests I have ever done, when restricting the bit rate setting to the same value, this approach seems to deliver the best result regardless of how much of the scene is motion. My understanding is superficial, but if the entire scene changes from one frame to the next (eg panning a PTZ), won't a pframe encode the same image as an iframe? If so, why waste storage space by constantly sending unchanged image data? I will read replies with great interest.
 

Attachments

  • typical setting.png
    typical setting.png
    66.6 KB · Views: 29
Dave, I can promise you this much: reducing your I-frames increases the artefacts in your image, particularly the moving parts. That's simply because an I-frame is effectively an original frame from the camera whereas all frames in between the I-frames are interpolated based on the content of the preceding frame/s (or in the case of B-frames on the content of preceding and following frames). A P-frame looks at preceding frames to calculate the speed/position of a red pixel for example and then inserts a red pixel where it computes it should be in the new frame. It's clever stuff but it's not 100% correct because, in the real world, each pixel doesn't necessarily follow a 'true' path, and even if it did, it might change colour as the light changes.

So more I-frames = more clean/original/accurate frames and fewer grubby artefacts. But they come at a price: an I-frame contains significantly more data than a P-frame and they require more bandwidth. If you are pushed for bandwidth, then more I-frames might not be an option.

Perception also matters. If you are viewing at small size or on a cheap monitor, you might not see the artefacts, so you would be no better off by getting rid of them. But if image quality matters, which it does it most CCTV scenarios (and my drone videography hobby), then you should add I-frames.

There's a good read here on the subject - and a helpful video: Test: H.264 I vs P Frame Impact


Dave Lonsdale said:
Thanks for the response ipOsX. I guess I wasn't very clear, I currently use 200GB for each of 10 cameras, 2TB in total. Attached is a setting example for one of my cameras. I generally record direct to disc with Blue Iris unless I'm trying to pick out spurious alerts with overlay rectangles and try to use the maximum bit rate setting possible. It's a bigger number for my cameras without h.265 compression, nevertheless giving me 7 - 10 days storage.

Recording continuously, you may notice I send the minimum number of iframes possible. I'm sure you'll say this is rubbish but for all the tests I have ever done, when restricting the bit rate setting to the same value, this approach seems to deliver the best result regardless of how much of the scene is motion. My understanding is superficial, but if the entire scene changes from one frame to the next (eg panning a PTZ), won't a pframe encode the same image as an iframe? If so, why waste storage space by constantly sending unchanged image data? I will read replies with great interest.
Click to expand...
 
I'd say look at the LPR, License Plate Reading, thread. The same principals apply here. You're trying to capture a readable image of a quickly moving object very similar to capturing the license plate of a moving vehicle. The biggest "take away" is that shutter speed rules out over frames per second. If a clear image of a license plate can be obtained from a vehicle moving at 30, 40 or even 50 mph at 20FPS with a shutter speed of 1/250, say ~4ms, or a little faster, there's no reason to chase 60 or even 30FPS and hog up disk space, and CPU cycles, unnecessarily. The key factors are shutter speed and enough light, "smoothness" is not the goal here.
 
Last edited:
  • Like
Reactions: spammenotinoz
You must log in or register to reply here.
Top Bottom