There is another A/V adaptor for the Colossus that fits into a spare backpanel slot.

Looks a lot more solid than the first one. Same price.
The Colossus is installed and working, and appears to be stabilizing the captured video timebase to a large degree.

To get to this stage, I had to use the TBC registry edit from this page:
http://forums.sagetv.com/forums/show...=52718&page=76

A driver bug?

The Colossus driver has a "VCR Input" option in the Device Settings/Properties/Video Decoder menu, but it won't stay set! Every time the check box is enabled, it immediately clears. This appears to be a driver bug, related to the device properties window refreshing. I have emailed Hauppauge support about it - still no answer after a few days.

The Colossus handles loss of HSYNC quite well.. A lot better than it handles loss of VSYNC, which results in one or both fields not updating - repeating the previous field from a frame buffer. It handles flagwaving (tearing) better than my analog TV, but it needs to do even better to cope with really bad tapes. Maybe if Hauppauge can fix their driver "VCR Input" option, it may improve things. The Colossus currently doesn't cope with the (non-standard?) video from my VCR menu!

Room for improvement:

My JVC SVHS VCR has had a severe fast jitter problem since it was new. The Colossus is making an attempt to correct these timebase errors, but it leaves fine jitter (about 1 pixel worth) on vertical picture edges. A good quality Panasonic standard VHS deck appeared to have far less jitter than the JVC (but worse flagwaving with a bad test tape). This jitter problem needs further investigation - it could be related to tape transport, higher bandwidth, or an electronics problem. Some improvement has since been made by modifying the "Impedance Roller".

Hauppauge could improve the VHS capture performance of their Colossus driver by changing it to make smart guesses about missing VSYNC, and by fixing the broken "VCR Input" driver option and/or optimizing the hardware settings further. A MANUAL override setting for incoming video standard would avoid the need for the MPEG encoder chip to reset after video loss. There are more settings hidden in the registry than are available in the capture options, but at the time of writing no further performance improvement could be obtained by tweaking some of them.

That's interesting. I've seen video problems where one of the fields froze, which you just described in the capture cards problem. You can fix these captures with a script that looks for frozen fields and motion compensates around them.

I'm considering a hardware solution - A video stabilizer (not a TBC) that can intelligently insert VSYNC when it is missing. My JVC VCR has this option built-in, but on one bad tape I found, the recording VCR wasn't locked onto the VSYNC - so the JVC puts the VSYNC in the wrong place.

Ideally the solution to missing VSYNC would be written into the capture driver (ie: make it more robust), but using a microcontroller it might be possible to decide when to insert some fake sync (and it's a lot easier than building your own capture device :) ).

That's an excellent idea - in fact, you could make a very simple TBC just by replacing all the syncs! That's amazing.. it would be really cheap. There's already sync separator chips, but anyhow, there's uC with level comparators. Just need a resolution of 100nS I think.

Only - You can't make a TBC that way. All you can do is repair missing syncs, or else you'd mess up the video timing since it doesn't actually correct the timebase of the video.

But as a way to "patch up" a bad signal and help a capture device continue to function normally, I think it has potential.

Yes, I agree - I was going to clarify that. However, in most cases the capture card takes care of the horizontal jitter, and filling the missing or weak syncs will make a difference to the final result, in fact in some cases working as a TBC.
Based on discussions with LordSmurf about a "real TBC", he expects the following qualities;
-fix horizontal jitter
-fix bad horizontal jitter aka flagging or missing hsyncs
-fix vertical jitter which could come from bad vsync or possibly slightly mismatched timing between capture rate and source rate
In the case of your new capture card, and this stabilizer, we should finally have a "real TBC" and the total cost would be much cheaper than an external tbc. (or sometimes a tbc and dvr).

btw I learned that flagging was due to the response time of the vcr's closed loop. The problem comes from a mechanical effect at the start of the track and some kind of bump in the head. I'll have to look it up again.
It's basically a slight tape stretch that always occurs (equivalently) at the top of the screen.

So flagging is more of a "phase jump" in HSYNC instead of an actual frequency jump like I said on VH.. Although I'm sure you could get both since they are related..

To be really sure of the Colossus TBC abilities I'd have to make some sort of test like they did in this thread:

http://forum.videohelp.com/threads/2...d-anyway/page3

But it does seem to work better than my HVR-2200 card (except on the VCR menu!).

I've been thinking about that stabilizer idea for a while now.. In fact I built one years ago to stabilize weak signal TV reception. It had a very slow time constant, and could lock to a signal that was so weak you couldn't see it! A VCR unit would have to be much faster to cope with typical VHS jitter.

An update:

I emailed Hauppauge again, and this time they replied quickly. They told me the "VCR Input" option "has no meaning" and it is "just a property page from Microsoft that is being exposed". The respondent didn't know there was a TBC registry setting or even what TBC meant! I replied, explaining the terms and giving them a list of suggestions for new driver options that would greatly assist people capturing from videotape.

I have also been busy designing a microcontroller based video stabilizer unit that can repair damaged sync, and blank noise from a video frame. There is also the option to put a timing reference signal on the edges of the frame for software TBC. It should all help quite a lot even if the software people don't give us poor users better driver options.. :)

I'm sending jmac698 a "broken" TBC (works, but has an unknown noise issue going on), a couple of sample tapes, and a small stack of DVDs for research. You two should definitely exchange information -- and share it here, too. I'd like to see newer and better hardware and software capable of tackling longtime nuisance errors that currently exist as uncorrectable or only mildly correctable.

I'll provide what I can, to support these projects.

Feel free to make this your "home" site and bring others here to join in the conversation. We're interested in professional and advanced hobby video users, and we'll maintain a proper setting for such serious projects. (No trolls here, etc.)

Additionally, as I'll be doing with jmac698 at some point, I've set aside server space for creating a place for developers. I'll maintain the sites, and you can just add/edit the content to reflect updates to your progress. Any developer interested in this, that has a valid project (like you do), should contact me, and we'll get it set up. Again, I want to support these projects properly, instead of damning them to forum posts on amateur sites where the info may get lost or buried. I've seen far too many nifty things disappear over the years, or never get proper treatment.

Thanks. :)

