Analog full-frame synchronizer wanted?
 

Hi all,

I'm interested in purchasing a frame sync for analog video work. I know there is often confusion regarding terminology, so to clarify, I'm not looking for TBC or a stabilizer. I'm hoping to find a (nearly) real-time device for capturing, storing, and re-timing/re-clocking entire fields to match a genlock input. I'd also appreciate any recommendations for particular models to look out for, as I'm also trying to track these down by setting up eBay alerts.

I'd ideally have NTSC/YPbPr/RGB I/O. I understand that SDI I/O would likely make this an easier find, but I would like to stick to NTSC-only if at all possible.

Lastly, this is my first post here :wave: so please feel free to let me know if there's any forum etiquette I'm missing.

Thanks all,
-Jeff

Welcome. :)

Your terminology is still wrong here.

A mere frame sync does not capture or store anything -- that's a frame TBC function (frame sync TBC).

Mere frame syncs accept incoming data, simple clocks against itself, and immediately releases. Or at least it attempts to do so. The incoming data is dropped/duped as needed, to meet the simple needs of the quick I/O. Mere frame syncs can, and often do, make bad video worse, due to the simple realtime application.

Frame TBCs are for accuracy (data integrity), while frame syncs are looking for signal continuity without any regard to the input quality. Frame TBCs essentially rebuild the faulty signal into compliance, frame syncs have no concept of faulty or accurate. TBCs introduce signal delay (time for capture, correction, store), frame sync do not.

Genlock clocks against another signal, not itself, and without any sort of frame store or correction. It's essentially a frame sync that marries two (or more) video sources.

Line TBC essentially repairs the visual X * Y axis, the frame TBC repairs the non-visual temporal Z axis. This is accomplished by storing and processing data, which is not the simpleton job of a frame sync.

Now then, this all said...

I wonder if you're seeking a SDI converter, which integrates everything into a closed loop system.

NTSC has nothing to do with SDI.
NTSC is a signal, SDI is an interface.

"NTSC/YPbPr/RGB" is also not a thing, not a comparison, or whatever.
- NTSC is the signal type, defined as (digitally) 720x480/486, 29.97 interlaced (ignoring film fps).
- YPbPr is essentially a YUV colorspace (1 luma/green + 2 chroma red/blue at ~50% values)
- RGB is the opposite of YUV (and essentially 4:4:4), and most NTSC/PAL video gear does not operate in that colorspace.

Do not try to buy this gear on eBay. It's a great site for buying non-functional items, like vintage actions figures. But it's a nightmare for quality video gear that is working properly and to-spec.

Bonus example:

The Panasonic DMR-ES10 DVD recorder includes a great example of non-TBC frame sync weaknesses, as it doesn't re-time/realign incoming frames. The ES10 has a strong+crippled line TBC to straighten out wiggles and tearing, and then it gets fed to a mere frame sync that rough aligns the data to the clock.

The problem here is that it can still result in signal slop/chaos that still needs a true store>release retiming. Capture cards can be easily confused by any imperfections, and just drop frames in response (and thus lose audio sync).

Unfortunately the digital/DVD aspect of the ES10 also adds artifacts. So it's not a pure line TBC, nor frame sync. And the line TBC is crippled due to exclusions for anti-copy, which can also cause issues with natural video errors that are similar to the false/artifical anti-copy/Macrovision errors.

Would probably need to know more about the use case, particularly curious why genlock is important to you? Typically genlock would have been used so that you can crossfade/transition different video sources without sync issues for live TV, but I don't think it has much usefulness in the capture space.

I do have a Leitch DFS-3005 unit that I'd be willing to sell, though I don't really have a good way to fully test it. It has separate TBC and Frame Sync Modes I believe. Which functions are available varies based on what mode it is in. See the manual attached so you can look at all the inputs and outputs that has and the description of different functions.

My understanding is that a frame sync is basically a TBC where the timing of the start of the frame is determined by an external (genlock) reference signal which is usually blackburst or triphasic sync signal. A frame sync may not buffer as many fields or frames as a traditional TBC since at max it would need to delay a signal by just shy of 1 frame. Most TBCs I think buffer up to 2 frames (or fields?) at a time.

I think the other purpose of genocked devices were so that you could film a CRT screen without getting the "rolling line" effect on the video camera, but I could be wrong on that. Essentially you'd want to match/synchronize to the refresh rate of the CRT itself.

A frame sync would have a role if being used with a live video camera feed that you're switching from one camera to another, whereas a plain TBC wouldn't really add anything to the chain without that sync feature. TBCs are more geared towards irregularities in the frame arrival times as they are read off of mechanical media in real time (which a live camera feed would not have).