washed out colors from VGA to HDMI

[DiTBho]

So, I bought a VGA to HDMI adapter, and today I tried it. Colors are faded like when, after many cycles of your clothes in the washing machine you got colors washed out.

What can it be? And how to fix it?
The VGA cable is brand new.
The HDMI cable is brand new.
The VGA source has brilliant colors.
The VGA-to-HDMI adapter is a GANA 1080P Full HD.

Why life always is so complex?!? 

[DiTBho]

Googling ... this explains an interesting case, but it's not my case.

Attached to the HDMI there is a video grabber, and things work perfectly with HDMI-sources.

Don't  you know, guys, a well-known working VGA2HDMI? (supposing it's its fault)

[Nominal Animal]

Do you have full black-white intensity range?  Or is the HDMI output similar to when your RGB output was restricted to say 51-204 (20%-80%)?
If you have a scope, verifying the VGA color signals (pin pairs 1-6 for red, 2-7 for green, 3-8 for blue) are 0.7 Vpp, would be useful.

Have you opened the adapter yet? pics of the board?

[DiTBho]

Have you opened the adapter yet? pics of the board?

does not open, there are no screws, the case is glued.
If it is faulty I will return it to Amazon, but I cannot return it if it is damaged.

I am tempted to buy a second adapter, but which model?
I'd like to have something with screws so I can open it without problems.

[DiTBho]

Do you have full black-white intensity range? 

To test this, I would have to create a black- # 00.00.00-to-white- # ff.ff.ff intensity image test on Gimp.
I will do it! Then we can compare the original image on Gimp with the captured image.

diff(original{R.G.B}, captured{R.G.B}) = ?!?

If you have a scope, verifying the VGA color signals (pin pairs 1-6 for red, 2-7 for green, 3-8 for blue) are 0.7 Vpp, would be useful.

Yup, but in this case: should I amplify the { R, G, B } signals with OAs?
Isn't there a VGA amplifiers?

Or is the HDMI output similar to when your RGB output was restricted to say 51-204 (20%-80%)?

umm, how to test this? 

I don't have here a device with native HDMI-out.
I could borrow an RPI, just to see if the problem is at the HDMI-side of the grabber rather than at the VGA-side of the VGA2HDMI

That's the best I can do here.

[Nominal Animal]

To test this, I would have to create a black- # 00.00.00-to-white- # ff.ff.ff intensity image test on Gimp.

Or use one of the well known "test pattern" images, as they're already designed for visual verification and tuning of displays/televisions.

Yup, but in this case: should I amplify the { R, G, B } signals with OAs?

I didn't think that far.  I always try to find the problem first, before worrying about how to fix it.  (The idea being that if I limit the solution space to the one I know I can fix beforehand, I'm unlikely to pinpoint the true problem.)

I don't have here a device with native HDMI-out.

Hmm, that's a problem, since the issue could also conceivably be in the (HDMI input of the) display and not the VGA2HDMI gadget.

[m k]

The screen has switched on the Technicolor compensation.

[jonovid]

The VGA-to-HDMI adapter is a GANA 1080P Full HD.

looks like the same case style of video adapter as sold as a no-name brand on AliEx   
them cheap video adapters all use the same plastic case.
HDMI-to-AV  RGB-to-HDMI VGA-to-AV  RGB-to-AV just to name a few.
the brand name is irrelevant . crack it open  and see what pcb and chips their are using? 

[DiTBho]

The screen has switched on the Technicolor compensation.

Can you explain? and is there a workaround? kind of compensating circuit or something?

[DiTBho]

crack it open and see what pcb and chips their are using?

I paid 20 euro for it, I am still not sure if to return it to Amazon or not,  I am still in time to return. So at the moment I won't crack it for inspection, maybe in the future if I will decide to keep it.

- - -

