This is more of a curiosity than anything that might affect actual captures.

Several days ago I asked if my capture system had AGC in the thread "Is this an example of AGC changing levels?". I had experienced automatic level shifting while paused on an image that was over the brightness 235 upper limit. The shifting brought the over exposed limit to well within the 235 limit. Some times it occurred other times it did not. Today I found that whether it happened or not was based on which capture device I used.

Today, I ran into the automatic level shifting again so I went back to my engineering roots and figured out where the change is coming from one step at a time. The starting workflow included: Mitsubishi HD-2000U vcr --> Panasonic ES15 --> Diamond VC500 capture device --> Windows 7 Pro with VirtualDub 1.9.11. I used S-video for all connections.

Step 1: Eliminated the ES15. Automatic level shifting still occurred.

Step 2: I suspected the vcr because Sanlyn said the VC500 did not have AGC. I went through all four combinations of turning on and off the 3D-Y/C and DNR+TBC features. Level shifting still occurred.

Step 3: I now suspected the VC500. I moved the video connection to my Hauppauge 2250 capture device. Surprise! The auto level shifting did not occur while paused on an image. I ran the same combinations of the vcr 3D-Y/C and DNR+TBC features and the level shift did not reappear. I also tried different paused images that were out of bounds.

With the VC500, the right end of the histogram moved left in small increments once a second until the level was well within the 235 boundary. The VC500 only affected the white level. I tried images with blacks below the lower limit and no automatic change occurred.

I ran further tests to determine if this action affects video that is running versus paused. While paused, I stepped the video forward and back a frame at a time to see if the adjusted level reset or stayed the same. The adjusted level stayed in place. However, hitting the play button always put the levels back to where they were with the overly bright scenes going past 235.

A few days ago I thought consistently over bright scenes would cause the level to change automatically so I ran some overly bright scenes. I didn't see any change. Either the level shift does not occur during play or the shift is so slow I couldn't see it.

CONCLUSION: I think the level shift during pause is a VC500 protection feature to prevent CRT and plasma based displays from burning in.

The following images are from my prior post and show the amount of shift over about 20 seconds while paused on one frame.

Attachment 8823

about 20 seconds later:

Attachment 8824

Update: A family vhs video that has considerable over limit scenes did show the VC500 adjusting the upper end just like the paused video.

I'm not convinced about an AGC issue, but also won't rule it out.

I've really never been overly fond of that card, though several members of this site use it. (And I have ATI AIW systems for capture.) What I've seen on my card is that the levels are dark, and vary system to system. I don't like that one bit. I like something that can be easily repeatable. The AIW cards don't act like that, nor do ATI 600 USB in all but a few cases I've seen.

An interesting thread. :hmm:

I would very this myself if I had time for it.

I noticed this issue for the first time today. It was on a cartoon with Macrovision.

Previously I captured a live action title which doesn't have Macrovision to my knowledge. I double-checked it and the brightness did not visibly change like I saw with the cartoon. So maybe it's Macrovision that causes the levels to drift? I didn't see any mention of that in this thread or the other one.

AGC can mean any things, like TBC people tend to interpret the meaning "a bit".

Its basically a way to prevent peaking or crushing blacks.. but how that is achieved can vary. It can also be performed by an analog circuit or in the digital domain both before and after digitization.

One issue I've long suspected is that its wound up in an IRE problem.

Video signals in the United States "assume" a Pedestal setup.. or a front porch level shift upwards to separate the horizontal sync pulse at the start of the each video line from the black level. This was an ancient compromise to keep the cost of televisions down in the 1950's so their sync separation circuits did not have to be that complex.

But in the rest of the world that used NTSC (like Japan) there is no Pedestal setup. Their IRE level starts at the same level as the sync pulse and is differentiated by time, not voltage. I (guess) that by the time (post-world war II) that television became common place in those locations analog circuitry had advanced enough that Pedestal setups were no longer necessary.. regardless the difference persisted 60 years later.

