High CPU on nph-zms process

[robi]

upscaling imho is best done by the browser to conserve bandwith and cpu cycles

Agree, some logic could automatically select the best method, to conserve bandwidth.

[mathewss]

I did some checking to help out and here is the docs regarding capture for vfl.

video4linux/API.html
Once the mmap has been made the VIDIOCMCAPTURE ioctl starts the
capture to a frame using the format and image size specified in the
video_mmap (which should match or be below the initial query size).
When the VIDIOCMCAPTURE ioctl returns the frame is not captured yet, the driver just instructed the hardware to start the
capture. The application has to use the VIDIOCSYNC ioctl to wait
until the capture of a frame is finished. VIDIOCSYNC takes the frame
number you want to wait for as argument.

Looking over PostCapture and PreCapture first glance seems to indicate the proper things are being done so I will do some more debugging this week time allowing to see if i can figure out what is going on.

Re
Sean M

[mathewss]

Ok i have looked over the kernel driver and the code more and again all seems ok. The kernel driver will take a lot to debug so before I dig any farther I would like to confirm this is an issue.


I have researched this and seen several people with different cards see mixed images and jitter using ZM. The parameter ZM_CAPTURES_PER_FRAME was i presume designed to fix this issue yet for me it seems to not work well and i end up with jitter still. Although i dont see a mix of my two cameras on 1 frame i do see my 1 camera as if it were being in the middle of drawing between 2 captures.

I am wondering again how many people were seeing this problem and what drivers they were seeing it with. If it is only the bt8xx driver then at least i know to look here.

Re
Sean M

[mathewss]

Ok i have news. I looked over all this code the kernel etc and everything looks perfect. So why was my video mixed? ok well lets see. I pulled out my sleep statment and low and behold my problem was gone?...

Dammit.. ok what did i do to fix it. I had made one change during my debugging of this problem yesterday. I had change the ring buffer size because of the amount of warnings i was getting in the logs regarding [Buffer overrun]. It was set to 10 on each channel but i changed it to 30 on each channel. So i put one channel back to 10 and BAM!!! my problem returned..

see pictures here in no specific order showing the color shift and camera corruption that happens if i change the value of this buffer.

@20 image is perfect on both channels

@15 color shifted and part of one cam is on the other camera

@10 same as above


Any ideas whats going on here?

Also on a side note you can see from this that one zone has had many motion events yet my second camera has never had any. I have been over the settings many times and i can see no difference between the two caperas or motion zones for them yet it has never seen a single event. If anyone has ideas on that that would be appreciated.

[wilso027]

Thanks for some of the ideas. It's funny that you mention the part of a camera image on another input because I have one camera with the same problem. I had an open port and switched and it fixed it. Also I have a problem with tearing on my images that happens about every 6-9 frames usually around where motion is happening. Any ideas?[/img]

[mathewss]

You should post examples for the record : c ). I dont have any ideas I have not looked at those parts of the code it would probably take me a while to get to know the code well enough to look over the motion detection or buffering portions where i "think" the issues is. It seems like we have some buffer overuns or operations that are bleading across buffers, but thats just an educated guess.

[robi]

Well it's plain to see it's not a capture problem, as the timestamp gets shifted too. Timestamp is applied by ZM way later after capturing, so this problem may be related imho to shared memory or cambozola.

[cordel]

Since he's using Firefox, cambozola shouldn't even be used as it decodes mjpeg naively (assuming it hasn't been forced in ZM's options) so subtract cambozola.

Make sure you have shmmax set high enough according to the calculations in the README and you need some extra fudge room as well (I add a extra 10% typically, as for where I got this number... It just was what I had tried and may be a bit much).
So if your monitors sum up to 132M, then you want to add 13.2M for a total shmmax of 145.2M (just arbitrary numbers for example).

[mathewss]

the cambozilla applet is just a simple java applet that shows 1 video stream at a time from one socket to the web server. It by itself cant access any memory of the other applet running at the same time this would be a violation of the sandbox. So I am 100% sure its not the applet.

I also dont think its shared memery size. Just for starts why would "INCREASING" my ring buffer cause the bug go away if it was a lack of shared memory. It would be understandable if we increased the buffer and we saw problems but not "decrease" the buffer.

My shared memery is as follows

cat /proc/sys/kernel/shmmax
4294967295

Plenty.

Anyone with indepth understaning of the memory buffers and how they are written to around to give some thoughts?

Re
Sean M