I am looking at the Startech VGA2HD2, which looks better on the paper. It's more expensive, on Amazon it's listed at 110 euro, I can find on a local store for 90 euro, but it's still 5X more expensive than the GANUA one.

Dunno 

I am going to test all the equipment separately, stage per stage, so

• (source) VGA --> VGA2HDMI --> HDMI-LCD, comparing the same image on the VGA screen and on the HDMI screen
• (source) HDMI -->VIDEO-Grabber, comparing the captured image with the original one

rather than

(source) VGA --> VGA2HDMI (stage1) --> HDMI-VIDEO-grabber(stage2) --> stream


(source) VGA: my old laptop has one VGA port
(source) HDMI: The Raspberry RPI has one/two HDMI ports

[DiTBho]

In the description of the Startech VGA2HD2, they mentions YPbPr and PC-VGA in the video source compatibility list. They recommend a shilded and short VGA cable.

[AndyBeez]

This may be of no help at all but, my monitor has a hidden factory mode that permits setting 'profiles' on the HDMI channels. There is a whole soup can of settings including picture brightness, contrast, gamma, R/G/B gain, R/G/B offset, pixel overscan, pixel dithering and something called HDMI RGB range. Which seems to squeeze colours from greyscale thru vibrant. Maybe there is an equivalent on your monitor which can compensate for the budget voodoo?

[DiTBho]

Maybe there is an equivalent on your monitor which can compensate for the budget voodoo?

Yes, my NEC LCD supports these settings, but ... on the final project the HDMI goes directly to the HDMI-video-grabber

Code: [Select]

                _________          _________
    |  VGA     |         |        |         |
SBC | -------> |         |        |         |
    |          |         |  HDMI  |  H.264  |  udp/ip
    |          | adapter | =====> | encoder | =======>
       audio   |         |        |         |
    /--------> |         |        |         |
    |          |_________|        |_________|
    |           VGAtoHDMI           Grabber
    |
comments
microphone
and here I can do nothing but post-processing color correction on { FinalCut, Premiere, DaVinci, ... }
But I would like to avoid doing it.

[bw2341]

So the VGA source is a single-board computer? Is it your own design or a commercially available product?

Is there a serial EEPROM on the SBC to present the EDID information? If not, I suspect that without an EDID EEPROM, the default values for video white and sync levels on the VGA to HDMI adapter do not match the output levels on the SBC.

If there are no user controls on the VGA to HDMI adapter to adjust for various input VGA levels, you will have to find a more expensive VGA to HDMI adapter with this feature.

To check if the VGA to HDMI adapter is defective, I would connect an older PC with a VGA output.

[DiTBho]

So the VGA source is a single-board computer? Is it your own design or a commercially available product?

The SBC is a commercial AMD Geode x86-PC in mini ITX form factor, running Linux.
I have also tried a common PC and a laptop with no progress, still washed out colors.

Is there a serial EEPROM on the SBC to present the EDID information?

Yes. But it didn't help.

I also tried with a RGBHV cable, a cable with only the { R, G, B, H, V, gnd } wires from the VGA-board adapter to the VGA2HDM, so without any additional EDID information over i2c, there was no difference in the results: washed out colors.

It sounds that ... either EDID is wrong or it's irrelevant (ignored)

If not, I suspect that without an EDID EEPROM, the default values for video white and sync levels on the VGA to HDMI adapter do not match the output levels on the SBC.

The SBC is a true miniPC with a common PC-AMI-bios. When it boots it's 640x480@50Hz, H and V sync work with a pixel clock frequency of ~25Mhz, which should be the minimal default choice.

640x480@60Hz, pixel clock 25.175 MHz -----> Industry standard

Then you boot Linux, the kernel reads what it's passed through boot command line, and accordingly sets the video card to 1024x768@60Hz, which OK, it has a different sync-polarity and the higher 65MHz pixel-clock, but it should be a common choice.

1024x768@60 Hz, pixel clock 65.0 MHz

