Jumpy Video During PTZ Panning

Undisclosed Integrator #1

01/06/14 10:54pm

In a 100+ CCTV Site I'm using about 20 Axis Q6034 PTZ cameras. Client reports jumpy video during PTZ panning.Well it's harsh to say jumpy, in my opinion some frames are lost which is not very marked nor deteriorate picture quality.

My understanding about IP PTZ cameras is that they take time to put out the stream so there is an inherent delay (about a sec) even on web page without any switches/VMS.The latency increases via switches and VMS before stream is fed to CCTV Client software. Then again since the PTZ commands travel faster to camera than the realtime video is appearing on CCTV client, I believe either the camera or the VMS is dropping frames to keep a balance between video quality and PTZ responsiveness. Very slow panning shows no frame losses, I believe because video reception/processing is keeping with PTZ command speed.

Is this a correct assumption? Is there other explanations to this behaviour and importantly fixes for this (I can think of lowering frame rate, resolution, use of high performance camera with high-end CPU e.g. ARTPEC5 in future).

Thanks

John Honovich

IPVM | 01/06/14 11:01pm

Do you have a short video clip of this to share with us? When dealing with video issues, seeing the symptoms helps a lot.

One simple thing to check - have those PTZs been configured for constant bit rate? That's one thing that would cause an immediate problem when you move a PTZ because that action creates a spike in bandwidth needed that might result in dropping frames.

I don't think latency is causing frames to drop but, again, seeing the video would really help (even a 5 second clip).

Undisclosed Integrator #1

01/06/14 11:16pm

Hi John

I'll get a clip hopefully tomorrow. All cameras are doing VBR, we have plenty bandwidth available.
But I get your idea fast panning creating a bandwdth spike.

Thanks

Undisclosed Integrator #2

In reply to Undisclosed Integrator #1 | 01/07/14 03:43pm

I've had similar issues that you are describing while using Milestone and Axis Q-Series Cameras. Couple of things that helped me.

1. Verify that you are using TCP and not UDP to transmit the stream.

2. Play with the GOV Length (Lower the # the higher the bandwidth but more i-images will be sent.)

3. In extreme situations I had to revert to MJPEG with lower framerate.

4. If you are using Milestone, increasing the stream buffer can also help.

Undisclosed Integrator #1

In reply to Undisclosed Integrator #2 | 01/08/14 10:09pm

Thanks for the response.

Currently the cam is doing TCP/VBR. Tried changing GOV setting.

Didn't see any difference. Unfortunately I couldn't get a clip due to nature of facility.

Brian Elias

01/08/14 06:20pm

I had the same issues with the Q6035 when it first came out. It's been largely addressed with updated firmware, but (at least for 1080p) the main issue is the extra load on the H.264 encoder when panning (lots of motion to deal with). In addition to the suggestions above, try increasing the compression - this has the effect of reducing detail and reduces the processor loading. It also gets noticeably worse with additional streams being requested...

Undisclosed Integrator #1

In reply to Brian Elias | 01/08/14 10:15pm

Thanks Brian.

I'll try playing with compression. True, that panning/motion increases data rate and puts more load on to the Camera CPU; think I tried setting a ceiling for data rate, but did not see any perceivable diffrence.

To say that the video is jumpy/stepping is too harsh; more accurate to say less smooth (slightly stepping). I see no problem when slowly panned. May be I should try adjusting shutter speed/aperture just to see their effect video on fast panning. But then low light performance will definitely be compromised.

Reckon 60fps camera would do better in fast panning.

Horace Lasell

01/09/14 11:40am

All other things being equal, would 60 fps will place a greater load upon the encoder and result in even less satisfactory performance?

If the reason for the stutter is camera loading during h.264 encoding at 30 fps, then is your rationale that a camera designed to support 60 fps will have been provisioned with greater processing capacity to deal with the higher encoding load, and that you would then run it at 30 fps to create some overhead?

Undisclosed Integrator #1

In reply to Horace Lasell | 01/09/14 11:54am

Do not think camera loading is the issue here. But smoothness is lost in speedy panning doing only 25 fps, as in the case of a fixed camera viewing a fast moving object. So I'm assuming 60 fps would make a difference, provided camera is capable of handling 60 fps at required resolution.

John Honovich

IPVM | In reply to Undisclosed Integrator #1 | 01/09/14 01:11pm

Presuming this is a load issue, increasing the frame rate would only make it worse.

Undisclosed Integrator #1

In reply to John Honovich | 01/09/14 01:35pm

It is too obvious to see that any incremental task compromises performance when load is the issue. Who can set 60 fps on concerned Axis Q6034. I do see fps dropping (both reported by camera fps measurements as well as VMS) when camera cpu is pushed too much (opening 2 streams in highest resolution), but never when panned. Although any incremental task add to load, fps drop is visible when multiple streams are opened, and when recording on to SD card based on MD, but not by enabling on camera MD, etc.

I'd like to see a panning video comparison in 25/60 fps in future.

Kieron McDonough

01/22/14 12:23am

I disagree with using constant bit rate, I would use constant frame rate (if available).

I disagree with using TCP instead of UDP, I would use UDP. This gives less overheads on the network and doesent require a packet retranmission.

Also check PC CPU usage for the PC displaying the camera is not high. if you find the problem is not as servere when using a lower bit rate then it may be CPU related, or display using mjpeg instead of h264 which requires more CPU grunt.

Also try another Ethernet switch.

Yowie De

01/22/14 01:44am

You could also look if the PTZ is overdriving or if it is just the video. If PTZ is overdriving or jumpy then I would say its a bandwidth issue. Also check the recorded footage and see if it is the same or if it just the live stream that has the issue.

Top Comment Votes - Past 3 Months
  • 1. John Honovich - 1678
  • 2. Chris Dearing - 953
  • 3. Brian Karas - 491
  • 4. Marty Major - 314
  • 5. Brian Rhodes - 217
  • 6. Ethan Ace - 205
  • 7. Michael Miller - 202
  • 8. Sean Patton - 185
  • 9. Frank Lucero - 163
  • 10. Daniel Tyrrell - 130
  • 11. Greg Cortina - 130
  • 12. Sean Nelson - 129
  • 13. Shannon Davis - 115
  • 14. Andrew Myers - 109
  • 15. Charles Rollet - 97
  • 16. Stephen Green - 75
  • 17. Jason Crist - 71
  • 18. Jon Dillabaugh - 66
  • 19. Clint Hays - 65
  • 20. John Bazyk - 65
Manufacturers
Tools

AI Tester

BestMatch

Camera Calculator

Camera Finder

F-Stop Calculator

Chat

Integrator Finder

News Spider

Camera Comparison

Quizzes

Pages

About

Contact