Movement artifacts

[kangaroo]

Bit of a wired problem here. I have tryed the card on multipal computers and multipal versions 1.23 ubuntu 9 repostorys, deb installer for 1.23.1 and ZMLarch_1.24.2-1.
It works fine if i have low fps 5 per camera or so, but at 20 to 30 fps whith all 4 on it start artifacting.
Whith 3 camras on it dose so less whith 2 on dosnt do it.
At lower resolutions also seams to do less of it.
The card is PV-149 - 4 port video capture card (120FPS) can be found here http://store.bluecherry.net/Provideo_PV ... pv-149.htm
I have tryed turning V4L_MULTI_BUFFER off and CAPTURES_PER_FRAME to 3

The computer is a core 2 dual 1.8 with 1 gig of ram. I have been trying to use 720*480 and 640*480
Tryed tail /var/log/syslog but it didn't turn up anything in-trusting

Any help would be appreciated

[kingofkya]

see help near bottom

http://www.zoneminder.com/forums/viewtopic.php?t=14111

[kangaroo]

Whell i did try that. I just installed windows whith blue iris and it is doing it as whell so im thinking its a hardware problem now.

[timcraig]

I have the same artifacts on my PV-155. They're not too bad though and only occurs once in awhile. I think it's an issue with heat. The bt878 chips run really when running at the max resolution, and/or running high frame rate. If you touch them while zoneminder is running, it might be hot to almost give you a light burn.

Putting heatsinks on the BT878 chips and keeping you're zoneminder box cool should help reduce the artifacts. It's seems to help with me.

[jack]

I have the same problems with no solution yet and opened a thread in December 2008:
mixed up lines from different channels with 8 ch bt878 card

Heatsinks didn't help for me at all (I tried). My grabbing hardware was running stable with no picture problems with ZM 1.22.x, an older kernel (32bit) and older motherboard for months (see thread above).

[kangaroo]

Whell I have heatsyncs on the card. It dose it right away after u set the rez of all the cameras to 640 x 480 + and it works fine at 320 x240. It dose it in Blueiris as whell as zone minder so i am thinking iv got a bad card. i have tryed it in 3 dif computers now a old p4 3ghz a pentium d 3.4 and a ibm core2 1.8 all to the same problem. If i can get a replacment of the same card i will know for shere.

[jack]

Did you changed the slot when reinserting the card with heatsinks?

My picture problems look exactly the same as the above screenshots.
In my case I observed that the bad lines always come from other channels pictures. Since I got independent bt878 chips for each channel, the mix-up could not happen inside a single bt878 and must happen later inside v4l/ZM buffers.
Perhaps the heat does affect interrupt timing a little in your case. I still suspect lost interrupts as the cause....or some kind of 64bit/4GB+/P35 bug.
As far as I could tell system i/o load (harddisk/pci) makes the problem worse.

Perhaps we should compare our hardware to find the cause:
I currently have a DFI LP UT P35-T2R with P35 chipset, first E2160 DualCore, now Q9650 QuadCore and 8GB RAM
(software setups mentioned in the thread posted above)

I had no problems with a AMD Athlon XP 2400 with nvidia chipset, 512MB ram and the same bt878 card.

Does anyone with a 32bit CPU and/or kernel do have this problem?

[timcraig]

Out of curiosity, have you guys tried using V4L2 on Zoneminder 2.4.2 and have the same problems?

I recently switched from V4l1 to V4l2 (Device Format: NTSC, Capture Palette: RGB555, Capture Size 640x480) and so far I haven't noticed any lines at all. I probably need to make a lot of movement in front of the cameras to be 100% sure.

[kangaroo]

Whell it seams like by defalt its on V4l2, thogh setting rgb555 from bgr24 seamed to help alot, seams to still do it but way way less. I also just tryed it in an older amd 3000+ to the same problems. I just dont get why it would be doing it in windows as whell. Ill have to keep trying difernt things but atleast it seams like it may be usable under rgb555