If you assume the IRE range starts at 0 (like most of the world) the dynamic range of the signal voltage will be "larger" than the window for the video capture device. And that will cause blown highlights and "peaking" that goes through the roof.. making other things downstream of the capture have to react. Typically we "turn down the brightness" to try and get it under control.. but that crushes the blacks.. essentially the capture window needs to be "compressed" to capture everything in proper proportions.. but we don't have such an instrument.. an IRE "compressor" or "compensator" standalone device doesn't exist. Broadcast format "transcoders" do exist.. but are very expensive and rare.

A video capture device that assume a US IRE will know to compress the range.. or compensate for the higher peak.. it will attenuate the video signal in just the right way such that broadcast standard video signal will not ram through the ceiling and blow the highlights.. so nothing downstream will have to compensate.. and we won't have to "do anything" to capture the entire video signal.

This phenomena won't happen on every line of video or every scene in a video playback.. it will only happen for certain "suddenly" bright scenes.. or scenes with lines of video that exceed the capture window for the video capture device.. which will cause something downstream to automatically "React" to dampen or "make darker" the out of range video signal.

ATI was a North American company, Canadian to be sure.. but they were fully invested in the US broadcast standards for IRE with Pedestal setup.. they designed the Theater 100 (Rage) and Theater 200 video decoder and capture chips.. specifically for the Canadian and US markets.. so naturally they were least likely to ever experience this problem.

In the DVD recorder market its well known that Toshiba,RCA/ Philips/Thomson and Panasonic all had problems when they began importing their DVD recorders into the US and Canada exactly with the same IRE problem.. they had a very hard time it seems even understanding the problem.. even if the US was well aware of the problem. For the most part they simply suggested dialing out the problem in customer TVs.. which didn't go over well because then watching regular broadcasts, the programs would appear too dark or muddy. Its simply not something you can ignore with a level shift.. its a "range" problem as well.. the width of possible voltage levels is (too) large for the video capture device.. and the level shift on the inputs is already "stepped up" which rams the highlights into the ceiling of the capture device.

So the VC500 is "made in China" which uses IRE "0".. its no wonder it has this problem.. as well as any made in Europe.. the Middle East.. or anywhere other than Canada or North America.

The ATI 600 uses a chip made by a company in the US, Texas Instruments (tvp5150) and they are "Very very" aware of the IRE problem.. its covered in detail in the tvp5150 databook.

A very few Euro made video capture dongles and cards do use the tvp5150.. but its not something printed on the outside of the box.. so there are some dongles that do not have the problem.

I am not sure of the micronas, connexant and other video decoder / digitizers.. but to a degree if they have the ability to compensate for IRE differences.. it also needs to be used by the device driver software writers.. aka.. they have to tell the chip to "switch that feature on".. so even if the chip were a tvp5150.. if the device driver is written in China.. its unlikely they were aware of the problem, what the IRE feature is for.. or had a way of testing it.. since all of their local broadcasts and sources will be IRE "0".

What I am not sure of with the ATI 550, 600, 650, 700, 750 chips was if ATI "Went wrong" or if its a continuation of the basic IRE problem. Some of those chips were "MPEG2 hardware encoders" and some "were not". Contrary to the rest of the world that went to DiVX and other types of compression .. ATI stuck with MPEG2 longer than most.. and specifically DVD compatible MPEG2 formats.. which.. assume IRE 0.. so on playback the video levels may or may not be in the proper IRE format.. and could interact with how those signals are interpreted by playback software.

"Capturing Uncompressed" I would assume they would be less likely to have these types of problems.. but those chips were designed for Windows Media Center or PowerDirector or other types of PVR capture software.. they were almost never used for Uncompressed capture.. you would probably be hard pressed outside of using DirectX9.0c and GraphEdit to come up with a video capture software that could use those chips in that manner (for Uncompressed capture).

Getting IRE "right" is not easy.. JVC made it a "major" marketing issue with all of their Professional gear ("We get IRE right!") but most lower end, less costly gear .. gets it more often wrong than right.

