Go Back    Forum > Digital Video > Video Project Help > Capture, Record, Transfer

Reply
 
LinkBack Thread Tools
  #1  
02-28-2020, 03:44 AM
jwillis84 jwillis84 is offline
Free Member
 
Join Date: Aug 2017
Location: College Station, TX
Posts: 800
Thanked 217 Times in 174 Posts
Hello,

Some might be interested to see and learn a little more about the effects of "Head Switching" and "Top Curl" in a video signal coming from a VCR, and how at least Analog Devices dealt with it in 2012.

This Application Note is well written, and includes diagrams and photographs of the effects discussed.

Analog made Standard Definition decoder chips way back in 2012.

APPLICATION NOTE AN-850 "Adaptive Digital Line Length Tracking"


The photographs of before and after are taken of a crossbar monitor which deliberately focuses the monitor screen on the vertical and horizontal blanking intervals.

This was a diagnostic tool to check for video signal problems in the broadcast era.

The important part to pay attention to is the "Top Curl" in the before image, which we often call "Flagging" or "Tearing" at the top of a program being played back from a tape in a VCR.

The described technique that Analog uses to fix this problem solves two problems at once, it both compensates for horizontal sync pulse and variable line length problems. The horizontal sync pulse problems result in "Flagging" or "Tearing". The variable line length problems result in "swim lanes" or wavey verticals in the edges of things in the video that should be still and straight from top to bottom.

Line TBC generally refers to a TBC that can correct one or both of these problems at the same time and is built-into to some very high end VCRs.

Often the LTBC function is paired with DNR - "Digital Noise Reduction" or CNR - "Chroma Noise Reduction" or some combination of these with edge enhancements which cannot be independently separated. They are (all) either on or off. And even if you can turn them down the additional "filters" can continue to cause problems. Only certain JVC and Panasonic PAL VCRs reportedly "did" offer independently turning off and on of their LTBC or DNR separately.

I stumbled upon this while looking into CGMS-A, which broadcasters often turned on accidentally causing some DVRs to soft encrypt their recordings to prevent multiple copy generations from a single broadcast recording. CGMS-A could also go "unnoticed" from the source material at the studio that produced the content and be unwittingly broadcast without the television stations knowledge because it was embedded into vertical blanking intervals for the analog signal. The intent of the rights holders didn't actually go into whether it was appropriate or not.. they just tended to "turn it on for everything" if even some content they produced happen to require it.. they flipped a switch and left it permanently "on"

Analog devices decoder chips that included this LTBC equivalent (called "ADLLT") also included the "ability" to turn on CGMS-A detection ...

However it was not turned on by default.

As a result of that, some devices that used Analog Devices decoders chips appeared to "Ignore" the CGMS-A signal "accidentally" but could pass on the signal unwittingly. This also occurred in at least two Japanese USB NEC and Fujitsu video capture devices.. which seemed to be an open secret in Japanese blogs around 2012.

Long story.. but I recommend reading the Application Note PDF below. Its a short read, somewhat technical but not overly so.

NOTE: This is all about "Line" TBC correction. A "Partial or Full Frame" TBC does more and costs more, it is typically not built-into an internal device due to its circuits size and complexity. Its usually a standalone device, which caches entire fields or frames at one time and "compensates" if the problems with a video signal result in an incomplete field or frame. Rather than drop out and confuse downstream capture devices, it merely sends a duplicate frame of the last thing it has a complete copy of in order to maintain synchronicity of the video information with the audio information. This results in a less disruptive picture and less audio that gets ahead or or behind the video currently being captured.

In effect it "manufactures" frames as "filler" and never lets the video train of images stop.

If the train does stop many capture devices will "abort" their capture, or react badly to the garbled partial frames that they do get.. mistaking sync signals for color burst and transitioning into psychedelic mauve and green color spectacles or "plan 9 from outer space" B&W specials.


Reply With Quote
Someday, 12:01 PM
admin's Avatar
Ads / Sponsors
 
Join Date: ∞
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #2  
02-28-2020, 04:09 AM
lordsmurf's Avatar
lordsmurf lordsmurf is online now
Site Staff | Video
 
Join Date: Dec 2002
Posts: 13,510
Thanked 2,449 Times in 2,081 Posts
Ah-ha, I knew it!

The question for me is this: which chips passed it?

Did the cable box ignore the CGMS-A?
That Philips DVD recorder is a known offender. Which chips caused it, or fail to ignore it?
By contrast, the RCA recorder (Zoran chipped) pays no attention to it.

