Ancient history, time base correction and frame sync or genlock

Time base correction (TBC) for a VCR or used during VHS tape capture seems to relate mostly to correcting the Horizontal sync pulse and the length of the video line timing as it passes through a one or two line buffer.

A line buffer type of TBC was the most common until digital memory prices fell far enough to make field, or full frame "synchronizers" more practical.

What this means is a Level 1 - TBC (a small number of lines buffer tbc) would potentially "band" or stagger its fixes across the entire field and frame of the picture when it was output.. but usually it was unnoticeable unless scaled up, during which aliasing artifacts could appear. - This appears to be why it can be a good thing to disable an older "line-based" time base correcting circuit built-into a VCR when planning to capture and or scaling up a capture using an external device called a "scaler".

What this means is a Level 2 - TBC (only a field tbc) could potentially "jump" or de-sychronize between fields.. perceived more as a glitch, mostly depending on how bad the vertical sync retrace or VTI were between frames. Since "field based" tbcs were not on the market long before being replaced by the more expensive "full frame" capture time base correctors.. these problems are not as common as others. However they could produce a superior capture experince.. since they would not attempt to de-interlace the picture with an out dated poorer quality de-interlacing method.

What this means is a Level 3 - TBC (a full frame tbc) would normally be best.. with one exception, at some point the frame output (which may also perform a poor version of de-interlacing.. since that as a simpler output circuit than leaving it interlaced) may have to drop or repeat a frame in order to remain broadcast "locked" to a data frequency that matches broadcast standard.. while this could be minimized by using genlock.. it could also cause frame jumping vertically in a free running work flow with no genlock use. - While a free running full frame tbc would place that burden on the capture card.. since at some point it will have a a buffer over run or underrun.. and the capture card hardware or software will have to make a decision as to how to handle the situation.. its a choice.. of leaving the decision up to the TBC.. or leaving the choice up to the capture card.. as to how to handle the situation.

TBC - "time base correction" traditionally focused on "curing" problems with the Left "edge" or horizontal portion of the scan lines. While "genlock" or frame sychoonization focused on curing problems with the Top "edge" or the Top and Bottom edges of the field or frame as the field or frames were displayed and the next was setup by moving the focus of the scanning beam back to the top of the visual field.

So "tbc" is mostly about Left edge problems and "frame sync" is mostly about Top edge problems

When things go wrong, 

A flag waving from the Upper Top Left edge is fixed using a TBC or a TBC that specifically "locks" its Left edge "frame clock" before additional lines are displayed.. a TBC that waits and samples more lines may "drift" back and forth releasing some of the Top Left lines before it settles down and locks. It "locks" fast.. as opposed to a broadcast TBC which is seeking to lock on an over the air transmission which may have additional problems related to signal ghosting and locks "slow". Some broadcast TBCs have a setting specifically to support use with a "VTR" in the studio environment.. that locks "fast".

A "vertically jumpy" or "rolling" problem is a frame sync problem and relates to stably outputting a field or frame at the right rate and time to match the expectations of the broadcast standard, or house timing genlock called a black burst.

Ideally and in practice.. a tbc does not do the job of a frame sync.. and a frame sync does not do the job of a tbc. They are two very different things. However some early devices for broadcast and for the consumer combined the two functions in a single box. Whether it actually did correct the Left "Edge" or not is often the question.

And they use digital computer memory to store different parts of the picture.

A tbc samples and stores and corrects and outputs line information.

A frame sync stores all of the "assumed" correct line information for a field or frame and outputs field or frame information.

Performing a tbc on the line information before its captured by the frame sync is important.. since it avoids over and under runs in the frame sync which can make problems with the vertical "jumps" and frame sync output "worse" if it is not performed.

TBC's for the most part are no longer made.. and if so its mostly for SDI.. or serial digital inteface output. All video signals are assumed to have already been converted to some digital format and are rendered analog only in exceptional circumstances and probably not likely to be broadcast in native form.

Frame synchronizers are still made and SD or HD versions are available, often with scalers. But these regularly go for many thousands of dollars used.

Video switchers and DVD recorders are looked upon as potential sources for TBC and Frame sync work.. as pass thru devices.. but for the most part are frame sync devices only. They "appear" to be time base correctors because they have to digitize the entire field.. but more often also de-interlace and output the complete frame.. the effect is the output can have many Left "edge" problems and problems with line length since those devices never attempted anything in the slightest to correct problems with line length. Worse.. the problems are "fixed" by simply "chopping off" badly timed lines and throwing the rest away.. baking in the problems.. from which there is no current way to recover missing information.