[jack]

Out of curiosity, have you guys tried using V4L2 on Zoneminder 2.4.2 and have the same problems?

Yes and I had the same problems: Debian Lenny with ZM 1.24.4 and SVN ffmpeg running in a Xen DomU using V4L2 and BGR24, as far as I remember.

But I know that I had definitely interrupt problems with that configuration because different hardware was sharing IRQs among different DomUs.
PCI data to my video decoder card was lost, when I had a lot of network traffic (and other problems).

Whell it seams like by defalt its on V4l2, thogh setting rgb555 from bgr24 seamed to help alot, seams to still do it but way way less.

Perhaps because rgb555 needs 30% less buffer space or data transfers makes the error less likely.

I also just tryed it in an older amd 3000+ to the same problems. I just dont get why it would be doing it in windows as whell.

That is really interesting. Does your AMD board have a VIA chipset like the KT400? I had to change my previous KT400 board to a nvidia based board, because the KT400 had a lot of lost interrupt caused the network interface to "hang" (Windows with VIA device drivers had no visible problems...).
What chipsets do are using on your AMD board and your other board?

Unfortunately I have not the possibility to test my bt878 cards on my old hardware again, to be sure, that I haven't killed them by heat But I doubt that, I always had a big ventilator in front of the slots.


Did someone also observe (like me) that a lot of PCI bus traffic/interrupts like copying data from one harddisk to another or to network does make the problem worse or cause it?

[kingofkya]

That is really interesting. Does your AMD board have a VIA chipset like the KT400? I had to change my previous KT400 board to a nvidia based board, because the KT400 had a lot of lost interrupt caused the network interface to "hang" (Windows with VIA device drivers had no visible problems...).
What chipsets do are using on your AMD board and your other board?

I have had the same problems on the via pci bus chips (the first time and only time linux crashed completely) and dont even get me started the via unicrome

if you want to know do a lspci you will see something about via in the first few lines

Did someone also observe (like me) that a lot of PCI bus traffic/interrupts like copying data from one harddisk to another or to network does make the problem worse or cause it?

yeah i had a mythtv running once on a via based bord and hd could only run at about 250kbs whenever pci video cap was activated and about 1mb normally

[kangaroo]

Whell the amd is a
K8VGA-M
http://www.biostar-usa.com/mbdetails.asp?model=k8vga-m
chipset
VIA K8M800 / VT8237

p4s a
p4p800-vm
http://www.superwarehouse.com/Asus_P4P8 ... /ps/284610
chipset Intel 865G

pentium d
d945gtp
http://www.intel.com/support/motherboar ... 029368.htm
chipset Intel 945G

the core 2 is an lenovo
8808-94u
http://www-307.ibm.com/pc/support/site. ... MIGR-65919
chipset q965

In windows on the ibm under resorcses everything has its own irq

[jack]

Several Intel chipsets and VIA chipsets seem to be affected and also 32bit and 64bit kernels. So I think these are most likely not the cause.


The following I observed within the last days:

- If I got nothing else running except ZM and open a monitor view with 9 cameras and there is no huge movements in the pictures, the pictures are error free.

- If there movements (like cars driving through the pictures) errors seem to occur (not always, so I not sure it is the cause).

- If I enable Modect for one camera or more, a lot of errors occur when Modect triggers.

- I'm also pretty sure now, that Modect cause the computer to freeze (dark screen, no log entires) after several hours!
I had this problem with all my linux/Xen installations (see other thread), but I thought this was because of the IRQ sharing between DomUs.

Has anybody else problems with system instability?

I'm not sure, if these problems are linked together, but it is obvious, that if the one problem gets worse, the other gets worse too.
It is also possible that SATA harddisk access causes the problems, since Modec writes, of course and other activity also makes the problems worde. I'm not yet sure about that.


