Interlacing issues.

[maclellan]

Sorry in advance if this seems redundant, but seems like a recurring problem.

It appears that ZM is giving only half the picture since I am experiencing the horizontal lines described elsewhere.

The video "frame" is actually 2 "fields" - one odd and one even. When I read the previous messages these terms are being confused. For example to capture video at 30 frames per second you need to get 60 fields per second. To capture 4 channels then the best one can acquire is 7.5 frames per second. But due to the asynchronous nature of multiple cameras the worse case could be 3.25 frames per second. So I dont care so much about frame rate but I want the complete frame.

So if I want to grab a true frame I have to first wait for an odd field then capture it. Next I have to get the next even field then capture that. The 640 x 480 image then can be extrapolated. Only then can I move to the next camera.

My question is how does ZM capture true frames vs fields? Is there any configuration I can change to ensure I get the whole frame?

Many Thanks for comments!!

[lazyleopard]

The frame-capture hardware will usually sort this out, but if you're switching inputs rapidly (as happens when using a single bt8x8 chip for multiple channels) sometimes its first attempt at a full frame gets the odd and even ones the wrong way round. The easy way to avoid this is to tell zoneminder to skip a frame or two after each switch to give the hardware time to sort itself out. There's an option ZM_CAPTURES_PER_FRAME which can come into play when interlacing might cause problems. The default is 3 but I've found 2 works Ok on my system.

[maclellan]

Thanks lazy for the valuable tip. I did apply your suggestion and it did work. I do indeed use the bt878 based 4 inout board.

Only thing is I dont like is the 1.25 fps rate. I think the patch works but misses a problem that may be in the driver or zoneminder.

Is it not possible to wait for the correct odd or even firld then start the capture process before going on the the next channel. So if the bt878 needs an odd field to start the process then the driver could just wait until the right time. If this is the case the worst case should be 50 percent reduction from 30 frames / sec divided by 4 or 3.75 fps worse case.

Perhaps there is ans issue of chroma synchronization that requires an additional frame or two.

If you know the actual issue maybe I cold look into some code for more clues.

Thanks again!

Scott

[lazyleopard]

The problem is that there's no way for the cameras to co-operate and synchronise their own frames (unless you use broadcast-quality cameras with an external sync source) so while one camera's on its odd-frame another's on its even-frame, a third is between frames, and so on. Each time the bt8x8 chip has another input switched into it, it has to figure out where it is, and it's going to take at least one full interlaced frame to do that, and may take up to two.

I don't know enough about the low-level bt8x8 programming to say how easy it would be to spot the odd (or even) frames straight away.

[maclellan]

Yes I totally agree with you. I fully understand the nature of asynchronous cameras but still I come up with 3.75 unless I'm still not getting it. In my experience two full frames (4 fields ) is more than adequate to capture asynchronous cameras.

Let's say ZM needs 2 full frames - 1 frame to synchronize and another fram to capture. This result is:

30 frames / (4 cameras * 2 frames) = 3.75 fps.

Even if it took 3 frames this would be 2.5 fps.


In practice I'm getting 1.25. Maybe something else is not quite working. My Capture Frames setting is 2.


Thanks again,

Scott

[lazyleopard]

I think the chip almost always looses one field each time it switches. Then (if you have ZM_CAPTURES_PER_FRAME set to 2) it'll throw away maybe 3 fields, and then capture a pair, so that's 5 or 6 fields per frame captured. If ZM_CAPTURES_PER_FRAME is set to 3 then there's an extra pair discarded, so it'd be 7 or 8 fields per frame captured.

Say 5 fields per frame. 60 fields per second. 12 frames per second. 3 per camera per second.

Say 6 fields per frame, gives 10 frames per second, 2.5 frames per camera per second.

At 8 fields per frame, gives 7.5 frames per second, or 1.75 frames per camera per second.

Hmmm...

[maclellan]

Hey Lazy,

Your making sense! There probably is a chroma syncing issue as well and that is done in the chip to ensure the color lock is stable before capturing.

So if I'm looking for a board that has 4 X 878 chips I should be able to get 30 fps - since there are no synchronization issues as each chip is dedicated. But that is almost overkill - as I need just 7.5 to meet my needs. Do you know of an inexpensive board to improve the 1.75 rate?

Thanks again for your help.

[lazyleopard]

There are plenty of other advantages to having a 4-chip card. You have individual control over the colour, brightness and contrast of each camera, for a start...

If a 4-chip card is out of the question then you could experiment to see what frame rate you get with just two cameras on your current card. If that turned out to be fast enough then you could just try using two single-chip cards. My best guess is you'd only get about 3fps though.

[thelight]

Are there any other causes of interlacing? I have a 4 chip card with 3 cameras on it. If I run them at 25fps then images are crisp and sharp, if I make zoneminder capture at 5 or 10fps instead to stop my system being crippled, any moving objects get interlaced.

[maclellan]

Yes! I have just made that observation. The problem is de-interlacing on any motion in the image. These do not appear to be blured but are the same deinterlacing errors seen at the start of this thread. Thanks to Lazy I have observed a solution for correcting the deinterlacing errors by setting the frames per capture variable. The overall still picture has improved. Diagonal objects dont show the de-interlacing errors.

However on any motion (even slow) the error reappears. It only disappears in 320X240 mode. If the camera shutter speed was too slow I would expect to see typical blurring at any resolution.

It still points to a problem with the BTTV capture mechanism. I have have not seen it on the same Grandtec card in windows so it has to be the case.

There may be an error in the bttv driver itself or perhaps in the capture code. I think if this can be solved ZM images would be perfect!

