TBC hardware: "velocity error correction" (calling jagabo)

[Brad]

Jagabo explains limitations of line TBC, post #1 & #2

My question is, doesn't "velocity error correction" as described below take account of this issue?

The rest of the post will just be an info dump of my Google research. I've tried to format it as best I can given the limitations of the forum software.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

http://www.sknet-web.co.jp/sknet/goods/3dwpro.htm

In order to calculate the amount of jitter from conventional single synchronization signal in TBC, when the amount of jitter in the left and right of the screen is different, it did not work enough compensation to the right side of the screen. Velocity error compensation is to calculate the amount of jitter from the synchronization signal between the two lines and can display the correct image at all times throughout the screen by applying a compensation to the entire screen.

http://www.sknet-web.co.jp/product/ps01prd.htm

3) Velocity error correction function corresponding TBC

In order to calculate the jitter (distortion) amount from a conventional TBC (time-base-collector) [haha, collector] in a single synchronization signal, when the amount of jitter in the left and right of the screen is different, sufficient correction did not work until the right side of the screen. Velocity error correction is to calculate the amount of jitter from the synchronization signal between the two lines, always by applying a correction to the entire screen and can display the correct image to the corners of the screen.


Conventional TBC .............. velocity error handling

https://translate.google.ca/translate?hl=en&sl=ja&u=http://www.muuz.ne.jp/store/crx900...ml&prev=search

Fixed clock TBC
Jitter (distortion) detects the amount of jitter on the basis of the (strength of distortion), and then corrected accurately extract the image data of the time axis to be taken out originally.
Velocity error correction
If the jitter of the right and left different amount on the screen to calculate the amount of jitter than coaxial signal of one place of the video (1 line) occurs, only the left edge of the screen will not be corrected.
It is now possible to calculate corrected extract the amount of jitter in the line from the synchronization signal between the two lines. This jitter different left and right now correction work on the entire screen be generated by.

Explanation of "velocity error correction" in some book called Video and Camcorder Servicing and Technology

Velocity error/jitter correction used for TBC (Time Base Corrector) ensures accurate time axis correction for the full screen.

Panasonic MN673794 datasheet excerpt

[ajk]

It can't. The only reference points the TBC has to work on are the sync pulses at the start of every line. So it can make sure that each line 1) starts at the correct time and 2) is the correct length, as in your figure 3.44. But it has no way of knowing what correction needs to be applied within a single line, so irregularities in the speed of the head can still cause visual jitter in the image.

Think of stretching a rubber string first by the two ends, but then additionally pulling towards the ends at one or more points in the middle. The distortion can be non-linear but the TBC only sees the endpoints.

In practice, as the head spins within a drum with a relatively large mass, the speed it moves at can't really change very drastically in the short time one line of video represents. An internal TBC within a tape player could theoretically know the exact spin rate at all times and apply a correction as needed, though I doubt this kind of thing exists.

[jagabo]

An internal TBC within a tape player could theoretically know the exact spin rate at all times and apply a correction as needed

But that could only adjust for the speed variation during playback, not during the original recording.

[ajk]

Yep, nothing will of course get rid of first-generation noise or other recording flaws. The best one can do is to not introduce any more when playing back (or capturing).

[Brad]

Then everything typically described around here as a "line TBC" is in fact doing both jitter correction and velocity error correction?

[Brad]

https://www.google.com/patents/US4443821

In the aforementioned patent, the velocity error in each line of video signals written into the time base corrector memory is assumed to vary linearly throughout the entire line interval. Another velocity error corrector which proceeds on this assumption is described in U.S. Pat. No. 4,065,787.

Other velocity error correcting circuits have been proposed wherein the velocity error is assumed to be not necessarily linear, or uniform, throughout the entire line interval. For example, in U.S. Pat. No. 4,165,524, the read-out clock pulses are phase modulated at different rates during a line interval, these different rates being a function of the velocity error that is present in preceding and succeeding line intervals. Also, in copending U.S. Pat. No. 4,393,413, filed Mar. 16, 1981, the velocity errors which are present in three successive line intervals are combined and integrated to produce a nonlinear velocity error correcting signal which then is used to phase modulate the time base corrector memory read-out clock pulses.

