Could a software equivalent to TBC be done in Avisynth...

[Chainmax]

...maybe using DePan and MVTools in conjunction?

[scharfis_brain]

maybe you try yourself?

[Chainmax]

Why, is a purely theoretical discussion a sacrilege?

[JohnnyMalaria]

...maybe using DePan and MVTools in conjunction?

Probably not. The correction that a TBC does to the video signal needs to occur before that video signal is 'captured' and forever digitized by your computer (or whatever). You capture device will - usually - just blindly sample the incoming video signal at predefined moments in time - in effect, it assumes that the time base is correct already.

All of the important timing signals etc present within a true video signal are essential to the operation of the TBC. Once inside your computer as an AVI file, all of that information is gone - forever.

[AVIL]

Hi,

IMHO Depan is not useful (modern mvtools make global compensation too). Perhaps a limited de-jittering could be done after 2x horizontal/vertical resizing, mvcompensating with a blksize of 4 and resizing to original size again.

But practise is the best master.

[Fizick]

http://www.avisynth.org/vcmohan/DeJitter/DeJitter.htm

[Chainmax]

Probably not. The correction that a TBC does to the video signal needs to occur before that video signal is 'captured' and forever digitized by your computer (or whatever). You capture device will - usually - just blindly sample the incoming video signal at predefined moments in time - in effect, it assumes that the time base is correct already.

All of the important timing signals etc present within a true video signal are essential to the operation of the TBC. Once inside your computer as an AVI file, all of that information is gone - forever.

Makes sense. Thanks for the explanation :).


http://www.avisynth.org/vcmohan/DeJitter/DeJitter.htm

Awesome, thanks for the link :) http://smilies.vidahost.com/otn/wink/thumb.gif.

[Mug Funky]

dejitter might work a little better if you horizontally resize *4, run it, then resize back. it only seems to do fullpel compensation.

[scharfis_brain]

dejitter for AVS and vhs sync restore for VDub only seem to work with hard thresholded values for the beginning of the active video area. But this is bad if the active video starts with a slow envelope.
thi means:
if the video contents are bright it recognizes a earlier (more left) start
and
if the contents are pretty dark it recognises a later (more right) start of the (virtual)sync.

so both are more or less useless of low jittered sources (one or two pel offset)

[Mug Funky]

ah, fair enough. still it could be useful for transferring beta SP stuff (no sodding TBC card in the digibeta decks... grr) - perhaps the brightness could be turned up before capture?

[scharfis_brain]

perhaps the brightness could be turned up before captureIf you want to overamplify bright areas, too...

I think that a better alogrithm is needed for sync restoration one image basis:
- let the ser define a search window for the beginning of the active image area
- let him also define the width of the expected start of the image (with VHS it is often a slow gradient of at least three pixels)
- let the algo search for this gradient and let it determin its middle point with subpixel accuracy of at least 1/4 pixel
- set this middle point as starting point for the current line.
- optinional temporal and vertical filtering before or after point creation may be useful, cause some of m tapes have a very slow changing sync offset (changes smoothly peridodically every 10 frames)

[Mug Funky]

there's a dial for contrast too :)

clouded had a pretty good looking solution a while ago, but i don't think it was released. that involved strong vertical blur + GMC on each line. i'm sure that could be sped up considerably...

[Fizick]

sonce upon a time I created dejiter beta too which use inter-lines phase correlation (by FFT), but results is not great (some wave) and i did not release it too. :)

[vcmohan]

I think that a better alogrithm is needed for sync restoration one image basis
When I created DeJitter I had as an example one small clip posted by an user. I did not know about the exact way how a vcr tbc is recorded.
- let him also define the width of the expected start of the image (with VHS it is often a slow gradient of at least three pixels)
What sort of gradient. Is it fixed? Increasing decreasing and by what amount?
- let the algo search for this gradient and let it determin its middle point with subpixel accuracy of at least 1/4 pixel
In the images I have seen the variation of values was erratic and I could not see a definite pattern. I therefore did not want to change the actual recorded values by interpolation