Any clues as to where in the code to look would be very helpful! (No offense I hope - ZM is a fine piece of coding!)

Scott

[maclellan]

Here's my theory to date for the de-interlacing problem on bttv 878 chips:
(Its just conjecture so feel free to shoot it down)

On normal operation with ZM_CAPTURES_PER_FRAME set to 1 and switching more than one camera there are occasional de-interlacing errors that appear in still frames about 40 percent of the time. All cameras in addition are subject to de-interlacing errors visible on the vertical edges of a moving target until the target stops where it then gets filled in 60 percent of the time.

When the ZM_CAPTURES_PER_FRAME is set to 2 the still image errors always dissappear but the motion images allways re-appear. The capture knows nothing of moving images - it just captures data.

My theory is at any time only one field of data is being captured properly at any given time! This may not allways be the case but often it is.

Here are some scenarios of how the timing could explain these results:

Note that the number of captured fields is with respect to one input only when it is being switched. The actual interval will be 2, 3 or 4 times longer.

Normal - no errors in still image - capture 5 / 7 fields:

O E | O E | O E | O E |
|__________|
C_________C

Every five or seven fields or so we capture alternating O E fields giving the appearance of a complete image assuming it is capturing .
However during motion the De-interlacing effect shows up due to the long delay:

t = (7 X 32mSec) X number of cameras = 224mSec X 4 = 896mSec (almost one second!)

Because the vertical edge is moving faster than the second or longer the de-interlacing effect show up as the missing O or E field. When the subjects stops moving the missing field is filled a second later.

(Note that the O or E fields are mixed to give the effect of a complete frame but are not related to the original frameset. This likely will affect motion detection on long distances - something I have also seen.)


Normal - errors in still image 6 / 8 fields:

O E | O E | O E | O E |
|_____________|
C____________C

Now we will view the de-interlacing seen 40 percent of the time. How and which camera it shows up depends on the timings of the different cameras.
Occasionally I have observed a fluttering effect every few seconds in the errors. In this case the timing of a previous camera is changing slightly or is concurrent with the vertical blanking period causing the captures to be Odd field one moment then Even fields the next.


The ZM_CAPTURES_PER_FRAME fix:

O E | O E | O E | O E | O E |
|_______________|
C______________C

O E | O E | O E | O E | O E | O E |
|___________________|
C__________________C

This variable ensures all inputs are catching on 7 or possible 9 field intervals. The still images are definately fixed the problem or perhaps only MASK the problem.

But because the time between the captured O / E field is longer, the moving image errors are even more pronounced. This is something I also observed.


Conclusion / summary:
--------------------------
During data transfer we are getting only partial frames. Inserting delays appear to fix the problem but the captured frame contains unrelated fields separated in time. Moving objects illustrate the problem of this time delay in terms of de-interlacing errors momentarily. Motion detection will be adversly affected especially for objects further away from the camera.

[lazyleopard]

The motion interlace errors I see are always 1/50th second apart (I'm using 25fps PAL cameras).

A while back I played with small bits of a couple of images where there's a fast-moving target, using a sub-optimal way to extract the half-frames:

interlaced one half-frame the other half-frame

interlaced one half-frame the other half-frame

The fox was running, and the magpie flying, so there's no way those particular interlace mis-matches are more than a difference between two adjacent half-frames.

[maclellan]

Thanks for the images! Your point is well taken. I however think it is showing a de-interlacing error as well, similar to the ones myself and others see. My above theory might not point to the exact problem but I still believe the errors should not be there - even for fast moving objects. I'm also starting to think it a driver issue since ZM really doesnt concern itself with fields.

Consider the video source - a CCD / CMOS sensor and a controller chip. I think most sensors knows nothing about interlacing. They capture the image data complete and holds the information long enough for the controller chip to encode the data into interlaced video - either PAL or NTSC.

The capture card receives the video and starts to decode the interlaced analog signal using the bttv chip. The driver has first hand control of this and must ensure the chip is setup properly to capture the entire frame, extract related fields and and transport the image data to a memory location for ZM to use.

I've looked at ZM code right down to zm_local_camera.c and it all looks great. There are just 2 calls to the driver - one to switch the camera and one to capture the frame data.

With all monitors switch to "none" except one then I believe the switching call is not made - but even then I see the de-interlace errors - although just not as pronounced. When turn on all 4 monitors the error is more pronounced and even a slow moving object like myself will show the errors.

I'll keep digging to see if what I think is actually the case, but I'm open to all suggestions!

Thanks again!

[lazyleopard]

Yes, it could be a driver problem. I don't know enough about how CCTV cameras produce their interlaced output though. Do they take a full frame and then transmit it as two half-frames, or do they alternately take even and odd half-frames, and transmit each as it's taken? In the first case I'd expect to see cleanly reconstructed full-frames. In the second I'd expect to see errors a half-frame apart.

I wonder whether I can do some measurement of images to see how far apart the interlace errors I see actually are...

[jameswilson]

most ccd cameras are 'interline transfer' which means they scan a line eg1 send one scan next line eg 3 once oll odd lines complate then it does the same with the evens. I am currently tring to get hold of a 'frame tranfer' camera to see if the problem goes. Frame transfers were developed to stop the smearing of light all down the chip like most cams do and grab a complete frame then send it interlaced. From what i know i asume a frame transfer will fix it but i have been wrong many times before. Unforunalty most frame trans cameras are expensive rare and use a 1/2 chip, great for low light not so great when you have to buy a 1/2 inch lens

I will let you all know when ive got one and tested it

Regards James