Well, perhaps the '$9' figure I posted was misleading. Yes, you can buy a single IC which is designed to convert composite video to 24-bit digital colour, with adjustable sync timing. It can extract the colour and brightness, (and the sync) from standard composite video...which is essentially a composite to RGB converter - and then sample this with high speed ADC's. But these require a hell of a lot of support circuitry, PCB layout concerns, power requirements, filtering... trust me, what seems to be a great $50 project, can balloon into the point of diminshing returns.
Some numbers for the math masochists (like myself):
The framerate of TFT/LCD displays is in the order of 50-70Hz, and if you used a 'dumb' display (just one with drivers, no controller, by far the msot common) then you must 'draw' each frame, providing 3 x 8-bit numbers for each pixel. For say 320x240, thats 74800 pixels. multiply that by 3 bytes, and thats 225kbytes (230400 bytes). You must send this ammount of information for every frame, whether the display is static, or a motion picture. for 50 frames per second, you're talking giving the display 10.98Mbytes per second.
Now, if you're just displaying data from a microcontroller, with a bit of logic, and some ram to store your frame, its possible. But our source is a constantly changing waveform - you can't go back and re-read what the signal once was. So in order to allow for the differences in timing between composite video, and what the LCD wants, one needs a buffer. The video decoder takes in composite video, and spits out bytes, it must be stored in ram, so that your LCD controller can take that information when it needs it. This equates to more IC's, more circuitry to generate the timing signals = mo money
The resolution of your LCD determines how many pixels you need per line, and as such, determines how the composite video is sampled. It starts to get VERY hairy when working out the sampling frequency, and timing requirements to determine when each part of the circuit does what. Get samples, store in buffer, new LCD line, read from buffer etc..
All of these parts, although relatively straight forward, add up do a rather complicated system which is rarely done by DIY'ers, although FPGA's are usually used in such situations.
If you open up a cheap in-car display (not a tv, as that has RF and tuning as well....gah) you will see some pretty big chips, generally a few ones from well known manufacturers (like those analog video decoders) as well as a master controller, which I think is generally an ASIC only available to the maker of the glass/TFT. Much cheaper for them to use custom jobs.
If I get time tomorrow I'll take a few snaps of the PCB's of such displays just to show you what you're up against
Apologies for another long post, but I might as well mention 'mpeg'. Mpeg video, since its all digital, can generally be handled entirely on one chip with very little support circuitry (read: analogue). So whilst a digital photoframe will read MPEG's, decode them into 'bitmap streams'....it passes this directly to the LCD. This means the part that 'controls' the LCD is embedded in that MPEG decoder chip (again, another ASIC which is unlikely you'll ever find the datasheet for). So all you get from a digital photoframe, is the LCD display glas, and its driver chips (on the display itself) which you can probably get for around $20 anyway.
Modern embedded electronics has become far more integrated, what once required 10 chips and a shed load of analogue, is often now just a single IC with a handful of passives. There are very few 'modules' circuits. This makes things smaller, and cheaper, great for consumers, but a ***** for us guys who like to salvage parts and subcircuits, or hack consumer goods for our own projects
