Frame sync TBC test.

[Gary34]

I’m just wondering what you guy’s think of this. https://www.reddit.com/r/VIDEOENGINEERING/s/AEOM2ZRWX1

[lordsmurf]

"Free software for testing" is already nonsense. Software = zero use. TBC is for hard(ware) analog errors.

AI slop. At least he admits it.

But there is something interesting here...

We still do not have content-aware software TBC. Hmmm... possibilities...

[dellsam34]

How do you suppose to check a TBC before purchase? The seller is going to send it to you for free test it with the software and then pay if it passes the "TBT" test? This is just a money grab.

[pandy]

"Free software for testing" is already nonsense. Software = zero use. TBC is for hard(ware) analog errors.

If you can capture RAW video signal then you can do TBC purely in software - it doesn't need to be real time if you can process RAW video offline.

After checking github this looks to me like NTSC signal generator with injected common VR issues and it is tailored to TEST real TBC .

[lordsmurf]

u can capture RAW video signal then you can do TBC purely in software - .

No, I refer to already-captured footage.

And the whole "raw signal" is nonsense. Nothing is raw, it's all modulated, reliant on hardware (decks).

[pandy]

u can capture RAW video signal then you can do TBC purely in software - .

No, I refer to already-captured footage.

And i refer to TBC principle - you can implement TBC in software and there is no sense to apply TBC to already captured footage as it is already affected by signal distortions - TBC works only if it precede video capture.

And the whole "raw signal" is nonsense. Nothing is raw, it's all modulated, reliant on hardware (decks).

You see video signal only as active video part, for me video (RAW) signal is also parts normally invisible to person working with active video - VBI areas as particularly those VBI signals are important for proper work of TBC - from your perspective chrominance subcarrier is nonsense and from mine it is important timing reference (as it is well defined in time, level and frequency so capture device is able to properly acquire and decode video signal)...

[lordsmurf]

VBI signals are important

Yeah, great. Most captures don't have that.

For decades now, "software TBC" has referred to as something that applies to after-the-fact (already captured) footage.
It's a unicorn.

[pandy]

VBI signals are important

Yeah, great. Most captures don't have that.

For decades now, "software TBC" has referred to as something that applies to after-the-fact (already captured) footage.
It's a unicorn.

That's why i pointed - video RAW signal including VBI i.e. unprocessed video - this is base where software TBC may work exactly like pure HW TBC. Brooktree/Conexant chipset (848 and other) make possible to capture video with VBI so you can implement TBC in software, you can use one of commonly available acquisition devices and as such process RAW video in software.

Free software for commonly available cheap ESP32 boards is used to create source of stimulus - video signal (only NTSC) with intentionally injected distortions - such signal is used to verify physical TBC - results are compared in two channel DSO so it can be objectively verified and as such verify real, physical TBC.

[aramkolt]

I like the idea of it - various corrupt signals that would confuse some TBCs generated by an inexpensive ESP32. What I don't like is needing to use the command line and needing an AD2230 to analyze the results.

I messaged the developer with what I'd change, namely:

1. No use of the command line - have the device output a good composite signal by default and use a physical button using unused IO on the ESP32 to trigger the test sequence. You'd then capture the output with a basic video capture card. For the test to be standardized, you'd probably want to choose a widely available capture card that doesn't have any stabilizing effects of its' own and doesn't have multiple hardware revisions.
2. Each frame of the test should have a visible time code or frame number "burnt in" that could then be looked at later to cross reference what that frame is actually testing. The visible time code would also tell you after the fact which frames were lost or duplicated during the test.
3. Didn't mention this, but I'm sure the ESP32 could also output LTC audio that would give an idea of processing delay and this could optionally be looked at later.

This is not at all as accurate as the original concept where the samples are then analyzed and measured compared to the source with a digital oscilloscope that reports back to a computer, but we already know what the source is supposed to look like and most people care more about the visual result than numbers. Does it look stable? Are the lines well aligned horizontally? Are there dropped frames?

I presume that a companion drag and drop software could be made to analyze the resulting captured video file if you wanted to get into things like hue differences and specific measures compared to a "reference" device that is known to produce ideal results using the same test.

[pandy]

I like the idea of it - various corrupt signals that would confuse some TBCs generated by an inexpensive ESP32. What I don't like is needing to use the command line and needing an AD2230 to analyze the results.

You need to capture video - two streams original and after TBC, let say you can perform acquisition in two steps but still you are dealing with real video signal so you need to have sufficiently fast analog to digital conversion - there is many possibilities but author probably own AD2230 so he focus on this device.

I understand that his goal is to provide some objective way of TBC quality assessment so no longer TBC are subjectively verified - also this can help in cutting all this advertisement crap where everyone claims to perform TBC but in real life this is way far from truth.