I mean, I didn't use any weird or extreme configurations:

weird: 1024x768@43 Hz, pixel clock 44.9 MHz (*interlaced)
weird: 1024x768@70 Hz, pixel clock 75.0 MHz
weird: 1024x768@75 Hz, pixel clock 78.8 MHz
weird: 1024x768@85 Hz, pixel clock 94.5 MHz
weird: 1024x768@100 Hz, pixel clock 113.31 MHz
extreme: 1600x1200@60 Hz, pixel clock 162.0 MHz
extreme: 1600x1200@60 Hz pixel clock 162.0 MHz
extreme: 1600x1200@65 Hz pixel clock 175.5 MHz
extreme: 1600x1200@70 Hz pixel clock 189.0 MHz
extreme: 1600x1200@75 Hz pixel clock 202.5 MHz
extreme: 1600x1200@85 Hz pixel clock 229.5 MHz
extreme: 1600x1200@100 Hz, pixel clock 280.64 MHz
extreme: 1680x1050@60 Hz, pixel clock 147.14 MHz
extreme: 1792x1344@60 Hz, pixel clock 204.8 MHz
extreme: 1792x1344@75 Hz, pixel clock 261.0 MHz
extreme: 1856x1392@60 Hz, pixel clock 218.3 MHz
extreme: 1856x1392@75 Hz, pixel clock 288.0 MHz
extreme: 1920x1200@60 Hz, pixel clock 193.16 MHz
extreme: 1920x1440@60 Hz, pixel clock 234.0 MHz
extreme: 1920x1440@75 Hz, pixel clock 297.0 MHz

If there are no user controls on the VGA to HDMI adapter to adjust for various input VGA levels, you will have to find a more expensive VGA to HDMI adapter with this feature.

I am afraid there is no control. There are no trimmers, the VGA2HDMI looks like a blackbox 

[Nominal Animal]

Does the Linux kernel report any EDID information (from a HDMI display, back through the VGA2HDMI converter, via I2C to the VGA adapter)?

Install the edid-decode package (sources at git.linuxtv.org/edid-decode.git), and run
    find /sys/devices/ -name edid -exec edid-decode '{}' ';'
to find out.

If the kernel receives no EDID information, then the VGA2HDMI converter does not pass it back from the HDMI display to the VGA adapter, which indeed could be part of the problem.  It is notable that HDMI uses E-EDID whereas VGA just plain EDID (same link), so some kind of mapping is needed on the converter.

The particular bits we're concerned about are the three most significant bits at byte offset 20 in the EDID 1.4 block:
    000: RGB signal range is from -0.3V to +0.7V
    001: RGB signal range is from -0.286V to +0.714V
    010: RGB signal range is from -0.4V to +1.0V
    011: RGB signal range is from 0V to +0.7V

It is also possible in Linux to create your own EDID information for the kernel driver to use instead of what is passed via the VGA I2C lines in a fully connected VGA cable.  Specifically, in edid.S, you'd change
    video_parms:   .byte   0x6d
(which corresponds to the default 0V to +0.7V signal range), into either
    video_parms:   .byte   0x0d  /* -0.300V to +0.700V */
or
    video_parms:   .byte   0x2d  /* -0.286V to +0.714V */
or (unlikely!)
    video_parms:   .byte   0x4d  /* -0.400V to +1.000V */

Whether your VGA adapter is actually capable of honoring this or not, I do not know.

Pin 9 in the VGA connector does provide at least 50mA at 5V±5%, but to create a board to adjust the levels, one would need a bipolar supply, and a capability to both shift (0.0V to -0.3V) and amplify (by 1.000× to 1.429×) each of the RGB signals, noting that each of them have a separate ground/return.  So, it should be quite straightforward to implement such an analog board, except that at 1280x1024, you need 160 MHz of bandwidth; are fast enough opamps too expensive to make such a thingamajick useful?  I dunno.  Making a stable enough bipolar supply alone scares me.

