Post here to ask any questions about hardware suitability, configuration in ZoneMinder, or experiences. If you just want to know if something works with ZoneMinder or not, please check the Hardware Compatibility sections in the forum, and the Wiki first. Also search this topic as well.
The artifacts occur anytime on record or live view using 640X480 mode and seen only with a moving object. I have only two monitors active and limit the image to 10 fps.
This shows that frames are captured into memory but are incomplete. Part of the previous frame show in the current one. Sometimes in live view parts of the previous images alternate repeatedly for a second then fade when the object is still. One or more capture buffers are also incomplete are not cleared for a new frame.
Could this be an issue with interrupts or threading?
I believe this is the same problem I had on a faster p4 system but the epia is slower and the artifacts show up all the time. The card works perfectly in windows 2000.
not sure that the error is related but i have seen this on via chepsets when the proc pushed i had to drop the framerate. I dont know if its a linux/ via thing or a via thing but i havnt found a way round it yet. I used one of the little via onboard cpu's on a micro atx and it did this
Well things are really close so it seems that the VIA chipset is compatible especially with the results of v4lctl. However I'm now thinking the issue is within the bttv driver. In particular it may involve interrupts and loss of data with simultanous interrupts. My tests show prove that the more monitors I activate - the worse the problem gets.
My theory is that since the BT 878 chip only stores a single line of data inernally and not a whole field (or frame for that matter), then receiving a complete frame depends on receiving all the interrupts correctly as they occur with each hsync. But when there are several chips sending interrupts there is a chance that a line of data for any frame may be missed.
In the driver's internal buffer, if a line is missed then the data from a previous frame might not be over written. This explain why artifacts from former frames actually remain in the current one.
fair play then but if you take that card and put it inot another linux machine does the problem go away? Thats why i thought it was a via/linux problem. I hope you resolve it, especailly if its a bttv driver problem!
Yes on my p4 Intel chipset system the problem largely dissappears, but not 100 percent. (see the link at the beginning of this thread.)
On the EPIA it happens all the time - probably due to differences in the chipsets as well as a much less powerful machine. Less power means more time in the interrupt handlers and more likeliness that other interrupts will cause the data loss.
So I think it is really a driver issue and may be out of the scope of this forum. ZM simply poles each monitor and requests a frame of data. It assumes the frame is complete from the driver but occasionly it is not. Interestingly when reviewing the file bttv_driver.c I found absolutely no provision for keeping the frame data intact and complete. I think a change is needed in the driver to collect an entire frame from any given device even at the expense of slower frame rate.
-shared mem address,
-Frame server,
-net.core.wmem_max,
-frame rate in zm
-bios settings,
-pnp settings,
-gbuffer
-kernel.shmmax
-monitor resolution - (improves things but doesnt entirely solve. I prefer 640x480 anyway)
-number of active monitors - (even on one there is the occasional artifact).
My goal is for 4 monitors at 5 fps in 640x480 mode, with flawless pictures.
I am currently recompiling gentoo with a faster setting -c2 from -cs, but this will likely take a few days! - I'll post my results later this week!
The CPUs with relatively small on-chip caches may do better with the size optimisations than the speed ones. I'd be tempted to experiment with just re-compiling the kernel to begin with, to see how small I could get the kernel, and whether that made it run faster...
