Archived from groups: comp.graphics.apps.ulead,rec.video.desktop,rec.video.production (
More info?)
"david.mccall" <david.mccallUNDERLINE@comcast.net> wrote in message
news:wQNhd.355849$D%.318795@attbi_s51...
>
> "Mike T" <mtallent@u$-i$p.net> wrote in message
> news:LyGhd.2239541$yk.364158@news.easynews.com...
> >
> >
> > His descripting is functionally accurate, as this is what a TBC is. A
> > video
> > digitizer is also a TBC.
> >
> > The basic TBC function is accomplished by digitizing the video signal
and
> > storing it in memory. What separates the MEN from the boys is how well
> > the
> > sync signals are extracted from the incoming analog video stream and how
> > well the "write" clock tracks the video incoming frequency rate. So for
a
> > VHS type of player, the clock generator must correct for the head-switch
> > error so that there is no picture hook or bending at the top of the
> > screen.
> >
> > Thus, you have two big problems, First, the sync signals are usually
> > distorted and compressed by the tape recording, especially with multiple
> > generations of analog recording and, Second, you need to be able to
store
> > a
> > complete frame of the video signal in memory in exactly one frame of
> > memory,
> > so as the playback frequency of the video signal drifts over time, the
> > "write" clock must be able to very accurately measure the incoming video
> > rate in the presence of noise, sync compression and tape drop-outs, head
> > switch tension errors and I believe the current "phase of the moon" was
> > also
> > important.
> >
> > Over about 20 years of designing TBC's I used many different sync
> > extraction
> > methods and several different clock generators to try to find the best,
> > never did.
> >
> > For the First digital TBC designed in 1972 I used a PLL clock design to
> > lock
> > to incoming horizontal sync and incoming color burst signal as it was a
> > "composite" video world back then, I am very glad it is now gone.
> >
> > Mike Tallent
> >
> A good piece. Thank you. and thank you for being a part of that
> first TBC. How many lines could it do? What company?
The first digital TBC was introduced by Consolidated Video Systems (CVS) at
NAB 1973, it was 8 bits at 3X color or 10.7 MHz and had a correction range
of 3 horizontal lines, using 1024 BIT dynamic shift registers as the largest
RAM chip was 256 BITS and need several support chips per RAM. UGH! I was a
founder of the company and project manager on the TBC and designed the
analog parts with another designing the A/D converter and a third doing the
digital "stuff", guess we helped to put the "silicon" in Silicon Valley.
Sure was a lot of fun in those days in N. Cal.
After CVS, I did ADDA Corp and ALTA Group "stuff"
Here are a few of the patents on this stuff--
http://www.delphion.com/details?pn=US04062041__
http://www.delphion.com/details?pn=US03993982__
http://www.delphion.com/details?pn=US03900885__
http://www.delphion.com/details?pn=US03860952__
In case you want to know more ;-)
>
> Looking back at it now, I'll bet you wished you had microprocessors
> to analyze the signal, instead of just PLLs. On advantage to "capture"
> alone is that you don't have to put the video back out in real time, you
> just have to get it onto a hard drive. With current microprocessor
> speeds, you should have a lot of advantages in terms of line to line,
> field to fields, and even frame to frame comparisons, to get all of those
> pixels lined up just right.
I don't think today the computers are fast enough to do much analysis on the
video signal in real time, and to store the video into memory you STILL have
to know WHERE the video line starts and if you do that correctly the TBC
function is complete.
To store the complete sync pulse into memory in order to analyze it would be
a waste of dynamic range and you still have to "DC" restore the sync pulse
to set it at the proper video level into the A/D converter and if you can do
a proper DC restoration on the incoming video, then you also "know" where
the video line starts so you would also know how to perform the complete TBC
function.
So software is not a solution for this "hardware" problem, at least not yet
Mike T
>
> I'm not saying that they are doing a good job of it, I really don't know,
> but it should be practical to capture most anything directly into the
> computer without an external TBC. I have an old Matrox Digisuite
> and it seems to handle everything I've thrown at it so far, but I really
> haven't had to test it much. I realize that a lot of people are using
> capture cards that are well under $5000, so I wouldn't be surprised
> if their performance was somewhat different. However, there has
> been a lot of time for improvement since this thing was designed.
> A 300 mhz computer was a cooker back then.
>
> David
>
>