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
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 16 of 16
Thread
-
-
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.Want my help? Ask here! (not via PM!)
FAQs: Best Blank Discs • Best TBCs • Best VCRs for capture • Restore VHS -
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. -
*** DIGITIZING VHS / ANALOG VIDEOS SINCE 2001**** GEAR: JVC HR-S7700MS, TOSHIBA V733EF AND MORE
-
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#post1813636Last edited by johnmeyer; 9th Mar 2019 at 10:18.
-
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
-
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? -
-
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 -
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?
Want my help? Ask here! (not via PM!)
FAQs: Best Blank Discs • Best TBCs • Best VCRs for capture • Restore VHS -
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.
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... -
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. -
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. -
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. -
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).
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.Want my help? Ask here! (not via PM!)
FAQs: Best Blank Discs • Best TBCs • Best VCRs for capture • Restore VHS
Similar Threads
-
Key Digital KD-VP8 As External TBC or Video Capture Device
By dellsam34 in forum CapturingReplies: 1Last Post: 24th Dec 2018, 16:26 -
Is a full frame TBC necessary or VCR's builtin TBC enough?
By DNICE_ONE in forum CapturingReplies: 37Last Post: 22nd Dec 2018, 15:03 -
Best External TBC or Frame Sync for Betamax tapes
By Deter in forum RestorationReplies: 5Last Post: 6th Nov 2017, 12:32 -
Marantz MV5100 for Home Movie Digital Conversion (TBC Question)
By bro240 in forum CapturingReplies: 1Last Post: 28th Aug 2017, 05:10 -
What is a good TBC analog - digital converter box for hi-8 tape conversion?
By timecapture in forum CapturingReplies: 2Last Post: 10th Sep 2014, 19:28