I don't think there any bandwidth problem there.
I had the same framerates with the same grabber card on an other motherboard (+kernel) with no errors at all.
I'm grabbing 3 or 5 (alarm) 720x576 frames per second. Even if there is a bandwidth problem, this should result in lost frames, not in image errors I think.
Like a wrote before, I removed the 8 channel Kodacom clone card and connect all channels to the PV-981: The image errors are gone, but the framerate (~4/s) isn't that good because of the 4 instead of 8 bt878.
Unfortunately the system freezing problem IS NOT gone, like I thought before.
When the Kodacom clone card the system freezes more likely/quicker.
This could also be because the Kodacom clone card affects the heat/air circulation and something else gets hotter.
I do have some idea what causes the log entries and a least some of the system freezes.
Perhaps I will open an other thread, because it is probably not related to the image error problem.
Still no solution for the image errors....
Movement artifacts
I tried this on my machine, but to no avail. Although it might help to look at the kernel scheduling overall.sef1976 wrote:echo deadline > /sys/block/sda/queue/scheduler
#Completely Fair
#Queuing -elevator=cfq (default);
#Deadline -elevator=deadline;
#NOOP -elevator=noop;
#Anticipatory -elevator=as
game's of elevators
on my system DEADLINE best
At this moment I am testing with only all camera's on monitor, so it does not take any disk activity.
Are you still using CAPTURES_PER_FRAME = 3 ? as this should result in a much higher internal framerate ? ( although i agree with you that lost frames would be better than image errorsjack wrote:I don't think there any bandwidth problem there.
I had the same framerates with the same grabber card on an other motherboard (+kernel) with no errors at all.
I'm grabbing 3 or 5 (alarm) 720x576 frames per second. Even if there is a bandwidth problem, this should result in lost frames, not in image errors I think.
Like a wrote before, I removed the 8 channel Kodacom clone card and connect all channels to the PV-981: The image errors are gone, but the framerate (~4/s) isn't that good because of the 4 instead of 8 bt878.
) As said above at this moment I am testing with monitor, so i am only recording. I have added another card so i can test more. At this moment I am running with 8 bt878 chips.
With 1 card:
I see the distortion with 4 channels at RGB24 640x480 25 fps. (around 92.16 MB/s )
I have nearly no distortion with 4 channels at RGB565 640x480 25 fps. (around 61.44 MB/s )
With 2 cards:
I see the distortion with 4 channels at RGB24 640x480 25 fps. (around 92.16 MB/s )
I have nearly no distortion with 4 channels at RGB565 640x480 25 fps. (around 61.44 MB/s )
I have nearly no distortion with 5 channels at RGB565 640x480 25 fps. (around 76.8 MB/s )
I see a lot distortion with 6 channels at RGB565 640x480 25 fps. (around 92.16 * MB/s )
I see no strange increase in interrupts or context switches.
When activating irq_debug in the bttv driver i notice the following error:
"FBUS", // pixel data fifo dropped data (high pci bus latencies)
Is there someway this can be checked in zm_local_camera.cpp so the image can be f.e. discarded , or maybe the framerate automagically decreased with an warning to syslog ?
regards,
Gert-Jan
"FBUS", // pixel data fifo dropped data (high pci bus latencies)
Is there someway this can be checked in zm_local_camera.cpp so the image can be f.e. discarded , or maybe the framerate automagically decreased with an warning to syslog ?
regards,
Gert-Jan
I Have just tryed a new card as whell to the same affect so dosnt seam like its the capture card for me as mentiond b4 I got it working well on 640 x 480 whith rgb555 and 30 fps. However in windows and blueiris it artifacts at anything higher then 10fps. I tryed VLC and it seamed to work happly whith all 4 Inputs on. So im at a loss on what causes it but dose seam like sometimes it can be worked around. Wouldnt mind knowing what causes it thogh.
Like I wrote, I'm currently using only the PV-981 PCIe and the problem is NOT gone, I noticed now, so I doubt it is a bandwidth problem. The images are almost always error free, but only almost...
I just had a monitor window (ZM v1.23.3) with 8 cameras (2 per channel). Two running Modect, all other Monitor.
There was a motion (a person) in two cameras (one Modect, one Monitor) and both had the error lines, but only in and perhaps slightly around the (small) area of motion (!) in both camera images.
Perhaps PCI bandwidth problems result in similar image errors, but I think there must be another problem....
I just had a monitor window (ZM v1.23.3) with 8 cameras (2 per channel). Two running Modect, all other Monitor.
There was a motion (a person) in two cameras (one Modect, one Monitor) and both had the error lines, but only in and perhaps slightly around the (small) area of motion (!) in both camera images.
Perhaps PCI bandwidth problems result in similar image errors, but I think there must be another problem....
Multiplex issue or perhaps PCI latency timing issue?
HI folks:
Okay, I don't know much about these things, but here is a crazy idea
Isn't it possible that with each chip processing only one camera, the logic of the chips works fine,
but once you start adding more cameras with the same amount of chips, and one chip starts supporting
more than one cam, that the logic of the encoder chip or support chips (are there any?) needs to
multiplex/demultiplex video signals, and that multiplexing/demux doesn't always work properly?
Might that explain the symptoms we've seen with both something that looks almost like bandwidth problems
and pictures that are supposed to be on one monitor displayed on another? Not sure I've explained this well,
but I think you can guess what I mean.
What about the possibility that what we have seen could be a combination of both bandwidth problems
AND mux/demux bugs in the microcode?
Also, no one has responded to the other person's post about PCI latency timer setting in the BIOS.
I know I had to adjust that before on several motherboards because certain combinations of mobos and PCI cards
caused a variety of problems. (Try Googling PCI latency timer and Sound blaster static or something similar)
Basic thread with definition of PCI latency timer:
http://www.computing.net/answers/window ... 47078.html
I've noticed quite a few threads in which people report making progress with their pro video editing-type capture cards
by adjusting PCI latency timer.
Let the flaming begin
Brainer
Okay, I don't know much about these things, but here is a crazy idea
Isn't it possible that with each chip processing only one camera, the logic of the chips works fine,
but once you start adding more cameras with the same amount of chips, and one chip starts supporting
more than one cam, that the logic of the encoder chip or support chips (are there any?) needs to
multiplex/demultiplex video signals, and that multiplexing/demux doesn't always work properly?
Might that explain the symptoms we've seen with both something that looks almost like bandwidth problems
and pictures that are supposed to be on one monitor displayed on another? Not sure I've explained this well,
but I think you can guess what I mean.
What about the possibility that what we have seen could be a combination of both bandwidth problems
AND mux/demux bugs in the microcode?
Also, no one has responded to the other person's post about PCI latency timer setting in the BIOS.
I know I had to adjust that before on several motherboards because certain combinations of mobos and PCI cards
caused a variety of problems. (Try Googling PCI latency timer and Sound blaster static or something similar)
Basic thread with definition of PCI latency timer:
http://www.computing.net/answers/window ... 47078.html
I've noticed quite a few threads in which people report making progress with their pro video editing-type capture cards
by adjusting PCI latency timer.
Let the flaming begin
Brainer