[mariush]

The HDMI output may be Studio (Limited) RGB / YCbCr   where the values for the 3 elements are not 0..255 , they're 16..235 for Y and 16..240 for Cb and Cr

See https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr

You should configure the HDMI capture card to also capture assuming the input is in this format, and the capture card should then expand that 16..235 to original 0..255  , and Cb/Cr from 16..240 to 0..255 and restore the colors.

Some TVs use the "Full " (0..255) YPbPr / RGB when you configure it on PC Input / Raw  but assume that Studio/Limited mode when HDMI input is set to "Bluray" or "TV set top box" or allow you to switch between Full / Limited.

Video cards also have this option to output Studio (Limited) RGB/YCbCr  or Full RGB/YCbCr - check the control panel of your video card. I know for sure AMD cards have it. 
This way you would be able to test your capture card.... perhaps by setting it as 2nd display and clone your main monitor.
There are also filters to correct captured data after capture in most video editors, if this turns out to be the issue and you already captured stuff.

[m k]

The screen has switched on the Technicolor compensation.

Can you explain? and is there a workaround? kind of compensating circuit or something?

Just one of those asymmetrical picture "enhancement" modes.
But that is in the monitor so it's irrelevant.

It seems that your problem is too cheap adapter.
On the other hand the link has a converter list and it is not saying anything about the picture quality, it's also 10 best, yours is #7, so one can assume that not so good ones are disqualified.
https://www.slashdigit.com/best-vga-to-hdmi-converters/

If you have a peak hold DMM make white full screen picture and measure those VGA RGB values.

There's a USB power connector.
Have you checked how your Linux box is seeing it?

[bw2341]

Oops! I had it the wrong way around. The sink device (VGA to HDMI adapter) has the EDID EEPROM. The source (SBC) has to read the EDID and present the proper signal.

The SBC is a commercial AMD Geode x86-PC in mini ITX form factor, running Linux.
I have also tried a common PC and a laptop with no progress, still washed out colors.

If the VGA to HDMI adapter has the same problem with other VGA sources, the VGA to HDMI is either broken or incorrectly designed.

You mentioned earlier that you don't have a native HDMI source to check the HDMI capture device. You could try a DVI source with a DVI to HDMI cable. It's not the best test device as there are a lot of differences between DVI and HDMI. Can you reveal which HDMI capture device you are using?

With a DVI to HDMI cable you could also test the VGA to HDMI adapter by connecting it to a DVI monitor. This might not work as I'm not sure if HDMI sources are required to support DVI sinks.

Could you post screenshots and video clips of the problem? A screenshot from the source and the matching video clip of the capture would be helpful.

[AndyBeez]

I note @eevblog Dave has already been in this ball park before:

https://www.eevblog.com/forum/reviews/vga-to-hdmi-converter-teardown/

[DiTBho]

Does the Linux kernel report any EDID information (from a HDMI display, back through the VGA2HDMI converter, via I2C to the VGA adapter)?

Just checked and it doesn't report any EDID information. I never worried because it's not a problem for my { NEC-17"CRT, NEC-21" }, which work just fine.

My NEC monitors are "multisync" so they probably have a smart circuit; I'd like to know that the VGA2HDMI module handles H and V frequencies and all other properties without talking to the EDID eprom.

[DiTBho]

Pin 9 in the VGA connector does provide at least 50mA at 5V±5%, but to create a board to adjust the levels, one would need a bipolar supply, and a capability to both shift (0.0V to -0.3V) and amplify (by 1.000× to 1.429×) each of the RGB signals, noting that each of them have a separate ground/return.  So, it should be quite straightforward to implement such an analog board, except that at 1280x1024, you need 160 MHz of bandwidth; are fast enough opamps too expensive to make such a thingamajick useful?  I dunno.  Making a stable enough bipolar supply alone scares me.

