VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 48
Thread
  1. Mountains of gear vaporeon800's Avatar
    Join Date
    Apr 2001
    Location
    Vancouver, Canada
    Search PM
    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
    Originally Posted by SKnet 3DWPro product advertisement [Google translate - JP to EN]
    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
    Originally Posted by SKnet Pure-D product advertisement [Google translate - JP to EN]
    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.

    Name:  ps_3-3a.jpg
Views: 519
Size:  13.4 KB Name:  yajirusi.gif
Views: 515
Size:  144 Bytes Name:  ps_3-3b.jpg
Views: 582
Size:  13.2 KB
    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
    Originally Posted by PLANTEC CRX-9000 product advertisement [Google translate - JP to EN]
    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
    Click image for larger version

Name:	Velocity correction stages.png
Views:	670
Size:	26.8 KB
ID:	35399

    Click image for larger version

Name:	Pixel data velocity correction.PNG
Views:	381
Size:	32.0 KB
ID:	35398

    Originally Posted by Panasonic MN673747 description
    Velocity error/jitter correction used for TBC (Time Base Corrector) ensures accurate time axis correction for the full screen.
    Panasonic MN673794 datasheet excerpt
    Click image for larger version

Name:	MN673794 - TBC mode.PNG
Views:	645
Size:	28.1 KB
ID:	35392
    Quote Quote  
  2. Member
    Join Date
    Dec 2005
    Location
    Finland
    Search Comp PM
    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.
    Last edited by ajk; 28th Jan 2016 at 02:47.
    Quote Quote  
  3. Originally Posted by ajk View Post
    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.
    Quote Quote  
  4. Member
    Join Date
    Dec 2005
    Location
    Finland
    Search Comp PM
    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).
    Quote Quote  
  5. Mountains of gear vaporeon800's Avatar
    Join Date
    Apr 2001
    Location
    Vancouver, Canada
    Search PM
    Then everything typically described around here as a "line TBC" is in fact doing both jitter correction and velocity error correction?
    Quote Quote  
  6. Mountains of gear vaporeon800's Avatar
    Join Date
    Apr 2001
    Location
    Vancouver, Canada
    Search PM
    https://www.google.com/patents/US4443821
    Originally Posted by Sony patent filed 1981
    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.
    Quote Quote  
  7. Member
    Join Date
    Dec 2005
    Location
    Finland
    Search Comp PM
    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.
    Quote Quote  
  8. Yes. For example, one could use a spline curve rather than a simple linear adjustment.
    Quote Quote  
  9. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    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.
    I hate VHS. I always did.
    Quote Quote  
  10. Member
    Join Date
    Dec 2005
    Location
    Finland
    Search Comp PM
    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
    Quote Quote  
  11. Originally Posted by ajk View Post
    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.
    Quote Quote  
  12. Member
    Join Date
    Dec 2005
    Location
    Finland
    Search Comp PM
    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?
    Quote Quote  
  13. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by jagabo View Post
    Originally Posted by ajk View Post
    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
    I hate VHS. I always did.
    Quote Quote  
  14. 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.
    Quote Quote  
  15. Originally Posted by jagabo View Post
    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.
    Quote Quote  
  16. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by pandy View Post
    Originally Posted by jagabo View Post
    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.
    I hate VHS. I always did.
    Quote Quote  
  17. Originally Posted by PuzZLeR View Post
    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.

    Originally Posted by PuzZLeR View Post
    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.
    Quote Quote  
  18. Originally Posted by PuzZLeR View Post
    Originally Posted by pandy View Post
    Originally Posted by jagabo View Post
    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.
    Quote Quote  
  19. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by jagabo
    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.

    Originally Posted by jagabo
    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.
    I hate VHS. I always did.
    Quote Quote  
  20. 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.
    Quote Quote  
  21. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by jagabo View Post
    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.
    I hate VHS. I always did.
    Quote Quote  
  22. Originally Posted by PuzZLeR View Post
    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.
    Quote Quote  
  23. Not sure if i understand you correctly - can you describe more this:
    Originally Posted by PuzZLeR View Post
    Because "a few milliseconds">0-time.
    If this is relative or absolute?
    Quote Quote  
  24. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    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.
    I hate VHS. I always did.
    Quote Quote  
  25. Originally Posted by PuzZLeR View Post
    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?
    Last edited by jagabo; 2nd Feb 2016 at 12:42.
    Quote Quote  
  26. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by jagabo
    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.

    Originally Posted by jagabo
    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.
    I hate VHS. I always did.
    Quote Quote  
  27. Originally Posted by PuzZLeR View Post
    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
    Last edited by pandy; 3rd Feb 2016 at 02:59.
    Quote Quote  
  28. Originally Posted by ajk View Post
    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:

    Code:
    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.
    Image Attached Files
    Last edited by jagabo; 3rd Feb 2016 at 09:56.
    Quote Quote  
  29. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by jagabo View Post
    Originally Posted by PuzZLeR View Post
    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.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  30. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by lordsmurf View Post
    Originally Posted by jagabo View Post
    Originally Posted by PuzZLeR View Post
    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.
    Originally Posted by PuzZLeR
    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...)
    I hate VHS. I always did.
    Quote Quote  



Similar Threads