I've long wondered if the PAL users of these have any issue at all with IRE.. since I believe PAL doesn't have an IRE setup.. its simply IRE 0

You can play around with histogram to "center" the capture window you have.. but you can't shrink the range of the signal, or expand it as the case maybe.. you have brightness and contrast.. not "width" of the range.. so you have to "pick" a compromise.. and then when those levels are exceeded something downstream will react.. (to me) that is where AGC gets involved.

AGC is supposed to reduce the brightness when the level is exceeded for too long a time.. and this "automatically" darkens the entire scene for a period of time.. "pulsing" the scene. And it happens with regularity unless you permanently reduce the brightness to unacceptably low levels. Normally a broadcast signal does not trigger an AGC to "overreact" in this manner.. but an improper IRE will be pushing it quite often.. more so than normal because either a human will brighten the levels to compensate for an IRE of 0 or some other circuit will adjust it upwards.. but the range will not be shrunk.. so the top of the range will be bumping up against the AGC threshold and begin overreacting.

An ATI T200 or TI tvp5150 will "know" to expect an IRE of 7.5 and will automatically "shrink" the range of the signal to fit the window of the video capture Analog to Digital converters and their AGC controls will not overreact.

.. you might ask whats wrong with darkening the picture permanently and recording that way with crushed blacks and then raising them after the capture.. but you've lost information.. effectively you've accepted capturing the range at a lower bit resolution and therefore lost contrast detail. So a proper range capture means a sharper picture with no pulsing and a simpler setup..

Macrovision affecting gain sounds plausible, I believe the stripes are at max brightness so it could cause the decoder to compensate adjust a little compared to a video signal with no MV and less white peaking. There will always be some degree of gain control as the decoder will have to adjust for varying voltage levels for the sync signals, though I guess different decoders and drivers will handle it differently.

So just adjusting contrast in the capture device doesn't work properly?

As for PAL IRE, I haven't used DVD-Recorders for recording stuff off analog TV, but on the ones I've tinkered with for VHS usage it seems some tend to blow out bright spots, especially Panasonic ones (which bogilein here has also noted.) For most tapes I have to manually reduce the signal level to avoid clipping brights if using my ES10 or EH57. My JVC DR-M100 (it actually has a TVP5150 + LSI chipset) seems to also clip a little, but to a much lesser degree, on my Sony and Pioneer rarely an issue. The NEC-based ones like the Sony and Pioneer models I have (+ other newer sonys and pioneers, older toshibas) actually have level adjustments in the options which help reduce the issue. Don't know why other vendors didn't add functionality for that. Haven't noticed any issues with capture having unavoidable crushing or blowing out stuff.

Conexant was an american company, their video decoding lineup was aquired from brooktree, another american company.

Philips and NXP are dutch, don't know where they designed their video decoder chips, though they seemed to have been used a fair bit in pro/broadcast gear so I guess they may have got the IRE somewhat right.

Metaleonid posted samples demonstrating the VC500's AGC effect on real footage in 2017: http://www.digitalfaq.com/forum/vide...html#post48320

His source was LaserDisc, which can't contain Macrovision.

I feel the need to repeat my stance on this card: I don't like the VC500. :2cents:

Neither do I.

The Cypress CMD-1500 TBC that I ordered from LordSmurf just arrived. In the untouched screenshots below you can see how the opening image is darker and the ending image is lighter without the TBC, and the brightness is more consistent with the TBC. (I didn't try to match the capture card's brightness and contrast settings, but you can see how the brightness drifted without the TBC.) Also, the TBC unexpectedly cleared up a red/green horizontal banding issue.

So it looks like Macrovision is screwing up the brightness.

The screen time between the two images is about 7-8 minutes.

Opening image without TBC:
Attachment 10784

Opening image with TBC:
Attachment 10785

Ending image without TBC:
Attachment 10786

Ending image with TBC:
Attachment 10787