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.

[jordancrombie]

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.

So Im the guy....If you are sourcing from FBM, Karrot, CL...that kinda try before you buy. I grant you, if you are just getting them off EBay...try before you buy isn't gonna work. Admittedly my perspective is informed by where I live (Major City)

That said, even on Ebay good sellers do offer returns. It is not try before you buy granted, but maybe it helps you know if you got a lemon.

As for the money grab...its free software. Unless you are insinuating I am in fact Teo Swee Ann CEO of Espressif, and this is just an elaborate ploy to make people purchase old stock ESP32s...in which case...dude...you got me.

[jordancrombie]

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.

The guy again...and thanks for reaching out dude...

As for a GUI...maybe? If people are into it and find it helpful, a GUI isn't beyond the realm of possibility.
To be clear...it's designed (right now) to require a Software Defined scope (ADP2230 is what its built around, but anything with two inputs should work).

That said, if anyone wants to create PR, or even Fork it...got for it.

I do get your point about more visual cues for the user. The idea thus far is that is basically an automated suite...fire it off it takes about 13 min per field test run, and it gives you the report.

That said, I totally understand how it could be helpful for average user. The challenge (at least now) is going to be input signal is woven into the test (and designed to work within the ESP limits of memory). I suppose it could be updated to allow the firmware on the ESP to not be load once..but upload new blobs...not my use case, but get it for sure. Worth thinking about anyway

What isn't in the docs (though I should add it) is the sample reports & fingerprints (tried to attached here). The hope (if there is one) is maybe the fingerprints/reports could be shared in some way...to help people understand how their units are performing (or about to die like my ES10)

To be clear dudes....this is hobby thing. The idea is to just create something that isn't so subjective...and provide some real data to compare. Its buggy AI Slop (trying) to do something specific I needed (and maybe could be helpful for others).

Cheers dudes...

[jordancrombie]

"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...

ESP Generates Known Analog Signal (Reference)...ADP Captures it Before it goes in...ADP Captures it after it goes in. Compare.
You understand how the TBC handles certain conditions (late fields, out of spec). These are analogs to the things a tape actually puts on the wire.