True "time base correctors" probably stopped being made about the year 2013 and the use in consumer projects and some commercial projects have probably accelerated the degradation of the supply in the used market.. making them all but  unobtainable in good working condition. Some are servicing the short term electrolytic capacitors.. but these are rare and not often found.

FPGA efforts in the "line doubler world" or inexpensive "scaling" for the Gaming community for streaming is developing an ability to perform many of the functions of not only frame sync.. but also encroaching on the true - time base corrector realm as some older game consoles also had Left "edge" problems.


Blackmagic Thunderbolt Shuttle Video Capture on Windows XP

 Finally got a chance to look at a Shuttle on XP, not the same as an Extreme.

VLC seems to sort of work with it.. but with a lot of trouble.

The Decklink device drivers reject a 720x486 or 720x488 resolution and default to something ridiculous like 720x30.

But trying the Blackmagic WDM driver seems to behave ok with 720x480, but doesn't provide an audio stream.. so right now its very confusing.

The Blackmagic Desktop Video and Driver suite on Windows XP is the first version that I know of that included support for both XP and Thunderbolt Shuttle.. so I guess its a bit early and unstable.

Noel AMCap seems to work just fine with it, and Blackmagic Media Express, and GraphEdit seems to work with it.


Blackmagic Thunderbolt Extreme Video Capture on Windows XP

It would appear the Media Express capture program is not DirectShow based. 

This would make sense as Blackmagic makes a version for other platforms. It appears to use the QT user interface library which is also cross platform.

A best guess would be like VLC, they use a libavcodec or a wrapper like ff to use libavcodec.. but I'm betting they had to keep it simple. There is an LGPG notice included with the program that might refer to the QT libraries used.. or deeper in the code. I did not see a separate libavcodec dll included with the program, so if it is used.. its function are integrated with Media Express binary as a static compile. It is a medium sized executable. dedicated to one purpose.

The weak link in all of my captures has been Uncompressed at 8 and 10 bit resolution direct to hard disk.

Media Express does a good job of capture and maintains sync as far as I have tested.. but my hard drive speed is borderline and would probably not keep up long term.

VLC so far has not been able to keep up and appears to loose sync between the audio and video tracks when captured with the default Raw Record button. Adding a Transcoder to capture as MPEG2 or H.264 would seem to be a loosing proposition.. but might work, if the CPU is not overloaded and can reduce the stream speed such that the hard disk can keep up. Huffyuv is also possible with VLC and might make a reasonable compromise. -- noted that VLC is also capable of decoding and playing back Huffyuv on the fly! Which is quite impressive.

The Blackmagic Intensity Extreme is about ten years old, and in those days the limitations were as now the hard disk speed, in fact they include tools to test the speed.. and recommendations of always using a RAID0 situation to stripe the speed load across multiple disks. Today SSD might be able to keep up, but the individual SATA drive connections may still be too slow.

Noel's AMCap for Windows XP is no longer sold.. however due to his kind response to a plea for help, he did sell me a copy.. and that does appear to work excellently with the Blackmagic Intensity Extreme on the Windows XP laptop across the Thunderbolt connection.

Noel's AMCap for Windows now focuses on 64 bit versions of Windows and more modern versions of the Windows Kernels.. and had to leave Windows XP compatibility behind with the Version 9 of AMCap.

VirtualDub 1.9.11 does a respectable job of capture, but I am concerned compared to Media Express, or even VLC.. its a rather Large and Excessive program just for capture.. it has measures to try and help with hard disk speed like preallocation and buffers.. and logic for dealing with hard disk overruns.. but they are kind of overwhelming to master right away. But it does a good job from what I can see.


The Internals of VLC and How it works

VLC or VideoLAN client, retconned to just VLC.

It is (or was) planned as a media player in a suite of tools for sharing audio video media files from a Satellite downlink on a University campus in France.

It was a student led effort that evolved and led to it being open sourced in the year 2000.

Because not all students used a Mac or a PC or Linux desktop they chose to design it such that it was portable across all those platforms. It has since been ported to iOS and Android as well.

Basically the terminology changes depending on which era of programming, or desktop PC platorm your currently on but its a collection of 'mini" programs called "Modules" linked together in a chain by a "Core" interface being used.

Its mostly a "loader" with a user interface stuck on the front.

The Interface can be a command line string of commands like in a command processor script, or it can be a GUI user interface for a windowing system like wxWidgets, or Qt or Cocoa.