Can't say I understand how that would work out.

[ajk]

Hmm.

Patent text is not something I'm going to read in great detail on a Friday night, but I think the idea there is to interpolate the output based on trigonometric functions, instead of a simpler (linear?) approximation. So when the drum is speeding up or down, the TBC takes into account the velocity error over several lines of video and creates a more natural approximation of the original signal. Seems credible that doing so would improve the result, though it still can't fix slight wiggles that aren't predictable from the sync pulses.

[jagabo]

Yes. For example, one could use a spline curve rather than a simple linear adjustment.

[PuzZLeR]

As I was getting at, just before that linked post by Jagabo, so, what we're getting from line TBCs, such as the ES10/ES15 pass-through, is in fact velocity error correction, despite the fact that the tiny quivers remain, albiet much more subtle.

Then again, I see this quivering with anything I've tried, onboard VCR TBCs, full-frame TBCs, etc. I have yet to see a complete solution for this at the capture level.

However, some current software solutions can remedy this somewhat, and some WIP restoration techniques are showing promise for the future. At least there's some hope with post processing.

[ajk]

I think we will never see a (visually) 100% perfect TBC, because 1) as jagabo said, there's already some error introduced as the recording is made and 2) the correction can only be as precise as the sync pulses are and, for many reasons, they aren't perfect.

Eliminating the last bit of visual quivering has to be done by software means; an algorithm needs to examine the image and try to figure out what to smooth away. Considering how well QTGMC does compared to a basic bob deinterlace, or how EEDI/NNEDI does compared to a regular resize, I don't think this is outside the realm of possibility at all.

I think I'll hook up the ES15 to an oscilloscope some time and separate the sync pulses for inspection, much easier to understand what is going on with the processing that way than reading from a book

[jagabo]

Eliminating the last bit of visual quivering has to be done by software means; an algorithm needs to examine the image and try to figure out what to smooth away. Considering how well QTGMC does compared to a basic bob deinterlace, or how EEDI/NNEDI does compared to a regular resize, I don't think this is outside the realm of possibility at all.

But then the algorithm will also remove true details in that same frequency domain.

[ajk]

Yeah, of course. All those processes do, and so do the best denoising filters we have. But that doesn't mean that it can't be an acceptable trade off, if the perceived result is better. Especially if the image is already pretty good after a hardware TBC and the adjustments needed would be quite small. I wonder if someone has ever made a "denoising" filter that specifically targets horizontal movements?

[PuzZLeR]

Eliminating the last bit of visual quivering has to be done by software means; an algorithm needs to examine the image and try to figure out what to smooth away. Considering how well QTGMC does compared to a basic bob deinterlace, or how EEDI/NNEDI does compared to a regular resize, I don't think this is outside the realm of possibility at all.

But then the algorithm will also remove true details in that same frequency domain.

I do think QTGMC is a good example in this case. De-interlacing at the playback level will always be awkward, since you need to be correct on many predictions, which is impossible.

QTGMC's algorithm takes the time to be thorough, and can take all the time it needs when it has the data ready, and much of the guesswork is gone after the playback is captured/recorded, hence the algorithm makes easier decisions field-for-field, improving quality.

Just like deinterlacing software that negotiates a "raking" in the stream is possible at high quality, so is the possibility, IMO, of software that handles a "jitter" or "quiver" in the stream. Same logic in my head, and I can see how, for the same reasons, it can be done better after the capture is complete, not during.

Sure there will be sacrifice and compromise to remove jitter/quiver/wigglie/etc, and just like deinterlacing there will be true detail removed, and I can see it being very slow, at least at first, for higher quality, but I can see a solution like this is very possible, and with an acceptable compromise in quality. If it was as common a problem as interlacing has been we would have already had it.

And there already are a few WIP solutions that are starting to work, and even some threads in this, and other, forums on it.

There's a recent thread here that discusses solutions beyond stab, depan, deshake, Mercalli, etc, and shows promise:
https://forum.videohelp.com/threads/371336-Stabilization-Tools-Pack-v2-1

