VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 16 of 16
Thread
  1. Member
    Join Date
    Mar 2019
    Location
    Germany
    Search PM
    Hi folks,
    I wrote a simple digital frame sync TBC because my capturing rig has a great line sync TBC but some of the fields jump up or down by a few lines, especially after cuts in the video... It's in python using ffmpeg for video decoding and encoding.
    https://github.com/HENDRIX-ZT2/frame-sync-tbc
    Quote Quote  
  2. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    I have never seen anything that could claim to be a "software TBC", and doubt that I ever will.

    The closest we're getting is to RF capture the signal, but it's still in extremely early stages. And not sure that will ever come to fruition either. Once that signal is acquired, then maybe, maybe, an algorithm could crunch it to motion estimate timing issues. But still far-fetched right now.

    https://www.domesday86.com/?page_id=1379 (ignore LD aspect, focus on VHS usage)

    We briefly discussed this here: http://www.digitalFAQ.com/forum/video-capture/9432-decoding-vhs-rf.html

    jmac tried to make a software TBC about 8 years ago, and I still have his Avisynth code, but it never really worked. He had a few nice non-real-world samples, but that's all he could ever produce.

    I'm not sure how to use your creation, but it'd be ideal to post some clips of it in action.
    Quote Quote  
  3. Member
    Join Date
    Mar 2019
    Location
    Germany
    Search PM
    In essence it is nothing more than a stabilization operating on single fields. It just corrects fields jumping around due to lack of a frame TBC in my signal chain.
    Here's a real world sample: https://we.tl/t-KCbNBt4asv
    Observe the shaking picture at 7, 16, 30 and 40 seconds in the "raw" version.
    The processing greatly reduces this effect. There is still a very slight, but noticeable instability left in these spots, but it is a lot better, without introducing false positives ("swimming pictures") from excessive stabilization.

    I've heard of jmac's attempt. That RF capture project looks really interesting. If you have the RF, you could write a proper line and frame TBC easily. They seem to have implemented that already, for laserdiscs at least. When you have the RF signal there's no need for motion estimates or anything, as you have access to the same start and end markers of each line that are used by physical TBCs.
    Quote Quote  
  4. Originally Posted by csnyfan View Post
    I've heard of jmac's attempt. That RF capture project looks really interesting. If you have the RF, you could write a proper line and frame TBC easily. They seem to have implemented that already, for laserdiscs at least. When you have the RF signal there's no need for motion estimates or anything, as you have access to the same start and end markers of each line that are used by physical TBCs.
    I'd love to read anything related to this laserdisc tbc. Do you have links ?
    Quote Quote  
  5. Member
    Join Date
    Mar 2019
    Location
    Germany
    Search PM
    Originally Posted by themaster1 View Post
    Originally Posted by csnyfan View Post
    I've heard of jmac's attempt. That RF capture project looks really interesting. If you have the RF, you could write a proper line and frame TBC easily. They seem to have implemented that already, for laserdiscs at least. When you have the RF signal there's no need for motion estimates or anything, as you have access to the same start and end markers of each line that are used by physical TBCs.
    I'd love to read anything related to this laserdisc tbc. Do you have links ?
    https://github.com/happycube/ld-decode/tree/master
    https://github.com/happycube/ld-decode/wiki
    Quote Quote  
  6. Here is a link, over at doom9.org, to one of Jmac's attempts at a software TBC:

    New Script: Software TBC 0.6 & Sample (was Fast Line Shifter 0.53)

    He was trying to do a line TBC and it required the ability to capture enough of the area at the edge of the video to be able to "see" the blanking at the edges. Not all capture cards provide that.

    The theory seemed sound, but he never got it to work.

    Despite his failure, I don't share Lordsmurf's pessimism. I see no reason why this couldn't work, but it will require looking at more than just adjacent lines, and also will require looking at multiple frames. As a result, the data structures are going to be pretty hairy. The person doing the work will have to be a very seasoned programmer.

    In my experience with VHS, a line TBC would be far more valuable than a frame TBC. The little "jumps" in the OP's sample video can pretty easily be removed with a motion stabilization plugin, if that stabilization is properly tuned to only look for vertical jumps (easy to do in Deshaker), and to only look for jumps which last for 1-2 frames.

    [edit] To the OP: here is a link where jmac provided extensive information on the challenges he faced, along with references to some scholarly research on the topic:

    https://forum.doom9.org/showthread.php?p=1813636#post1813636
    Last edited by johnmeyer; 9th Mar 2019 at 10:18.
    Quote Quote  
  7. P.S. Since I mentioned software-only line TBC correction, and since I also challenged the pointless pessimism that says it can "never" be done, here is a link to a somewhat similar challenge that I was able to fix (90+ % improvement):

    Repair Bad Deinterlacing

    This particular problem involved un-doing the absolutely horrible artifacts which result from re-sizing interlaced video without first deinterlacing. Fixing these artifacts involved shifting groups of fields horizontally so they line up. In short, it was a very similar problem to identifying and shifting individual lines which have been shifted because of time base errors. As you can see from the post that I linked to, I was able to undo almost all of the problem and the only residual artifact were some slight horizontal lines, and those were only at some locations. I'm pretty sure those could have been further reduced, if I'd spent more time on it.

    The OP already demonstrated that he has produced algorithms which reduce the small jumps in his "before" video, and therefore to say that it cannot be done is to deny the reality of the result.
    Last edited by johnmeyer; 9th Mar 2019 at 10:12. Reason: added formatting
    Quote Quote  
  8. Member
    Join Date
    Mar 2019
    Location
    Germany
    Search PM
    Yeah, a fully-fledged digital TBC is definitely possible. It all comes down to the source material. If you have access to the RF and a suitable demodulation pipeline, it is easy peasy. From standard video captures, don't expect miracles as you have to do some sort of motion estimation. I do have a (very limited) dedicated line TBC emulation, which tries to figure out the correct line offsets using cross correlation of each line to those of the surrounding frames. It is not reliable enough to be used per frame, but it was very useful to align the lines of a video whose odd frames were skewed and offset from the even frames by a constant amount.

    What my frame TBC does to get the shifts is calculate the cross-correlation of each frame to the average of N surrounding frames. The image is then moved into the desired direction by whole pixel steps (no blurring from resampling).

    Will have to try that deshaker plugin so I don't have to leave avisynth to remove these jumps... Do you happen to have suitable deshaker parameters for this sort of frame sync issue?
    Quote Quote  
  9. Originally Posted by csnyfan View Post
    Will have to try that deshaker plugin so I don't have to leave avisynth to remove these jumps... Do you happen to have suitable deshaker parameters for this sort of frame sync issue?
    Try Stab():

    Code:
    SeparateFields()
    evn = SelectEven().Stab()
    odd = SelectOdd().Stab()
    Interleave(evn,odd)
    Weave()
    You could probably improve on this by eliminating sub-pixel motions.
    Quote Quote  
  10. Originally Posted by johnmeyer View Post
    Here is a link, over at doom9.org, to one of Jmac's attempts at a software TBC:
    I did a few experiments with video recorded by a digital oscilloscope and posted about them in this thread:
    https://forum.videohelp.com/threads/381019-Capturing-full-525-lines-of-NTSC-frame?high...t=oscilloscope
    Quote Quote  
  11. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by csnyfan View Post
    In essence it is nothing more than a stabilization operating on single fields. It just corrects fields jumping around due to lack of a frame TBC in my signal chain.
    Those sorts of errors can happen with or without TBC. What you've done isn't at all what I'd consider a software TBC, but rather a decent stabilizer/deshake algorithm. I' actually be quite interested in testing this, but I'm not really familiar with what you've done, and the instructions we gave already assume familiarity and knowledge of them. Is this supposed to be run on Linux?
    Quote Quote  
  12. Member
    Join Date
    Mar 2019
    Location
    Germany
    Search PM
    Originally Posted by lordsmurf View Post
    Originally Posted by csnyfan View Post
    In essence it is nothing more than a stabilization operating on single fields. It just corrects fields jumping around due to lack of a frame TBC in my signal chain.
    Those sorts of errors can happen with or without TBC. What you've done isn't at all what I'd consider a software TBC, but rather a decent stabilizer/deshake algorithm. I' actually be quite interested in testing this, but I'm not really familiar with what you've done, and the instructions we gave already assume familiarity and knowledge of them. Is this supposed to be run on Linux?
    This jumping did not occur on my TBC-free signal chain, so it's clearly not on the tape but merely a playback artifact.
    My script here is clearly not a software line sync TBC (it does not align each line), but it could be called a software frame sync TBC with some justification (it aligns each frame, or rather, each field).

    You don't need linux, I'm not even sure if it runs on linux (depends on the python dependencies, but probably yes), I run it on windows 10. Basically, install python 3.6, install the python packages listed on the page with pip and make sure you have ffmpeg installed on your system.

    Originally Posted by jagabo View Post
    I did a few experiments with video recorded by a digital oscilloscope and posted about them in this thread:
    https://forum.videohelp.com/threads/381019-Capturing-full-525-lines-of-NTSC-frame?high...t=oscilloscope
    Very cool, a bit of line sync error remains but certainly interesting. Is it feasible to capture more than a single frame with that oscilloscope card? Will try stab() soon...
    Quote Quote  
  13. Originally Posted by jagabo View Post
    I did a few experiments with video recorded by a digital oscilloscope and posted about them in this thread:
    https://forum.videohelp.com/threads/381019-Capturing-full-525-lines-of-NTSC-frame?high...t=oscilloscope
    Wow, what a cool read. I didn't know about those digital scopes. Maybe I can finally get a replacement for the Heathkit scope I built in 1975, and which I still occasionally use.

    I realized something when reading the posts in your link, and which is important in any work attempting to adjust line-by-line timebase errors in software. Here is that thought:

    Every point along an analog scan line comes from a different moment in time.

    This is really important, and I've seen many digital video restoration algorithms which make the assumption that the entirety of each scan line comes from a single instant in time. This is a true statement when dealing with interlaced video from a modern digital camera because those dump the CCD or CMOS data all at once. By contrast, analog video was created by a CRT-like device that used a scanning beam modulated linearly (moved horizontally) by a charging capacitor. Its intensity at each moment in time was controlled by the light entering the camera.

    If the restoration algorithm doesn't take this into account, you will get errors left to right.
    Quote Quote  
  14. Originally Posted by csnyfan View Post
    Originally Posted by jagabo View Post
    I did a few experiments with video recorded by a digital oscilloscope and posted about them in this thread:
    https://forum.videohelp.com/threads/381019-Capturing-full-525-lines-of-NTSC-frame?high...t=oscilloscope
    Very cool, a bit of line sync error remains but certainly interesting. Is it feasible to capture more than a single frame with that oscilloscope card? Will try stab() soon...
    Originally Posted by johnmeyer View Post
    Wow, what a cool read. I didn't know about those digital scopes. Maybe I can finally get a replacement for the Heathkit scope I built in 1975, and which I still occasionally use.
    The scope is a 50 MHz Rigol DS1054Z:

    https://www.amazon.com/Rigol-DS1054Z-Digital-Oscilloscopes-Bandwidth/dp/B012938E76
    https://www.youtube.com/watch?v=ETCOhzU1O5A

    Hacked for 100 MHz operation:

    https://www.youtube.com/watch?v=aNy6-CLS3BI

    It has enough memory for 24 million samples, several frames at 20ns per sample. In the thread you can see a zoomed out view of 7 consecutive fields. One problem for NTSC video is that it's not sampled at NTSC sampling rates. So a scan line isn't an integer number of samples. You can see the skew this causes in one of the images. It has a "video mode", maybe I'll try that some day.
    Quote Quote  
  15. Thanks! It has a very nice review profile. I put it into my Amazon "wish list." When I'm feeling flush I sometimes buy things off that list and, at the end of the year, if I haven't quite worked myself up to buy, it goes onto my Xmas list (although this is a bit too much money for that).

    I mentioned that Heathkit oscilloscope and just a few years before I built that I designed and built a power supply. It was one of the first things I ever built and, to say the least, the build quality and features left a lot to be desired. About two years ago I got worried that it might not be safe so I bought a proper bench power supply. My reaction after using it was, "why the heck didn't I do that about twenty years ago?" My oscilloscope is safe, but it maxes out at 20 MHz and has really basic features. I worked from '73 to '77 at Hewlett-Packard's test and measurement divisions and had a chance to use some of the best test equipment in the world. While I don't do as much bench work now, a good scope would be nice to have.
    Quote Quote  
  16. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by csnyfan View Post
    This jumping did not occur on my TBC-free signal chain, so it's clearly not on the tape but merely a playback artifact.
    Do not make leaps, that's bad science.
    If John likes bananas, and John lies blue, are bananas therefore blue? No, that's silly, bad logic.

    The issues you're seeing are more complex, and can merely be an interaction between hardware in the workflow, combined with bad signal from the tape. Like I said, those sorts of issues cam happen with or without TBC, I've seen them many times over the years. Yes, it can be lack of line/frames TBC, but not necessarily.

    but it could be called a software frame sync TBC with some justification (it aligns each frame, or rather, each field).
    I just don't agree with that. It's a stabilizer, and very decent one from your samples. I'll try it myself sometime.

    You don't need linux, I'm not even sure if it runs on linux (depends on the python dependencies, but probably yes), I run it on windows 10. Basically, install python 3.6, install the python packages listed on the page with pip and make sure you have ffmpeg installed on your system.
    Thanks for the clarification.
    Quote Quote  



Similar Threads