There are only 4Mbyte of VRAM for the framebuffer, it's enough from 640x480/32bit to 1024x768/32bit

• 640x480@60Hz, pixel clock 25.175 MHz, ~<1MB vram
• 1024x768@60 Hz, pixel clock 65.0 MHz, ~<3MB vram

Limited VRAM here is a pros because you only need ~70Mhz of bandwidth for the OAs 

[DiTBho]

If the VGA to HDMI adapter has the same problem with other VGA sources, the VGA to HDMI is either broken or incorrectly designed.

Just ordered other three from Amazon. Just for testing, I will return them in a week.
- GANA white (9 euro)
- GANUA black (13 euro)
- GANA black (20 euro)

I am also going to buy the Startech Pro (120 euro), which looks more professional and has better feedbacks

You mentioned earlier that you don't have a native HDMI source to check the HDMI capture device.

I asked a friend to lend me an RPI 3. This Linux card has an HDMI port. Tomorrow we will see 

With a DVI to HDMI cable you could also test the VGA to HDMI adapter by connecting it to a DVI monitor. This might not work as I'm not sure if HDMI sources are required to support DVI sinks.

Could you post screenshots and video clips of the problem? A screenshot from the source and the matching video clip of the capture would be helpful.

Yup, in hindsight I have already prepared a kind of Philips PM5544 test card, I just need to set-up and compare.

I will post here some screenshots.

[DiTBho]

Have you checked how your Linux box is seeing it?

it's only a +5V power link. USB.D+ and USB.D- pins are not connected.

[DiTBho]

The White Ganua in a video on YouTube 

[DiTBho]

Teardown, here

Interesting note

The PCB is relatively sparsely populated with all of the work being done by a Macro Silicon MS9288A with a few linear voltage regulators used to provide the necessary voltages. The IC is clocked by a 24.576Mhz crystal.

U2 is unpopulated, and I suspect, it may be a position for the EDID EEPROM. Note that there are no ferrite beads on any of the HDMI differential pairs – so I suspect they have been omitted in the name of cost saving.

The underside is free of components with mostly a solid ground plane and a few traces. It seems they were also too lazy to clip off the crystal’s legs – by leaving them in the air, they may act as antennas and “radiate” – not a good idea. The PCB also has some flux-like deposits as if it wasn’t cleaned properly.

[DiTBho]

At times, the image does come up a little soft as it seems it hasn’t quite synched to the VGA signal properly in terms of phase.
[ .. ]
I also found that connecting the output from the converter into an HDMI splitter resulted in a purple bar appearing on the left side of the image. The cause is not known but may be related to signal timing. But using it with my Avermedia LiveGamer Portable was no problem provided the converter had synced.

This is also interesting, because the HDMI-grabber I am using is sensitive to synchronism 

[AndyBeez]

The PCB in that teardown looks like a clone-alike from the one Dave has in his original posting. The XTAL is the same frequency and Dave's one has the EEPROM - an Atmel 24C02N.

A thought from reading the user comments on that teardown; are the VGA grounds and the converter's ground connected? In CVBS video, a missing or floating ground causes weak colours and bad sync.

[DiTBho]

are the VGA grounds and the converter's ground connected? In CVBS video, a missing or floating ground causes weak colours and bad sync.

good point ... I need to check.

Today I spent the whole day on the capture-application, rewritten in C from scratch, because the original application crashed when the udp payload is zero (probably a bug), and when the packet length is wrong due to data-corruption.

Now it's more robust and doesn't crash 

[darkspr1te]

Back when i used to repair monitors and old skool video cards (vga based) we often saw that the output on the vga side would be too high (washed out and bright) or too low (dark and washed out) . depending on the card type it may or may not have a vga signal buffer that has failed or it's input voltage has failed, matrox cards often had this issue and you would see 3.8v on the buffer VIN pin instead of 5v , this would output 0.5v peak to peak on the buffer instead of 0.7v peak to peak.