In the background however, once its started, its just making calls to load and start up "modules" and pass them commands parsed from the user instructions to configure them.

Its very similar to the way a GraphEdit Graph works in DirectShow to load "filters" but it does not use "filters" to achieve its goals. People often assume it should expose a filter graph using the graph builder interface on Windows.. but it does not. Instead all of its functions are handled by a series of monolithic "modules" which accept commands from their own type of user interfaces.

So basically VLC was not designed "only for Windows" and does not adopt the DirectShow method of creating filter graphs for performing its functions.

At its center VLC is a ("muxer") which means it takes audio and video streams in, performs some things on them and blends them together and then shoves them out in a new format. While its doing that it can also split off a duplicate stream and "Display" what is currently going through the stream.

Initially it was intended to accept UDP and TCP streams, later reading a DVD device or .ISO file were added, then taking in the Output from a Capture device or a TV Tuner.. these were all added one at a time.. to bring it where it is today.

Just like splitting off the Display duplicate stream, the Record button on the advanced User interface can direct a duplicate stream of the Input data straight to a file, which is automatically named and stored in a pre-configured directory for videos. No processing is performed on a Stream "Capture" as a Record file.. which is rather the exception than the rule with VLC.. and a default Capture/Record processing cannot be configured from the GUI interface.

Separate from a ["Capture/Record"] is a ["Capture/Convert" or "Save"].

Using the "Convert"  button instead of "Play" (which "Play" starts a stream already configured and stored in the Playlist, or completes the process of adding a stream to the stream list and then starts playing it) spawns a Wizard for configuring an Input and selecting a predefined "Profile" which will perform processing on a twin set of audio and video streams to mux them before sending them to a final directory and file destination.

Profiles are preconfigured as VLC default installed, but new ones can easily be created.

The same Convert "Wizard" can be used to complete a File, DVD, Network or Capture Card stream along with its mux processing profile.

The "Stream" button is basically the same thing but tailored more towards "re-streaming" as fast as possible .. possibly without "muxing"

The GUI user interface layers a conceptual way of looking at the the command line way of building up a 'filter graph' in DirectShow terminology even though.. it is not a DirectShow filter graph.. its basically the same thing. "Conceptually"

The VLC command line invocation does not replicate the GUI user interface, the GUI is task based oriented. Where the command line better represents the actual process of building up a single minded, single task process of configuring a input source, configuring the modules that will operate on those source with "VLC filters" and then multiplexing them into a single stream and delivering them to a file or other destination.

Because of the way VLC is built, and its core is libavc.. its sometimes desired to "use" VLC as a DirectShow "filter" itself.

Doing this is possible.

Sensorray opensourced a VideoLAN client bridge

The DirectShow filter appears as a Sink and is preconfigured to save a stream as a processed mux file, currently only as an MPEG1 or MPEG2 file.


Using VLC to Capture from Blackmagic Intensity Extreme on Windows XP

This took a while.

And I'm still not sure I totally understand it.

But to get a "Perfect" capture and Preview on Windows XP SP3 with Thunderbolt and a Blackmagic Intensity Extreme.

Here are the manual steps:

1. Open VLC

2. Go Tools > Preferences > Video 

3. Use the drop down for "Display ----- Output ----> [Windows GDI video output]"

The default "automatic" will produce a blocky chunky slow video window with multiple artifacts all over the place, so be sure to manually set the "Display Output method to Windows GDI video output"

4. Save

5. Media > Open Capture Device...

6. Video device name: Decklink Video Capture

7. Audio device name: Decklink Audio Capture

8. Video size: 720x486

9. Advanced options: check, Device properties


B. Play

C. First "popup" Properties > Video Format

D. Use the drop down for Video Format: (Scroll Up to pick the First: NTSC - 8 bit 4:2:2 YUV)

The default identical looking (NTSC - 8 bit 4:2:2 YUV) is an accidental abbreviation for NTSC "Progressive" which appears to be improperly rendered on Windows XP at the moment. The "Top" position in the list is actually the same "Interlaced" which takes less time for VLC to process and display.

VLC has its own internal software De-Interlacing options which appear to work without the long delay or lag of the Intensity Extreme "profile".. so I am uncertain what is going on.

Also the Blackmagic Control Panel applet is responsible for actually setting up the Intensity Extreme for input.. so it could be the pop up panel is confusing the DirectShow pin that feeds VLC and it may be mininterpreting the input as Progressive when it actually is not.. I do not know for sure.