The Grex does well to remove CGMS-A, but fails at everything else (Macrovision has fubar luma levels, it's not a TBC replacement at all).

BTW, varied line length is also responsible for "jitter" (layman term, not technical jitter) aka image jumping/bouncing/vibrating.

Nice stumble-upon, good info.

- Did my advice help you? Then become a Premium Member and support this site.
- For sale in the marketplace: TBCs, workflows, capture cards, VCRs
Reply With Quote
  #3  
02-28-2020, 11:30 AM
jwillis84 jwillis84 is offline
Free Member
 
Join Date: Aug 2017
Location: College Station, TX
Posts: 800
Thanked 217 Times in 174 Posts
The App Note was on the subject of LTBC and the accidental additional information was about CGMS-A in the same chips that had ADLLT.

I have not completed my research into CGMS-A or how that correlates with specific chips and STB or recorders.

Its a big topic (CGMS-A) it appears to have been rolled out rather clumsily and casually by the content producers themselves. Patents were filed that say its based on two bits in the Vertical Blanking field that have 8 combinations or "settings" with different behaviors and meanings the decoder chips and recorders could interpret. Only about 4 settings were ever used.

Macrovision or (old school 1980, 1990s) "Copy Guard" got lots of names over its lifespan. Grex (I think) only removed Copy Guard and it was an "analog" pulse train rather than a digital "bit system" like CGMS-A.

Macrovision is typical for analog reproduction systems like VHS or Betamax, where CGMS-A was used for DVD, Blu-ray and later got an upgrade to CGMS-D ("digital") when streaming or digital streams started appearing because Macrovision could not work in MPEG-TS or MPEG-PS.

Any or all of these can be embedded in late content types, and observing or enforcing them and their many settings is up to the end playback product used.. even if its just a computer program like VLC.

It looks like all of it "mostly" collapsed under its own weight and complexity.. no one could keep up with all the changes and history, DeCSS or basic "encryption" took over after everyone (content producers) and (playback hardware makers) and (customers) either stopped using it, sought ways to disarm it, or otherwise simply legitimately, play back the content they rented or purchased.

All this ancient history content protection is laying in wait like buried mines in content.. and the disarm equipment or software is disappearing.

The Philips appears to have been trying very diligently to flag and soft encrypt the CGMS-A content, they took the unusual "extra" step of lightly encrypting the content even on the media they stored it on.

IO data in Japan made a line of products that used Analog Digital chips which by default did not detect CGMS-A but could turn it on so that Power Director software could produce CGMS-A compliant DVD recordings (once) for broadcast videos and then lock the media on a PC hard disk by encrypting it so that it could not be burned again.

There was a lot of "good intent".. but content producers seemed back then to get so confused they simply didn't care in the end and flipped a bit or stopped using it altogether. The entire chain of custody was "foobar".

In our current era of binge watching and disposable media consumption these old ways of protecting content seem mostly forgotten. The signals still exist in old media.. but its a lost age of information and even the history about it is disappearing except for brief wikipedia articles.. or chip makers app notes.
Reply With Quote
  #4  
02-28-2020, 11:58 AM
latreche34 latreche34 is offline
Free Member
 
Join Date: Dec 2015
Location: USA
Posts: 3,257
Thanked 537 Times in 497 Posts
BlackMagic Analog to SDI mini converter have the Analog Devices ADC chip inside, Whether it is the right chip or not or the feature is enabled or not that remains to be seen, The one I have seem to either be defective or I couldn't pair it with my SDI to USB adapter, I was able to successfully update its firmware via the mini USB port though. I don't have a SDI display yet, I will be getting one for testing purposes:








Attached Images
File Type: jpg 810bR8B5wRL._SL1500_.jpg (70.3 KB, 111 downloads)
File Type: jpg IMG_0733.jpg (120.3 KB, 111 downloads)
File Type: jpg IMG_0735.jpg (132.2 KB, 111 downloads)
Reply With Quote
  #5  
02-28-2020, 12:27 PM
hodgey hodgey is offline
Free Member
 
Join Date: Dec 2017
Location: Norway
Posts: 1,680
Thanked 447 Times in 384 Posts
Quote:
Only certain JVC and Panasonic PAL VCRs reportedly "did" offer independently turning off and on of their LTBC or DNR separately.
DNR is not a requirement for the TBC function, though JVC (and seemingly Panasonic) did bunch them together. TBC and DNR both require storing of some amount of previous video data, and it makes sense to use the memory for both functions.

For example, the NV-HS1000 doesn't feature digital noise reduction (only analog like most VCRs have) at all, the A/D conversion is only used for time-based correction. The TBC in this VCR is a separate PCB, so it makes it quite clear what hardware is involved in the process if you look at the scematic: panasonic_nv-hs1000b.pdf. Also recently came across the docs for a memory chip
You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.
that describes it can be used for TBC operation. These more primitive TBCs can't store a lot of video data in memory, and seem to do the squeezing/expanding of lines by adjusting the output clock on the final D/A converter. In the NV-HS1000 circuit you can see a separate chip that does horizontal sync replacement.

The manual linked in this post has a brief description of the digital circuitry in the JVC HR-Sx500 VCRs, they altered it a little in the later models.

The functionality in the ADV chips (and similar offerings) has a bit more processing power and memory to work with so they may be able to do a bit more than the in-VCR TBC.

Quote:
Originally Posted by lordsmurf View Post
Ah-ha, I knew it!
That Philips DVD recorder is a known offender. Which chips caused it, or fail to ignore it?
.
Which model? I can't remember ever seeing ADV chips in DVD-Recorder service manuals, they seem to be common in AV receivers though.

Philips DVDrs seems to commonly have used NXP A/D chips together with various different system chips. Not so surprising since what is NXP was a division of Philips that was sold off at some point, not sure if they are related again now.

EDIT: Not sure what happened with the HM63021 link, alternative here: http://datasheet.buhieen.net/HM63021.pdf


Reply With Quote
  #6  
02-28-2020, 02:01 PM
jwillis84 jwillis84 is offline
Free Member
 
Join Date: Aug 2017
Location: College Station, TX
Posts: 800
Thanked 217 Times in 174 Posts
Not to get too specific, but..

latreche34 that is one of the ADV chips with the CGMS-A detection circuit if I recall correctly

but having the circuit and using it are two different things

the firmware or device driver software has to decide what to do with that information

the capture device I ran across were only available in Japan for the D1 and D4 capture formats, they also happen to have S-Video and composite inputs in addition to their "D" format inputs.. which were essentially YUV Component inputs in North America.

(also my recollection) BMD was rather lax.. or on the "minimalist" side of compliance when writing their firmware. I always assumed adding code to turn something on, risked more bugs and increasing the time to market.. so they tended to not implement it.. and slapped warning labels on everything that said (don't misuse this for copyright infringement)

since ADV was an "opt-in" implementation, not "opt-out" they tended to pass CP signals straight thru to the next device in the chain.. ignoring whether they should pay attention to Macrovision, CGMS-A/D or HDCP.. the next device in the chain might respond appropriately but BMD devices tend to not do that.. not exactly advocating for their use.. but just explaining how a confluence of ADV not making the option default to "block" and leaving it up to the users of the chip to do something (or not).

So putting an ADV chip in a BMD design device represents a perfect storm (or probability) that device will ignore CP signals.. but pass them through

I don't know what the Philips 3575 uses for a decoder. I have not looked, NXP was quite late in the game, but they did produce their own decoder..(before they produced their own decoder chip, they used other makers decoders) but I don't know if they were opt-in or opt-out. Looking at the behavior of the device it doesn't matter much since they obviously blocked, whether that was a chip default, or they did the right thing in their DVR recorder software.. the end result is the same. The 3575 is known to detect and then encrypt those recordings with CP flags.

there are "test" or broadcast proc-amps, like the PRS-970 which allow "knocking out" specific vertical blanking interval "lines" with a series of dip switches on the front panel.. but they are BNC composite proc amps

the only problem with these is they also take out "close captioning" which (I think) cohabitates on the same VBI line as the CGMS-A or other CP flags. For people with hearing problems this is a major issue.

its a vast problem space

remediating rogue CP signals that are inappropriately used for public material could take up a lifetime

i'm mostly just interested in the history and how it works

Last edited by jwillis84; 02-28-2020 at 02:12 PM.
Reply With Quote
  #7  
02-28-2020, 02:08 PM
lordsmurf's Avatar
lordsmurf lordsmurf is online now
Site Staff | Video
 
Join Date: Dec 2002
Posts: 13,510
Thanked 2,449 Times in 2,081 Posts
Quote:
Originally Posted by hodgey View Post
Which model? I can't remember ever seeing ADV chips in DVD-Recorder service manuals, they seem to be common in AV receivers though.
Philips DVDrs seems to commonly have used NXP A/D chips together with various different system chips. Not so surprising since what is NXP was a division of Philips that was sold off at some point, not sure if they are related again now.
Philips DVDR3575H/37. (And probably also the 3576.)

Quote:
Originally Posted by jwillis84 View Post
The 3575 is known to detect and then encrypt those recordings with CP flags.
And it includes flags that the cable provider doesn't know exists (and specifically claims does not exist). The issue now becomes "unencrypting" (likely just de-obfuscating) the recordings. What a mess.

- Did my advice help you? Then become a Premium Member and support this site.
- For sale in the marketplace: TBCs, workflows, capture cards, VCRs
Reply With Quote
  #8  
02-28-2020, 02:18 PM
hodgey hodgey is offline
Free Member
 
Join Date: Dec 2017
Location: Norway
Posts: 1,680
Thanked 447 Times in 384 Posts
The 3575 (and related models) seems to be using a SAA7136 (don't know if it's NXP or Philips branded) A/D chip and a pnx7350e (may be Philips but not sure) system chip.

From what I can gather, various SAAxxxx video chips were made by philips at first, but the technology has been under Trident and then NXP later, I don't know the full relationship between all of them but there have been video chips with branding from all of them at various times, but currently they're under NXP. I don't know when Philips first started making video chips, but they've been around for a while.
Reply With Quote
  #9  
02-28-2020, 02:30 PM
jwillis84 jwillis84 is offline
Free Member
 
Join Date: Aug 2017
Location: College Station, TX
Posts: 800
Thanked 217 Times in 174 Posts
Quote:
Originally Posted by lordsmurf View Post
What a mess.

.. for sure

But have to understand it before can do that.
Reply With Quote
  #10  
02-28-2020, 10:11 PM
jjdd jjdd is offline
Free Member
 
Join Date: Jul 2012
Posts: 159
Thanked 15 Times in 15 Posts
i did see that Aja IO HD did have many Analog Devices chips inside but i did not see any ADLLT mark on them
ADV7842 maybe have that future i know my Aja IO HD donīt care about Macrovision or i mean i have not yet play any retail tape that did not work on Aja IO HD

https://ez.analog.com/video/f/q-a/10...tearing/324973

maybe ADV7403 have it to

https://www.analog.com/media/en/tech...ts/ADV7403.pdf

-- merged --

from VH
maybe pointless info

Quote:
This is my first quick intro to my capture setup. If there's enough interest and it survives sharp shooting from the crowd here, I'm tempted to do a more thorough run of documentation. Lossless VHS captures (ffv1/flac) and compressed post processed (h264/aac: IVTC, crop, resize, normalize audio) captures are attached.

What do you think of the quality? Is there a test or benchmark tape out there you’d like me to test my setup against? Anyone have a tough tape they’d like me take a crack at?

Equipment:
JVC HR-S2902U ($59.95)
Sony Handycam CCD-TRV85 ($49.99)
EVAL-ADV7842-7511P ($216.41)
AJA KONA LHi ($119.00)

Signal flow is VHS/Hi8 (TBC/DNR disabled, edit mode) -> EVAL-ADV7842-7511P (Line and Full frame TBC enabled, 10-bit 422 out) -> AJA KONA LHi (lossless) -> ffmpeg archival and display copies

I've experimented with:
AJA KONA LHi (ADV7403) direct - solid captures unless there's non-standard signal, appears to use line TBC-like functionality BlackMagic Pro Capture 4k (ADV7180) - garbage, could not capture more than a few frames at a time, poor quality Magewell Pro Capture HDMI (ADV7842) - very good performance! appears to use line and frame TBCs, however captures seemed 'washed out' or had bad default levels, 10-bit 444 capture wasn't real. For one and done 8-bit (HD is just extra), I'd pick this. Must disable default deinterlace.

BlackMagic Decklink Studio 4k (ADV7842) - while having the fancy ADV7842, the latest firmware/drivers clipped outside of broadcast levels and support hasn't fixed it in years, randomly drops a handful of frames with no explanation

Since TBCs are historically a point of friction. If you believe the marketing:

"The ADV7842 implements a patented Adaptive Digital Line Length Tracking (ADLLT™) algorithm to track varying video line lengths from sources such as a VCR. ADLLT enables the ADV7842 to track and decode poor quality video sources (such as VCRs) and noisy sources (such as tuner outputs, VCR players, and camcorders). Frame TBC ensures stable clock synchronization between the decoder and the downstream devices."
https://www.analog.com/media/en/tech...ts/ADV7842.pdf
https://www.analog.com/media/en/tech...7357AN_850.pdf
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
FS: JVC HR-S9600EU in excellent condition [SOLD] juhok Marketplace 4 05-28-2015 02:54 AM
NOTE: Ask your questions in the above sub-forums. Thanks. admin Video Project Help 0 01-01-2011 10:42 PM
Quick Note: Ads Concepts, AdSense + intrusive ads admin Web Development, Design 1 06-17-2010 11:50 PM
DVDWS2 - important note - prevent fuzzy menus lordsmurf Author, Make Menus, Slideshows, Burn 1 12-15-2007 05:08 AM

Thread Tools



 
All times are GMT -5. The time now is 08:59 AM