Quote:
Originally Posted by jpodolski
Lastly, this is my first post here  so please feel free to let me know if there's any forum etiquette I'm missing.
Thanks all,
-Jeff |
Welcome.
Quote:
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.
|
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.