As for heavy blurring or using FFT and cross correlating, I tried with very disappointing results. So gave up that approach.

[Mug Funky]

i think what would be really cool is a way to get at the data that capture cards work with - record it in a similar way to PCM audio.

then a codec could be designed that performs these operations on the actual sync data.

not sure if this is possible at all, because as far as i know most hardware doesn't allow access to that kind of info.

[squid_80]

It can be done to a certain extent. Virtualdub's bt8x8 tweaker allows the left border to be pulled out far enough to see the color reference signal, which in theory should be at the same horizontal location for each line. For more damaged sources (when the card can't find hsync) it's possible to hack the drivers to at least get something back besides a blue screen.

[jmac698]

Ultralock™ and Scaling Support
The Fusion family, like the Bt848A, supports Conexant’s proprietary
Ultralock technique that locks to an incoming analog video signal. The
Fusion decoders will always generate the required number of pixels per
line regardless of the analog video source. Ultralock is able to recognize
unstable video signals caused by VCR headswitches or any other deviation
and adapt the locking mechanism to accommodate the source.

In the old days a TBC was an important piece of equipment, now it is no longer necessary as this feature is built into many chips. I can't imagine where you *would* find digitized unstable video.

[Mug Funky]

more often than you'd expect.

there's TBC's and there's TBC's. sometimes they can introduce more jitter than they remove.

domestic DVD recorders don't have them, and even digital betacam decks only have them if you pay extra (they're only needed for digitizing or playing beta SP)

[jmac698]

Here's a practical idea then, put the unstable source through various devices that might have a good chip (called a video encoder). For example a set top cable box (analog in to firewire out), a dv camcorder (analog in to firewire out), or of course any bt848 or bt878 based tv card. I recall, some high end Sony consumer decks had digital still frame, and probably built-in TBC. So just record on some good equipment.
If it's already digital and can't be re-recorded, I would say find the black pixels from either edge and resize to 712/704 pixels line by line. If the picture is black you can't find the edges, but then you don't need to worry :) I agree with scharfis_brain's idea.
I don't agree that you need to see the original sync, the rec.601 is extra wide on purpose (720 pixels instead of 711) to be able to capture the transition pixels. A TV broadcast is very highly stable, the VCR is highly unstable *over small time periods*, and detecting the active line should be all that is necessary, sync just makes it easier to detect. You're not losing information. Adjusting to rise time can be calibrated to the source by examing some white or dark lines. Resizing must be done with a sinc based resizer such as lanczos.
You can adjust brightness and contrast to see blacker-than-black but at the same time not wash out the picture. I've been able to see a few pixels of not sync but purposely blacked out inactive area from a source this way.

[squid_80]

In the old days a TBC was an important piece of equipment, now it is no longer necessary as this feature is built into many chips. I can't imagine where you *would* find digitized unstable video.

Digitized unstable video. (http://members.optusnet.com.au/squid_80/images/unprocessed.PNG) This was captured with an 878. It's true it will always return the amount of pixels and lines requested, but it's no replacement for a TBC. This signal has sync suppression so it's a lot worse than what we're talking about in this thread, but it's correctable if you can manually program the PLL on the card. (Not that I'd know anything about doing that...)

Also examples of what I mentioned earlier: A frame captured from VHS (http://members.optusnet.com.au/squid_80/images/vhs.PNG) and a frame captured from tv. (http://members.optusnet.com.au/squid_80/images/tv.PNG)

[jmac698]

I see what you mean. Such techniques were abandoned in my country a long time ago. I wonder how the 878 is working in such cases? Anyhow, the other caps were very good, would a TBC remove these 2 pixel glitches? It seems you could try to use that white line at the left. With my new pget() script, it is probably possible now.

[Chainmax]

Would using filters like TooT or Average be of help in creating this?