Pico2000 jitter solved, but better solution?

[haus]

I've been working with the pico2000-compatible (card=77) card for a few days now. As soon as I hooked up my 3rd camera, every once in awhile (every couple of hours at least) I would see image "jitter" where maybe 1 or 2 times per second all 3 images in the montage view (or any other view, for that matter) would jump down a pixel and then back up. Like someone was holding each camera and hiccuping (generally once it started it would affect all cameras). I've seen a couple of posts here with similar issues and one issue that was the same, but those solutions didn't help me (one was a cabling issue, the other was a custom multiplexer someone had built). Things were more stable with 2 cameras, and it never happened at all with 1 camera, so it seemed to relate somehow to the issue of switching channels as I added complexity to that task. The jitter caused headaches to the viewer and of course hundreds of false modetect alarms.

In my case the only thing that seems to have solved it is to increase ZM_CAPTURES_PER_FRAME to 2 instead of 1. I've been running this way for 12 hours without a single frame jump; everything looks completely stable so far.

Of course this decimates the frame rate that is already pretty low, from 3-4fps with just 3 cameras attached to 1.6fps. That's a little slower than I was hoping for out of this card (2-3fps was fine).

Now - first, I have a better capture card on the way. It's an 8-chip, 8 port card that others have said they've gotten working with ZM. So I'm excited about that! But I'm still hoping to get some use out of my 77 card. Is there a way to introduce a slight capture delay when scanning channels (thinking in milliseconds) rather than simply making more captures per frame? Would it make any difference? My idea was for ZM to switch channels, then wait N milliseconds and then capture an image. Ideally this would solve the jitter issue without cutting the frame rate down so much.

Just brainstorming here; I have tried a lot of things, though the one thing I haven't tried is putting 75ohm resistance across the last (unused) port. One other person who tried that said it didn't help. I know this issue is sort of on the periphery of what anyone would consider important (esp. given that there are better capture cards out there), and I thought of not even posting, but I realized that someone else might experience the same thing someday and maybe this post would help them find a working solution.

[kamand]

Things were more stable with 2 cameras, and it never happened at all with 1 camera, so it seemed to relate somehow to the issue of switching channels as I added complexity to that task. The jitter caused headaches to the viewer and of course hundreds of false modetect alarms.

Hi, Haus. I think this issue is about TV signal nature(synchronization). Or more precise about even and odd fields of TV frame and bttv drivers. If You know CPU cheap way to determine is this frame EVEN or ODD - than you can solve (maybe) this issue at capture time in drivers. And MS windows based programs can do this( maybe in cooperation with hardware). I had tried some time ago but...... From my point of view any other way - struggle against consequences but not with the reason
Regards
Andrew

In my case the only thing that seems to have solved it is to increase ZM_CAPTURES_PER_FRAME to 2 instead of 1. I've been running this way for 12 hours without a single frame jump; everything looks completely stable so far.

Of course this decimates the frame rate that is already pretty low, from 3-4fps with just 3 cameras attached to 1.6fps. That's a little slower than I was hoping for out of this card (2-3fps was fine).

Now - first, I have a better capture card on the way. It's an 8-chip, 8 port card that others have said they've gotten working with ZM. So I'm excited about that! But I'm still hoping to get some use out of my 77 card. Is there a way to introduce a slight capture delay when scanning channels (thinking in milliseconds) rather than simply making more captures per frame? Would it make any difference? My idea was for ZM to switch channels, then wait N milliseconds and then capture an image. Ideally this would solve the jitter issue without cutting the frame rate down so much.

Just brainstorming here; I have tried a lot of things, though the one thing I haven't tried is putting 75ohm resistance across the last (unused) port. One other person who tried that said it didn't help. I know this issue is sort of on the periphery of what anyone would consider important (esp. given that there are better capture cards out there), and I thought of not even posting, but I realized that someone else might experience the same thing someday and maybe this post would help them find a working solution.