For now.. just do it.

E. Apply: OK

F. Second "popup" Properties > Audio Format


It takes about 1 or 2 seconds for the window to launch, audio and video are "rock solid" and in-sync.

All  of this was figured out by trial and error.

Windows XP SP3

Blackmagic Intensity Extreme

HP Thunderbolt laptop

VLC Player 2.2.6 Umbrella

Pressing the [o] red dot "Record" button saves the currently viewing Preview as a Lossless .AVI file to:

C:\Documents and Settings\{my-username}\My Documents\My Videos

The videos are lossless, but the audio, video playback are very far out of sync.. and the file information reports a frame rate of 21.xx below 29.97

So I don't know if its a difference in format interpretation or dropped frames or samples.. or something else I do not understand.

Blackmagic went to a lot of trouble to not playback audio while capturing in Media Express and calls the process out as harmful to maintaining sync while capturing. VLC plays back audio while its capturing.. perhaps introducing a delay in the audio stream when writing to disk.

I am not entirely sure how to disable audio playback in VLC while capturing both audio and video. It could be a challenge.

VLC Preview however the audio and video are in lock step.


Enabling Blackmagic Intensity Extreme Input Monitoring on Preview on XP

On XP various sound chips may or may not have internal loopback circuitry to support monitoring the Mic Input.

This is important to understand because the Blackmagic Intensity Extreme device drivers do not appear to have an internal loopback for monitoring the Audio Inputs during capture and appear to pass-thru the audio and video to either the HDMI or the S-Video or Component Outputs.

For HDMI output the audio is embedded in the single connector.

For S-Video or Component outputs the audio is duplicated on the RCA output jacks.

I didn't run down the specific example with the chipset on my laptop, but more generally plugged in an M-Audio Sonic Theater sound card to the USB port and connected the RCA output jacks of the Intensity Extreme to the "Line Input" of the Sonic box and the Sonic box speaker outputs to a set of external speakers.

Routing the output through the Speakers was relatively easy and not much had to be setup, except the M-Audio control panel applet had to be used to "Enable Monitoring".

This sounds annoying.. but because Input Monitoring was not a "class supported" featured during the XP era, there was no "one way" of doing it for all chips. In Vista and 7 and beyond it was adopted as a class function and could be automated by visting the Input device "Listen" page to switch Input monitoring on.

Using an external "loopback" by using an external USB sound card.. was just a simpler.. more consistent work around that should work on all brands and model of PC.. since the M-Audio USB sound card has a "Monitoring" check box exposed in its Control panel.. and its portable.

Blackmagic Media Express "might" have a "monitoring" registry key.. but I haven't found it.. and judging from the old Blackmagic forums.. it probably doesn't exist.


422 Capture Blackmagic Intensity Extreme on XP using Thunderbolt

Not the easiest chain to put together.

But yes. There is a laptop brand and model with a Thunderbolt port, that fully supports Windows XP 32 bit.

And a BlackMagic Designs Intensity Extreme (Thunderbolt) with a version of Desktop Video and Media Express which works on Windows XP and installs a 32 bit device driver in XP for Audio and Video capture on Windows XP.

This kind of gives me "ideas" about how to create an Auxilary "Crossbar Control" that is independent of the DirecShow device drivers.. but can also help toggle bits that the normal DirectShow Control Panels do not. Pinnacle "Marvin" device usb-500, usb-700, usb-510, usb-710 come  to mind.

The old ATI TV Wonder 2.0N also is a possibility. USBSnoopy and USBRobot can bring over the 32 bit device driver to the 64 bit space, but then the DirectShow model doesn't fit. I'm not sure of the entire path.. but it gives me ideas.

In any event, the Intensity Extreme (Thunderbolt) under XP works.

However.. like all other platforms, to get it working you must first visit the Control Panel and use the BlackMagic Control Applet to manually set the Input and Signal format. (Not through the DirectShow device driver control panels.. they do not work!)

Windows Movie Maker 2.1 does not seem to have a problem using the Intensity Extreme after its setup. But there is some Audio device strangeness. It can record Video, it can't record Audio and it can't make clips after the capture. - So effectively only  BM Media Express can create .avi capture files with both audio and video captures.. which is very good.

 I only tested Component and S-Video inputs, and with a good signal, they are on par with one another. Crisp solid and invariant. 

I also tested with VirtualDub 1.9.11 - 32 bit, it works flawlessly. Captures audio and video.