I think you spoiled another surprise! But I've got my own:

It's not making much sense in terms of timing right now, what do you think?

This should probably be a new thread.
jmac's raw video samples.

lordsmurf:
Thanks for the support. I'm going to wait until I get some results before I publish anything though. Still making hardware design changes, and I haven't even started on the software yet...

jmac:
It almost looks like sync and colourburst, but the sync shape seems wrong..
Is that a software tool you have made to examine video problems?
A video CRO?
Or is this the early stages of a DSP VCR demodulator??? :)

It's raw video, this is a big step because I can finally view the sync, at the same time as I capture, so I can see exactly what's happened when the capture doesn't work.

Looks right to me - 4.87uS hsync, and two bright borders with a greyish main line, constant blue color.

So it's actually two full video lines. ok
Those bright borders at the line ends confused me. Yes, it is correct.
The chroma looks totally aliased, but not that important when you're only looking at sync.
Could be a useful diagnostic tool.

Here are some features I've been designing into the stabilizer:
Noise gated black level clamping
Noise gated 50% sync slicing
Hardware sync stripping, squaring and re-insertion
Dropout detector and software sync replacement
Continuously adjustable black and white clipping levels (to limit dropout noise and prevent video AGC problems)
Hardware sync reference video marker for software TBC
Black video generator mode
Software OSD (maybe)

This list may need modification depending on what actually works well in practice.

The microcontroller is an ATtiny2313 @ 20 MHz
All on a PCB about 4.5 x 4 inches, 12V powered, s-video luma only.
Most ICs are SMD, other parts are through-hole.

Due to limited I/O lines, the user interface will be basic. A few buttons and LEDs. Maybe an OSD for video standard display etc.

What CAD software do you use?

ExpressPCB

Video stabilizer progress update
 

Hello all,

Here is a progress update.

A prototype circuit for the video stabilizer has been built, and firmware development is underway. Some additional hardware changes may still be needed.

After doing some tests with a tape containing very bad flagging, I have a new idea about a way to repair it. On the example tape, there was a large head switching glitch on line 9 - making it over 80 microseconds long instead of the usual 64uS for PAL. Since this is happening in the vertical interval (where there is no visible video information - only signal timing info) it should be possible to "remap" the timing of the lines in this area to "smooth over" the abrupt change during the headswitch.

The Colossus capture card video decoder (ADV7441A) is rated for a +-5% HSYNC frequency variation, but this bad tape was actually about +30%!! No wonder it had trouble. By remapping the timing in the vertical interval, it should be possible to smooth this error over 25 lines and reduce the peak error to as little as 0.8uS (+1.25%). Perhaps an even better way would be to ramp the timing changes up and down to avoid any discontinuity at the end points.

It's challenging though, as coping with variable input and output timing is quite a juggling act...

Spot the difference! The attached images show the timing glitch on the test tape mentioned.
(Actual scaling is 500mV/div as the probe was inadvertently set to x10)
Attachment 2910

Attachment 2911

Attachment 2912

The PCB. Most of the ICs are SMD and mounted on the underside.
Attachment 2913

Video stabilizer progress update
 

Video stabilizer progress update

Here are some still frames taken using the Colossus capture card and the experimental video stabilizer.

I currently have two Hauppauge capture cards, the HVR-2200 and the Colossus. The HVR-2200 will reliably lock to video with non-standard structure (such as a VCR menu) or bad flagging, but it doesn't stabilize the typical VCR wobbles as well as the Colossus card does. The Colossus is very fussy about the video being the correct number of lines, and having good VSYNC - though it can cope with missing HSYNC from tape dropouts (but it's timing does drift off).

Attachment 2996

A severe dropout on one field (no stabilizer). You can see the Colossus recover HSYNC timing with a small overshoot after video returns.

The worst flagging example I could find so far...

Attachment 2997

This is a still frame off a tape from 1993, with severe flagging due to different mechanical alignment and poor head/VSYNC phasing adjustment. The wrong phasing does however completely remove the headswitching glitch from the visible portion of the video, and places it in the vertical interval! The JVC HR-S6960 internal video stabilizer was turned OFF in both these examples, as it actually made things worse.

Not perfect, but much better...

Attachment 2998

In this example the stabilizer firmware was written to replace the VSYNC with a near perfect software generated VSYNC that had manually adjustable line length (HSYNC timing). This resulted in the elimination of the flagging (except for a slight but stable bend at the top), even though the headswitching glitch on lines 9 and 322 (of about +-30%) was NOT covered up by this simple technique.

Attachment 2999

Awesome job! It must have been exciting to see the first improvement actually work.

Thanks jmac698 :)

Yes, it was exciting to see it actually working.. It was also interesting that the video signal didn't have to be perfect to fix the flagging problem. I suspect the timing change from adjusting the VSYNC line length was enough to put the glitch outside the Colossus sync gating window.

The main challenge at the moment is to get the timings corrected automatically, precisely and reliably. This will also free up the front panel buttons for their original tasks.

I used this microcontroller based approach because I was confident it could be made to work easily, but I think your technique of digitizing raw video is going to be a lot more powerful at fixing all kinds of video problems.

@AusDaz: Interesting stuff, thanks for posting it. :salute:

I've enjoyed reading this thread.
It gets me into the mood to want to go and experiment with some video hardware myself!