Why isn't there a software TBC? (Or is there?)

[swiego]

Pardon the silly question!

As I understand it, a line TBC tracks the horizontal sync pulse of each line of video, digitizes and stores everything after that in memory, then resends it back out with proper sync pulse. And field/frame TBCs operate similarly insofar as they digitize a video signal to buffer it, then send it back out as a reconstruction.

If that's the case, wouldn't it be better to attempt this purely in software, in the digital domain, after the capture, and avoid the conversions?

Just curious what the limitations are... at least nowadays. Are computer systems still not powerful enough to do this kind of thing in real-time?

[edDV]

The problem is this feature isn't built into the capture card. If the capture card had a tracking A/D clock and a frame buffer then the timebase correction could occur with one A/D to the framebuffer then that data could be clocked out to the HDD with proper sync.

Current capture cards use a stable clock to the A/D and don't try to follow small H phase jitter. So the error just gets sampled. Once sampled it is locked to the sample clock.

No reason why a capture card or an input section to a DVD recorder couldn't have built in TBC, other than cost.

By software TBC, do you mean some kind of image processing that would detect errors from the picture? This would be similar to motion detection but what is the algorithm to detect the results of line to line horizontal jitter? The jitter is no longer there, just the artifacts of the jitter.

[swiego]

Sorry, I should have said "post-capture digital" rather than software, but I think you got the gist of my question. I found a discussion about this on usenet where someone said the reason was due to lack of compute power, but that discussion was from the mid-90s I think.

I've been experimenting (for Video8 and Hi8) with a deck unit (EV-S7000) and a Digital8 camcorder (TRV120) and I am finding that the latter in some cases actually seems to produce better output than the former. I've been trying to reason why, and one of the things I've been thinking is that the camcorder might be applying TBC, DNR, etc., then sending that digital signal out the firewire port without any further DA/AD conversions as is the case with the deck unit I use.

[edDV]

Sorry, I should have said "post-capture digital" rather than software, but I think you got the gist of my question. I found a discussion about this on usenet where someone said the reason was due to lack of compute power, but that discussion was from the mid-90s I think.

I've been experimenting (for Video8 and Hi8) with a deck unit (EV-S7000) and a Digital8 camcorder (TRV120) and I am finding that the latter in some cases actually seems to produce better output than the former. I've been trying to reason why, and one of the things I've been thinking is that the camcorder might be applying TBC, DNR, etc., then sending that digital signal out the firewire port without any further DA/AD conversions as is the case with the deck unit I use.

A "software TBC" would need to rely on either image analysis or hardware. It comes down to algorithms, CPU power and cost. It's straightforward although expensive to correct for jitter before or during A/D.

There's a thread going here about TBC performance and they seem to have discovered that a dub to some some DV camcorders produces better TBC performance than stand alone TBCs.

[BrainStorm69]

There's a thread going here about TBC performance and they seem to have discovered that a dub to some some DV camcorders produces better TBC performance than stand alone TBCs.

https://forum.videohelp.com/viewtopic.php?t=289311