Forgive me if you have already answered any of these above but:
1. Have you reconfigured any Pelcos to use internal sync?
2. If so, have you had any of those manifest any symptoms since then?
3. If not reconfigured yet, is it because you can't do it thru the OSD? OScope work required? (God forbid).
4. When you get rid of the Pelcos, thereby fixing 90%, and so occasionally still have the problem, do you care?
Here's my best WAG at the moment:(assuming line lock=true)
Premises: (indicate if disagree)
1. Encoders do not affect cameras thru the video feed, assuming proper termination. (RS-485 aside).
2. Cameras do affect encoders thru video feed.
3. Encoders must sample incoming video signal to extract sync signal and then slave to it.
4. When power is cycled to cameras, sync is lost at encoder.
5. As camera boots, camera must sample mains to find phase and then slave to it.
6. As camera slaves to mains, sync is generated once again by camera.
7. Encoder must resample video and slave to it.
8. When problem occurs, cycling encoder fixes it.
Whos fault is it?
The fact that you can cycle the indigo to fix the problem, coupled with the fact that such cycling does not affect the camera, leads one to the conclusion that the indigo is not properly slaving to the camera and so is primarily at fault. (Think of it this way: whatever it does when it recycles, it should just do without recycling!)
Why do (mostly) the Pelcos manifest?
Perhaps the Pelcos as you imply do not handle the sampling of an erratic main gracefully and end up sending erractically pulsed video which causes the encoder error when sampling. Maybe the other cameras because they are DC or simply designed better handle the sync generation more gracefully...
What about the wiring?
Seems highly unlikely in any case because unlike the other two suspects it is virtually invariant, it goes thru no state change. Furthermore the problem is operating across a wide variety of various balanced and un-balanced media without showing any correlation to the effect.