[jagabo]

I suspect most digital line TBCs use velocity correction. Once the signal is digital it's easy to adjust the line length. Very old analog TBCs may have only adjust the skew. But I'm just speculating here.

[pandy]

I suspect most digital line TBCs use velocity correction. Once the signal is digital it's easy to adjust the line length. Very old analog TBCs may have only adjust the skew. But I'm just speculating here.

Most of the capture chips (i.e. digital decoders) is capable to perform some form of such processing - it has various names (for example Bt878 UltraLock) but similar principle.

[PuzZLeR]

I suspect most digital line TBCs use velocity correction. Once the signal is digital it's easy to adjust the line length. Very old analog TBCs may have only adjust the skew. But I'm just speculating here.

Most of the capture chips (i.e. digital decoders) is capable to perform some form of such processing - it has various names (for example Bt878 UltraLock) but similar principle.

I would assume such hardware may need a buffer, to hold such frames, to be effective.

Yes, a delay may occur, but that's fine as long as it's peforming in the end, but such a delay to me would be simulating an environment similar to software post-processing on a ready-made capture. If so, even though it would be a solution "on the fly" on the label, it's still, IMO, a post solution in many ways.

[jagabo]

Most of the capture chips (i.e. digital decoders) is capable to perform some form of such processing - it has various names (for example Bt878 UltraLock) but similar principle.

I would assume such hardware may need a buffer, to hold such frames, to be effective.

You don't know how long a line is until you've captured a complete line, sync pulse to sync pulse. Then you need to go back and stretch/shrink the line. So yes, you need at least enough memory to hold one line. You probably need a second buffer to capture the next line while the first is being processed. Maybe even a third, one line being captured, one line being processed, and one line being output to the DAC.

Yes, a delay may occur, but that's fine as long as it's peforming in the end, but such a delay to me would be simulating an environment similar to software post-processing on a ready-made capture. If so, even though it would be a solution "on the fly" on the label, it's still, IMO, a post solution in many ways.

Not at all. The delay is only a few scan lines. And it has access to the sync pulses which post capture software doesn't.

But even if most capture chips have the ability it's rarely implemented in the provided drivers. So it's useless unless you want to write your own drivers.

[pandy]

I suspect most digital line TBCs use velocity correction. Once the signal is digital it's easy to adjust the line length. Very old analog TBCs may have only adjust the skew. But I'm just speculating here.

Most of the capture chips (i.e. digital decoders) is capable to perform some form of such processing - it has various names (for example Bt878 UltraLock) but similar principle.

I would assume such hardware may need a buffer, to hold such frames, to be effective.

Yes, a delay may occur, but that's fine as long as it's peforming in the end, but such a delay to me would be simulating an environment similar to software post-processing on a ready-made capture. If so, even though it would be a solution "on the fly" on the label, it's still, IMO, a post solution in many ways.

This is simpler - you know time between two sync pulses (between 0h time for line n and 0h for line n+1) for 50Hz systems it is 64uS - every pulse in video signal is very precisely described and line length can be precisely described.

[PuzZLeR]

Not at all. The delay is only a few scan lines. And it has access to the sync pulses which post capture software doesn't.

I can’t see how this quiver/jitter can be corrected without any delay at all.

You are right, but it’s debatable. Something more "soft-coded" at the capture level is easier to work with than something completely "hard-coded" after the capture is done and totally stopped. I get it.

But, as I said, “in many ways", similar to a post solution - something you have to do after the capture - however small a fragment you're working with, any non-zero delay, even if only a ms, line, field, frame, etc, is still a delay.

You need this delay/buffer to work with to have any significant effectiveness.

A buffer to me means something “post”, even if it is something miniscule, and even if it’s during the capture.

But even if most capture chips have the ability it's rarely implemented in the provided drivers. So it's useless unless you want to write your own drivers.

Such a solution, if it exists, would indeed be the most desirable. However, such drivers would indeed be delay/buffer/post-centered to have any effectiveness. Without them, you'd need to rely on a complete software procedure after the fact for any quality correction IMO.

[jagabo]

