I am also having an issue with lines like that. I wanted the guy to buy an intel chipset mobo but he had a VIA one lying around and we put a pentium D925 with 2 gigs of matched memory.
we have a PV card from blueberry with 8 chip/8 ports and an unknown card with 4 chip/16 port (using one port per chip).
we have all 12 cameras set to 640x480 with shared memory at 256000000
5 fps view and 15 fps alarm .. all cams on modect
if it was just combing lines.. that would be ok.. but these lines show around were the motion seems to be and look like the ones posted here.
I have had issues with via boards on windows setups before with weird IRQ problems. So I wouldn't be surprised if thats what I am having now.
If no one has a solution I will keep trying things and if I find a solution, I will post it.
Lines in recorded events
I did restart the computer after making changes to the shared memory. After looking at it by device. It appears that on this 16 port card, the four ports on /dev/video3 seem to be the worse by a long shot. It on one of them I actually have a picture from another camera combing through. I though it might be easier to see on a video.
http://74.164.210.152/example.mpg
Each of these cameras have a problem that looks like the camera is bouncing a little and every 4 - 8 seconds you get the lines of distortion seen in the video. Any ideas and thanks for helping.
I haven't run a memtest and I can run one tonight if there isn't any other ideas. I don't know enough of the technical about this but how can two pictures bleed together? Is it chipset or software?
Allan
http://74.164.210.152/example.mpg
Each of these cameras have a problem that looks like the camera is bouncing a little and every 4 - 8 seconds you get the lines of distortion seen in the video. Any ideas and thanks for helping.
I haven't run a memtest and I can run one tonight if there isn't any other ideas. I don't know enough of the technical about this but how can two pictures bleed together? Is it chipset or software?
Allan
-
AlienTesticle
- Posts: 23
- Joined: Sun Apr 15, 2007 7:34 pm
yours is doing what I think is happening to mine... its mixing two different camera images together. In your video you can see some hallway in the flashes of lines.
If I view a live stream with no movement it doesnt happen.. when there is movement the lines show up but they are NOT comb type lines due to interlacing at 640x480 res.
so its like the motion detect routines are mixing buffers up. I'll keep playing with settings .
If I view a live stream with no movement it doesnt happen.. when there is movement the lines show up but they are NOT comb type lines due to interlacing at 640x480 res.
so its like the motion detect routines are mixing buffers up. I'll keep playing with settings .
-
jameswilson
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
I have had this with via chipsets and inr-tel on 4400r's I always assumed it was a bus bandwidth or chipset issue. Doesn't happen on cif res's but I'd like to know how you get on
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
I found this to be a problem last year on systems with via chipsets and intel with 4 chip boards such as Kodicom 4400.
http://www.zoneminder.com/forums/viewto ... highlight=
http://www.zoneminder.com/forums/viewto ... highlight=
As far I could guess it has to do with DMA and or interrupts causing these errors when transferring data from the capture card to memory buffers. The lines are actually fragments from previous image buffers that dont dont overwritten completely. Because data is transfered during a single field, errors show up as alternating lines when the 2 fields are combined to produce a frame. (See video ntsc theory.). It's only a theory but seems to be a performance issue when transferring so much data.
Another way of looking at it is when a single video field is being transfered to memory there is no guarantee that the entire fieldset of data will actually make it. The bttv chips do not store a complete frame or field internally but relies on external DRAM memory. I don't think the V4l driver ensures it's complete. So in a heavily loaded system there may be cases where the cpu or DMA cannot handle the transfer for a few lines hence the errors.
When I limited the frame rate at which data is written I can control this. Generally a lower performance systems shows the problem much more often.
http://www.zoneminder.com/forums/viewto ... highlight=
http://www.zoneminder.com/forums/viewto ... highlight=
As far I could guess it has to do with DMA and or interrupts causing these errors when transferring data from the capture card to memory buffers. The lines are actually fragments from previous image buffers that dont dont overwritten completely. Because data is transfered during a single field, errors show up as alternating lines when the 2 fields are combined to produce a frame. (See video ntsc theory.). It's only a theory but seems to be a performance issue when transferring so much data.
Another way of looking at it is when a single video field is being transfered to memory there is no guarantee that the entire fieldset of data will actually make it. The bttv chips do not store a complete frame or field internally but relies on external DRAM memory. I don't think the V4l driver ensures it's complete. So in a heavily loaded system there may be cases where the cpu or DMA cannot handle the transfer for a few lines hence the errors.
When I limited the frame rate at which data is written I can control this. Generally a lower performance systems shows the problem much more often.
If I understand what you are saying, I can lower the framerate which will stop the system from writing as much and drop the load and it should help this problem.
Do you think increasing the processor would help also? Thanks for your input, it makes sense.
*Note: I went and played with the framerate and the changed from modetect to record and it really didn't make a difference. There is a slower processor in this box so I think it may be choking there.
Allan
Do you think increasing the processor would help also? Thanks for your input, it makes sense.
*Note: I went and played with the framerate and the changed from modetect to record and it really didn't make a difference. There is a slower processor in this box so I think it may be choking there.
Allan
Yes. on my intel + kodicom system I did that. Not only that I had to set the writing frame rates to different values - such as 7,8,9 10. What a hack! But it was the only way I could get rid of the lines. I figured it didnt matter anyway since a chip with even 2 shared video inputs were good for only 7.5 frames per second total. Now I only use 640X480 mode so if 'solved' my problem then it should definitely be fine for you at 320X240.
I'll warn you - there are many variables. I also had to ensure that each chip appeared to have it's own interrupt. This is not easily done but rather has to do with 'coaxing' the kernel to distribute the interrupts. Either way you should use lspci -vv to get this info.
You should also optimize performance by limiting features. Disable analysis mode. use rgb565 rather than rgb32 for color selection, stuff like that. It seems the less time spent in an interrupt transfer - the better.
Still it's all a work around and makes the point of using a high performance boards a question in the first place in some cases. The problem might have to be solved in code!
I'll warn you - there are many variables. I also had to ensure that each chip appeared to have it's own interrupt. This is not easily done but rather has to do with 'coaxing' the kernel to distribute the interrupts. Either way you should use lspci -vv to get this info.
You should also optimize performance by limiting features. Disable analysis mode. use rgb565 rather than rgb32 for color selection, stuff like that. It seems the less time spent in an interrupt transfer - the better.
Still it's all a work around and makes the point of using a high performance boards a question in the first place in some cases. The problem might have to be solved in code!
I'll leave these 'low level' questions for someone with knowledge of interrupts or DMA, or any code hackers:
1) Is it possible to block or limit other system interrupts during the time a video line transfer is occurring?
(ie.. to ensure safe transfer of data. )
2) Is it possible to optimize the DMA transfer of video content to frame memory?
This is only my theory as to the problem - and it's just a theory. But if I'm correct then the above should solve all the problems and give much higher performance in terms of frame rates!
-Scott
1) Is it possible to block or limit other system interrupts during the time a video line transfer is occurring?
(ie.. to ensure safe transfer of data. )
2) Is it possible to optimize the DMA transfer of video content to frame memory?
This is only my theory as to the problem - and it's just a theory. But if I'm correct then the above should solve all the problems and give much higher performance in terms of frame rates!
-Scott
The motherboard has an onboard via chipset but I couldn't get it to work very good so now I am using an nVidia add in card.
Using rgb565 on the four inputs that where having the problem helped a lot. The problem is still there just a little but it is much better. It is acceptable now.
Can you give any more details about how to get the kernel to give better interrupts. I know how to use lspci -vv to see what it is using but I don't know what kind of changes to the interrupts to make. Thanks for your help.
Allan
Using rgb565 on the four inputs that where having the problem helped a lot. The problem is still there just a little but it is much better. It is acceptable now.
Can you give any more details about how to get the kernel to give better interrupts. I know how to use lspci -vv to see what it is using but I don't know what kind of changes to the interrupts to make. Thanks for your help.
Allan
Sorry for bumping this thread up.wilso027 wrote:Yeah
Please find my post: Posted: 24 Oct 2006 17:56
http://www.zoneminder.com/forums/viewto ... 7&start=15
May be this is a reason for such lines (PCI bandwith)?
I had finished with YUV422P for capture and code hack to work with these images as internal ZM image format.
I had posted code with hacks and processor specific MMX SIMD optimisations from transcode project for image processing to Zoneminder (YUV422P format and tihis code give me about 5-10% at peak loads against original sources).
Yet another optimisation - jpeg-6bx with SIMD support (about 20%). Search zoneminder forums for links.
With these hacks PENTIUM D 805 at ECS Intel 848 chipdet based motherboard and IDE HDD can handle 100FPS PAL at 768x288 resolution from 4 BTTV chips almost without distorted lines. All 4 cameras are in alarmed state. Compressed image size about 60KB.
Regards
Andrew
-
BrownBottle
- Posts: 18
- Joined: Mon Apr 16, 2007 8:02 pm
- Location: Florida, USA
