Reviving Old Unsupported Devices with AI - AVerMedia Game Capture HD II - Chiptron.eu

Skip to main content

Skip to footer<br>Reviving Old Unsupported Devices with AI – AVerMedia Game Capture HD II<br>Articles2026-08-12<br>Author: Vladimir Smitka

In short: Reverse engineering the AVerMedia Game Capture HD II (C285) . Inside runs a small Linux on a Texas Instruments DM368 SoC – no locked-down hardware here. The refusal to accept 640×480 input was never a technical limit, just a whitelist in the vendor application encode. Via the serial console, a dump of the decrypted system and a root shell (init=/bin/sh in bootargs), the box can be opened up and its firmware replaced with a custom one written almost entirely by AI. The result: an open network capture box with an RTSP stream, any resolution from 640×480 up to 1080p, and 60 fps where the original offered nothing but a dead cloud and a vanished mobile app.

It’s amazing to watch what AI enables today. In one day, almost anyone can handle the amount of work that fifteen years ago would have required an entire manufacturer’s development department and taken months. I don’t mean AI does the work for you – as you’ll see later, I spent a lot of time shooting down its nonsense. But the shift in what’s achievable for one person over a weekend is enormous.

I tried it on a box left over from that era: AVerMedia Game Capture HD II , model C285 . Solid piece of hardware – inside sits a Texas Instruments DM368 SoC at 432 MHz, 256 MB RAM, and a hardware H.264 encoder.

At launch it could do sensible things: record to disk, stream straight to YouTube, be controlled from a phone. But the YouTube API has long since vanished , the mobile apps disappeared from the stores, and I lost the remote years ago. Support ended. What remained was working hardware with no usable path to it.

I dusted it off for a specific reason. I’m working on the picogame engine for microcontrollers and needed to capture their video output – DVI 640×480 . I hoped the box could at least handle something that simple, since recording to disk can be triggered by the hardware button.

It couldn’t 😥. The input only supported a very limited set of resolutions and VGA 640×480 wasn’t among them . The box simply rejected the signal.

That was the moment I decided to look inside. I’ll give away the punchline right away because it shows exactly what this whole piece is about: the limitation wasn’t in the hardware. The kernel driver has a table of supported input modes and the 640×480 progressive entry had been there the whole time . You just couldn’t reach it through the vendor app.

What’s inside

I wanted to know why 640×480 was being reported as a bad resolution – whether it was a hardware or software limit. So I opened the box and looked at what was actually driving it.

Part fittedSoC Texas Instruments DM368ZCE , ARM926EJ-S core @ 432 MHzintegrated HDVICP – hardware H.264 coprocessorISIF + IPIPE (previewer and resizer) for image processingControl MCU Nuvoton NUC100 (Cortex-M0) – I²C master for the whole boardHDMI input ITE IT6604E – HDMI/DVI receiverHDMI output ITE IT6613E – HDMI transmitterAnalog input TI TVP7002 – component/VGA video decoderRAM 2× Nanya DDR2, 256 MB totalNAND Winbond W29N01HVS1NA – 1 Gbit SLC, i.e. 128 MBEthernet PHY Realtek RTL8201EL – 100 MbitUSB ↔ SATA Genesys Logic GL830 Bus drivers several 74LVC244A between the ITE chips and SoCRTC backed by CR2032 EEPROM 24C256 (32 kB) on I²C, holds settings and MAC addressAudio two TI TLV320AIC3x codecs

One thing only became obvious after disassembly: several 74LVC244A drivers sit between the ITE chips and the SoC. That’s physical proof of how the video bus is routed, and it made sense later: the receiver and transmitter pass data over a shared 16-bit bus and the SoC just reads from it. That’s why the monitor can show the picture even without active capture through the SoC.

The NAND holds two complete firmware sets :

mtd0 bootloader 0x00000000–0x003c0000 3.75 MB<br>mtd1 params 0x003c0000–0x00400000 256 kB (U-Boot environment)<br>mtd2 kernel_fw1 0x00400000–0x00800000 4 MB<br>mtd3 filesystem_fw1 0x00800000–0x04000000 56 MB<br>mtd4 kernel_fw2 0x04000000–0x04400000 4 MB<br>mtd5 filesystem_fw2 0x04400000–0x07c00000 56 MB<br>mtd6 programer_space 0x07c00000–0x08000000 4 MB (writable jffs2)

Two banks switched by a single variable in the bootloader. That turned out to be crucial – one bank stayed as a safety net I could always fall back to while I repeatedly overwrote the other and bricked it several times.

The hardware can do it, so why not?

The datasheets gave no hint that these chips would have trouble with 640×480. The IT6604 is a standard HDMI/DVI receiver that handles VGA modes without issue. The IPIPE in the DM368 works with widths up to 2176 pixels. 640×480 is a dramatically lighter load than the 1080p the box supports.

So I figured the limit had to be in software – and that the box was probably running some kind of Linux. A quick search confirmed it, and more...