Old Hi8 to 10 bit uncompressed video hack
 

Okay, I have been looking through these wonderful forums for the last few days, and I have found some great information, but nothing exactly like what I am looking for. My goal is to take an old Samsung Hi8 camera I have and capture the uncompressed video out of it directly to my PC.

After cracking open the camera I found that it uses the fairly standard AD9806 A/D converter to digitize the analog signal from the CCD. What I want to do is tap into the 10 data outputs (D0-D9) and the clock output (SHD) and run them into the PC. Between the camera and the PC I want to use a PIC18F4455 in streaming USB 2.0 mode to send the digital data straight into the PC. To clarify I have made a crude block diagram:

http://suprfile.com/src/1/1c78kxg/cam-block.jpg

To this point I think I can manage all of the hardware on my own, what has me stumped is the software. I want to take the raw data that is being streamed into the PC and encode it into an AVI file. For simplicity sake I am going to stick with an uncompressed AVI for now. No matter how hard I try I can’t seem to figure out how to convert the digital representation of the CCD’s output into frames/fields and store it as an AVI.

So to wrap things up I guess I have two questions to be answered:
1. Is my idea sound?
2. If it is how can I convert my raw data into an AVI?

Thank you for taking the time to read this.

The AD9806 will just continuously stream data. To figure out how to arrange the data to create the video frame, you need to use the H-SYNC and V-SYNC signals. There will be an H-SYNC pulse for every scan line and a V-SYNC pulse every frame. There may be the added complication of fields vs frames to consider.

These signals are elsewhere. I suspect there will be a buffer somewhere to store at least one scan line, if not a whole field or frame.

There's then the added complication of deconvoluting the raw pixel data from a single CCD into red, green and blue, so you'll need to know the pixel arrangement on the CCD. The arrangement is usually something like:

RGRGRGRGRGRG
GBGBGBGBGBGB
RGRGRGRGRGRG
GBGBGBGBGBGB

so you will not get full, uncompressed RGB.

Finally, by time you added it all up, the bit rate is going to be very high. Assuming 640 pixels per line, 525 lines per frame for NTSC including the blanking interval, 29.97 frames per second, and 10-bit resolution, that's 100,699,200 bits per second = 100Mbps to transmit via USB. USB 2.0 has an upper theoretical speed of 480Mbps, rarely achievable in practice. By time you take into account the transfer from USB 2.0 via PCI to a hard drive - with all the USB transactions being controlled by the operating system, I think you will have quite a time getting all the data to transfer smoothly.

The actual bit rate could be higher, since, according to the spec sheet for the AD9806, it can operate at 18MHz = 144Mbps.

what CCD Your Samsung got?

Thanks for the information John; it gives me much to think about. While I am still going to try and find a way to make it work, you’re right to say that it is not going to be easy.

Frank, the camera is a Samsung SCL906, I did not take it apart far enough to get a look at the actual CCD, nor do I have the schematics for it. However I do have the schematics for the Samsung SCL600 and it uses the ICX206AK-L CCD. I would say that there is a good chance that my camera uses it as well.

I imagine you should be able to do something very similar to andromeda perhaps. kinda like what they did to the dvx, and with the whole pixel shift thing. I dont understand much about how thats all acheived. but the result is impressive hd looking stuff.

Forrest: I dont quite understand the pixel shift thing my self, but I believe that in order for it to work you would need a 3 CCD camera. It is too bad that my Samsung only has one CCD.

I have been inspection the camera today, but I have yet to determine where the H-SYNC and V-SYNC lines are located. Anyone have any suggestions as to what chip they may come off of?

You should be safe with resolution, on digital, in particular, cameras use chips with resolutions a lot bigger than SD, and depending on what mode you are end depends on the resolution coming off the chip. Their might be some signalling off chip to indicate Sync, or at least close by.

Unless the chip exports video directly, you could look at recording the pattern instead, it will require a lot less data, and the pattern can be processed after on the PC to make the video. If it is a Bayer rather than complimentary filtered sensor, you should get more improvement.

You could use some capture card/USB capture devices to tap into the video somewhere is the processing chain. There is one that looks interesting at http://www.artray-ap.com/ but you might find a cheaper non-compressed one.

But you are already recording uncompressed to tape.

www.unibrain.com manufactures an uncompressed VGA firewire webcam/board using 1/4inch Sony CCD for around $80-140, and http://www.ptgrey.com/products/fireflymv/index.asp has an extra wide VGA for around $200. Using lower resolution you can get higher speeds (but I don't know if the colour can do this). But it is higher frame rate anyway.

I am still plucking away at this idea; I will get it to work somehow. What I am wondering now is if the H-SYNC is really necessary? If I know when the frame starts and stops (V-SYNC) and I know how many bytes/bits are in a scan line (640 x 10 bits) wouldn’t I be able to extrapolate the end of each scan line from that?

Does that PIC say full speed USB 2.0. Full speed means all 12mbits of the original spec, high speed means 480.

It specifically says "Full Speed USB 2.0 (12Mbit/s) interface" so unless it is capable of the 480mbit mode and its just not saying it, I think you need a different PIC micro micro-controller