Perhaps we should also compare kernel versions too:
- I got a vanilla 2.6.18.1 32-bit, ZM 1.22.x (not sure) running image error free
- ubuntu 2.6.24-19-xen-amd64 (ZM 1.24.2), debian lenny 2.6.26-2-xen-amd64 (ZM 1.23.3) had both problems with image errors

Any other ideas?

[jack]

PROBLEM PARTLY SOLVED:

As I already wrote in my my other thread, I have a
- PV-981 16 port PCIe card from bluecherry.net, 2 channels used
- 8 channel Kodacom clone card (with 8 bt878 and PLX PCI6150 PCI bridge, appears to be from China), picture here, 8 channels used

I had image errors in ALL channels from both cards before.

Now I removed the 8 channel Kodacom clone card and connected 2 additional cams (4 now) to the PV-981: All image errors are gone!!

My system freeze problem seems to be gone too!

BUT: After approx. the same time I had the system freeze before the PV-981 suddenly stops working with these messages:

Code: Select all

Aug  9 14:16:24  zma_m5[6031]: INF [cam1: 170366 - Left alarm state (165) - 39(17) images]
Aug  9 14:17:02  kernel: [63973.591309] bttv3: SCERR @ afec5000,bits: HSYNC OFLOW FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.620887] bttv0: SCERR @ afec8000,bits: HSYNC OFLOW FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.635220] bttv1: SCERR @ afec7000,bits: HSYNC FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.639796] bttv2: SCERR @ afec6000,bits: HSYNC FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.755434] bttv3: SCERR @ afec5000,bits: HSYNC OFLOW FBUS PABORT SCERR*
Aug  9 14:17:02  kernel: [63973.785639] bttv0: SCERR @ afec8000,bits: HSYNC OFLOW FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.798737] bttv1: SCERR @ afec7000,bits: HSYNC FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.806134] bttv2: SCERR @ afec6000,bits: HSYNC FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.921564] bttv3: SCERR @ afec5000,bits: HSYNC OFLOW FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.951663] bttv0: SCERR @ afec8000,bits: HSYNC OFLOW FBUS SCERR*
Aug  9 14:17:02  kernel: [63973.965412] bttv1: SCERR @ afec7000,bits: HSYNC FBUS PABORT SCERR*
Aug  9 14:17:02  kernel: [63973.973320] bttv2: SCERR @ afec6000,bits: HSYNC FBUS SCERR*
Aug  9 14:17:02  kernel: [63974.003990] bttv3: timeout: drop=3 irq=3367465/3367484, risc=afec5000, bits: HSYNC OFLOW FBUS

I reloaded the bttv module, didn't help. I think I have to reboot, haven't done that yet.

Since I'm pretty sure that the Kodacom clone hardware is okay and the other card is still having a problem, I think there is a serious bug in the v4l2 (bttv or elsewhere) on a low level that affects the PCI(e) data transfer and the system freezes/card errors(see log above).

I used the dvb-multiproto drivers for my test, but I had the problems before, when using the 2.6.26 kernel v4l2 when running in a Xen DomU.

I asked myself, if there is anybody with a recent kernel, who has no problems?! vanilla 2.6.18.1 and my old AMD hardware was fine....

Any ideas?

[gertjan]

I am also looking into this problem.

When I increase framerate witht high-resolution images i see the same problems ( 4 x bt878a ).

I am suspecting the PCI bus ( standard 133 MB/s ).
and f.e. 4 channels at 25 fps 640 x 480 RGB24 already give 92MB/s data which should travel the PCI bus. Switching to f.e. RGB565 reduces this to 61.44 MB/s and the problems occur less often.

Of course the pci bus is also used for all other hardware hanging on the bus. f.e. video, disks, usb etc.

Correct me if i am wrong, but it looks like we are hitting some kind of PCI bottleneck. Unfortunatly i have not yet found a way to monitor the PCI bus, so I can be sure this is the problem.