The point is that jitter/velocity correction can only reliably be done with access to the horizontal sync pulses. I don't understand your point about a delay. What's the problem with a few milliseconds delay receiving the data? Every TBC, even if it's in the SVHS deck, or any other digital processing unit, introduces a delay.

[PuzZLeR]

What's the problem with a few milliseconds delay receiving the data?

Because "a few milliseconds">0-time.

My point is that you need a 0+ delay to achieve a desirable result.

[jagabo]

My point is that you need a 0+ delay to achieve a desirable result.

What practical difference does that make? Even passing an analog signal through a cable causes a delay. There are delays everywhere in everything.

[pandy]

Not sure if i understand you correctly - can you describe more this:

Because "a few milliseconds">0-time.

If this is relative or absolute?

[PuzZLeR]

It's not about the "delay". My point is that, when it comes to handling this jitter, you need some form of processing after the capture, even if it's only a segment of a capture, to be effective. You can't do it with any reasonable results during.

Of course, hardware has the advantage of having the info in real time, but without performing any sort of processing after a capture segment, it's not going to be any more effective than a software solution.

[jagabo]

My point is that, when it comes to handling this jitter, you need some form of processing after the capture, even if it's only a segment of a capture, to be effective. You can't do it with any reasonable results during.

Of course. To process video digitally you must first convert it to digital. And as I pointed out, you can't know how long a line is until you've captured the entire line (sync pulse to sync pulse). So the minimum delay is the duration of one scan line. There is no other way to do this since analog video doesn't include a data clock.

But what is the point of bringing this up? Do you have a better way of fixing VHS horizontal sync jitter?

[PuzZLeR]

But what is the point of bringing this up?

Just a debate that went astray.

Just pointing out that if you have to do something "after" the fact for better results, even if it's only a segment of the capture at a time, it better demonstrates how software and post processing rise up in status of being more "comparible" to a hardware solution.

Do you have a better way of fixing VHS horizontal sync jitter?

As per having a better way of fixing jitter - you bring up something very interesting. I've recently started coding again - first time in years. I'm not "there" yet when it comes to video tools, but do have some ideas for this problem. Hopefully one day I can contribute to it.

[pandy]

It's not about the "delay". My point is that, when it comes to handling this jitter, you need some form of processing after the capture, even if it's only a segment of a capture, to be effective. You can't do it with any reasonable results during.

Of course, hardware has the advantage of having the info in real time, but without performing any sort of processing after a capture segment, it's not going to be any more effective than a software solution.

Any form of processing after will have same success as image recognition - without sufficient resources you will end very close to point where HW is. Decent oversampling may help but... at some point you will be forced to start doing "educated guessing".

http://www.ronaldsnoeck.com/vcr.htm

[jagabo]

Eliminating the last bit of visual quivering has to be done by software means; an algorithm needs to examine the image and try to figure out what to smooth away. Considering how well QTGMC does compared to a basic bob deinterlace, or how EEDI/NNEDI does compared to a regular resize, I don't think this is outside the realm of possibility at all.

Actually, QTGMC works moderately well with mild horizontal jitter:

TurnRight().QTGMC(InputType=1).TurnLeft()

Attached is an example where one field of a video has been isolated. On the top is the original VHS recording, on the bottom is the field stabilized by QTGMC. This one was easy because it's a still image. It may not work as well on moving images. Of course, the jitter is less noticeable on moving objects.

[lordsmurf]

My point is that you need a 0+ delay to achieve a desirable result.

What practical difference does that make?

I often wonder this myself.

[PuzZLeR]

My point is that you need a 0+ delay to achieve a desirable result.

What practical difference does that make?

I often wonder this myself.

Just pointing out that if you have to do something "after" the fact for better results, even if it's only a segment of the capture at a time, it better demonstrates how software and post processing rise up in status of being more "comparible" to a hardware solution.

I was referring to processing anything in between a buffer to hold so many lines/fields/frames/seconds to the whole capture itself.

Geez, it's not that big a deal of an explanation. I was stating that, IMO, you can't do this on the fly. That's all.

(Please don't ask what, now...)