darkspr1te

[DiTBho]

Back when i used to repair monitors and old skool video cards (vga based) we often saw that the output on the vga side would be too high (washed out and bright) or too low (dark and washed out) . depending on the card type it may or may not have a vga signal buffer that has failed or it's input voltage has failed, matrox cards often had this issue and you would see 3.8v on the buffer VIN pin instead of 5v , this would output 0.5v peak to peak on the buffer instead of 0.7v peak to peak.

That's interesting, I have a couple of projects based on

• PCI/32bit Matrox Millenium 1, 2MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox Millenium 2, 4MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox G450, 8MByte VRAM, VGA-dual-head, MGA-v2
• PCIexpress, Matrox G550 MGI G55-MDDE32F, 32Mbyte VRAM, DVI-D-single-head, MGA-v2

Were they on your bad-card list? 

G450 and G550 are more recent cards than Millennium cards, and looks better manufactured, but they are more annoying on the firmware side.

I spent two years reverse engineering a binary-only driver on Windows to understand the minimal set of things to do to correctly enable dual-channel output in order to prepare some patches for my PowerPC embedded board.

A lot troubles there, including bad setup of some registers that caused incorrect colors and weird behavior, that's because inside the MGA-v2 chip there is a programmable "Warp Engine" which theoretically enhances flexibility of the chip.

Unfortunately Matrox never described the functionality of this component in-depth, and there is no Linux driver that uses this functionality, it simply remains disabled.

Little is known about it, so ... enabling is like walking in the dark without a  portable flashlight, you risk tripping and falling into more troubles.


Anyway, I am not using any Matrox VGA card with that bloody vga2hdmi+hdmi-video-grabber, I will do it in the future, but not now, I don't want to combine problems

[DiTBho]

here a pic

[DiTBho]

here it is my "Philips PM5544"-like test card 
Designed with GIMP!

[darkspr1te]

Back when i used to repair monitors and old skool video cards (vga based) we often saw that the output on the vga side would be too high (washed out and bright) or too low (dark and washed out) . depending on the card type it may or may not have a vga signal buffer that has failed or it's input voltage has failed, matrox cards often had this issue and you would see 3.8v on the buffer VIN pin instead of 5v , this would output 0.5v peak to peak on the buffer instead of 0.7v peak to peak.

That's interesting, I have a couple of projects based on

• PCI/32bit Matrox Millenium 1, 2MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox Millenium 2, 4MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox G450, 8MByte VRAM, VGA-dual-head, MGA-v2
• PCIexpress, Matrox G550 MGI G55-MDDE32F, 32Mbyte VRAM, DVI-D-single-head, MGA-v2

Were they on your bad-card list? 

G450 and G550 are more recent cards than Millennium cards, and looks better manufactured, but they are more annoying on the firmware side.

I spent two years reverse engineering a binary-only driver on Windows to understand the minimal set of things to do to correctly enable dual-channel output in order to prepare some patches for my PowerPC embedded board.

A lot troubles there, including bad setup of some registers that caused incorrect colors and weird behavior, that's because inside the MGA-v2 chip there is a programmable "Warp Engine" which theoretically enhances flexibility of the chip.

Unfortunately Matrox never described the functionality of this component in-depth, and there is no Linux driver that uses this functionality, it simply remains disabled.

Little is known about it, so ... enabling is like walking in the dark without a  portable flashlight, you risk tripping and falling into more troubles.


Anyway, I am not using any Matrox VGA card with that bloody vga2hdmi+hdmi-video-grabber, I will do it in the future, but not now, I don't want to combine problems

It was mainly matrox Mystique cards in my dept, you may even remember the advert with the hidious clown offering the card to you, 
They used a st ramdac and buffer and both were fed from the same rail with a SMD cap that would crack in most cases causing almost but not direct shorts depending on temp or bend in the board.
Anyway, one trick i learned is biasing a channel , either to gnd or 1v rail with a pot and that would confirm a number of thing for us depending on what we saw on the crt , the crts we used were sony, illyama and kyrocira  we the first two having major saturation issues often on the input  side (the had caps on the RGB inputs which would leak and short to 1v rail) , the kyrocira units didnt have these filters and hence not affected by the signal out of spec and we often swapped them into the cabinets instead of the sony for pure ease despite the sony having the better image. 

Another item we had was a break out board for vga signals and injectors too, although i never found myself using the injectors (long setup time) over just grabbing our inhouse stocks computer and using it's vga output through the breakout and a scope to measure the h/v refresh, thats where we had some fun issues, either with drift in the the frequency or locking onto the signal due to improper hyrystisis on the input buffers which suffered from silicon rot on early models, this would duplicate the matrox ramdac failure model , same image issues which is why we always request monitor, card and PSU with the PSU having failing 5v rails which would kill the 1v/3.3v rails further in the chain again duplicating the original matrox failure mode exactly.

My point to the above rambling is that the input of the vga device can be very sensitive to the output of the driver/buffer/ramdac in either voltage P2P or voltage offset and these are values you can test & alter with ease, you can even use one channel to input to a svideo input with a simple resistor+cap signal combiner to confirm your systems output.

I never actually dug further into the cards software in those days, i wish i had now as our dept was well supported by matrox directly and we had manuals and sdk's laying around, no NDA to sign either. But alas i was a 68000+arm fanboy back then so it was still all amiga & Archimedes for me and had no interest in x86/PowerPC tech(unless it was SCSI  ) . 


One thing that might help you in your warp engine RE is matrox did a direct port of quake3 dos that did not run on other layers but direct to the card and was included with some models, it was shared a lot initially as it had no copy protection but ONLY worked with matrox cards with warp engine and that was made clear in the debug file that was included which everyone though would magically help them add opengl support, but alas only pointed to the matrox specific calls which replaced the opengl calls. Back then useless, now maybe not. 
 


darkspr1te

[Nominal Animal]

I decided to take a guess at how difficult would it be to create a circuit to adjust the levels.

Analog ADA4412-3 is an integrated triple video filter chip with about 36 MHz bandwidth, designed for 720p/1080i.  It has a fixed gain of 2x, so by attenuating its inputs, we can adjust the amplification.  It also has an output DC offset adjustment of ±0.5V.  It can use the +5V supply from the VGA connector, but to be able to get a negative DC offset, we also need a negative supply between -1V and -5V.

It is in stock at JLCPCB for assembly, as well as at lcsc.com, in QSOP-20, for about USD $3.20 apiece.

Here is my idea of an implementation (but do recall that I'm only a hobbyist, not an EE, and most members here could design a better schematic for this!):


On the host VGA side, pin 1 is connected to R, 2 to G, 3 to B, 6 to RGND, 7 to GGND, 8 to BGND; pin 9 provides +5V for V+.  Pin 10, ground for VSync and DDC, is used as GND (and implicitly on the right side as the ground for the ROUT, GOUT, and BOUT signals on the converter side VGA connector).  I do not know how to provide the -1V to -5V negative supply for V-, though; some kind of inverting circuit/regulator?  Also, the V+ and V- might use some filtering, just in case.

R1+R4, R2+R5, R3+R6 are the voltage dividers for the input signals, also providing 75 Ohm termination as required.  The wiper varies between 0.27× and 1.0× of the input voltage, so combined with the 2× gain in the chip, we can adjust the gain of each color component separately between 0.53 and 2.0.

R7 and R8 form the differential input pair to the output DC offset adjust; they're multiturn 10k pots.  (R8 could be eliminated, by connecting LEVEL2 directly to GND, but this way they're both ratiometric to V+ and V-, and thus should yield a stabler offset.)  Before soldering, they're both adjusted so that the wiper is about midway, ratiometrically the same for both.

[Nominal Animal]

On the other hand, using something like TI TVP7002 to digitize the VGA inputs directly, using say an ISSI IS61C256AL SRAM chip for mapping 15-bit color input into an 8-bit run-time defined palette, and something like an FPGA, FX2LP, or maybe even a Teensy 4.x to grab the (8-bit image) data, and to program the TVP7002.  (The SRAM address lines define the 15-bit color, and the data lines the 8-bit pixel value.  TVP7002 outputs are tristated when it is in reset, so a microcontroller connected to both (and the strobes) can quickly fill in the SRAM with an application-specific SRAM pattern.  One can even map to a 4-bit color table (16 colors), halving the bandwidth needed, for 16-color capture with custom palette!)

Could be an interesting project in itself, since 1024x768 @ 60Hz has a 65 MHz pixel clock, and produces 377,487,360 data bits per second at 8 bits per pixel, which might be doable over USB on a Teensy.  1024x768 @ 75Hz has a 79 MHz pixel clock, and produces 471,859,200 data bits per second; too much for high-speed USB.  But with 16 colors, 4 bits per pixel (or two pixels per byte), even that should work; an interesting option with Teensy 4 FlexIO (flexio_t4), since both 8bpp and 4bpp would simply be a run-time format selection...  The maximum clock rate of the IS61C256AL is over 80 MHz (12 ns), so it is just a matter of getting the digital logic right (and delaying the clock/strobe from the TVP7002 by about 12ns to trigger the DMA data read).

Interestingly, if one captures 16 bits per pixel (r5 g6 b5), then one can use UVC with the RGBP format (uncompressed pixels), and standard USB Video support suffices (using standard drivers and webcam software on a computer).   A single 1024x768 frame then needs 1.5 Mbytes (1,572,864 bytes), though, and the maximum frame rate via high-speed USB is somewhere between 25 and 30 frames per second.  (No such luck with the indexed color formats.)

[DiTBho]

In the meantime, I ordered the Startech professional VGA-HDMI, to be coupled with the HDMI grabber.
Interesting the color regulator, I will keep it in consideration if the Startech shouldn't be enough to fix the problem.

[DiTBho]

On the other hand, using something like TI TVP7002 to digitize the VGA inputs directly, using say an ISSI IS61C256AL SRAM chip for mapping 15-bit color input into an 8-bit run-time defined palette

That's similar to how old VGA grabbers operate 

I bought a few just to have a look at their hardware, one can be hacked, which is the reason for the topic about Golang to C conversion. There is no documentation except a source written by someone who tried to hack the grabber.

There is no audio, it only captures the VGA without any compression, which is good because having to deal with encryption, mjpeg or h264 is not easy.

Anyway, no-audio means I will have to think about an external circuit (audio-to-usb?) to capture and synchronize it with the video.

Not good, but it's a good starting point, and a useful piece of hardware to take a screenshot of a VGA screen.

Like I said, my "computer drug dealer" gave me some video grabbers. Some have a fast USB-bulk dedicated chip (~40Mbyte/sec), some Fast-Ethernet chip (~50Mbyte/sec), but if I were to build something I would prefer Ethernet over udp/ip.


So ... instead of Teensy, I would probably think about TI TVP7002 + static ram/pram + Xilinx-FPGA + parallel/32bit Fast-Ethernet chip


We will see ... just to give you priorities
- high priority: first I want to try to hack existing VGA and HDMI grabbers
- middle priority: C790 HDMI2CSI + RPI + I2S-hack (which can add Audio)
- low priority: custom solution

[m k]

Low priority:

One possibility is also a line buffer, or many.
Then the whole thing is in own hands and interpolation speed per CPU can be low.
Timing can be tricky though.

Analog interpolation is also possible.
Then even floating points wouldn't be a problem.
But perhaps a bit out of the scope.