EEVblog Electronics Community Forum

Electronics => Beginners => Topic started by: tineras on July 05, 2012, 02:30:26 am

Title: Suggestions for how to capture and delay an NTSC signal
Post by: tineras on July 05, 2012, 02:30:26 am
At the gym I attend, they were using a Tivo to capture a digital camera video feed that was then delayed by ~2-3 minutes so that the students could view their performance afterward. I had no idea the Tivo was even capable of this! Well, the Tivo died some time ago and their review system is sitting unused and collecting dust.

I thought it might be a challenging project to create an equivalent device that would capture and buffer the cameras video feed. A 1 minute delay should be sufficient.

This is me thinking out loud, so bare with me:  :P

I am assuming the video signal is NTSC. I have also made assumptions that if the data is captured at a specific sampling rate and sent back out at that sampling rate, the signal will be a recognizable/usable NTSC signal. If these assumptions are false or misguided, let me know. I believe the highest frequency is the color burst (approx 3.6Mhz), so the capture rate would need to be at least double that which would require a high speed ADC (and DAC on the other end). All of this data would need to be stored somewhere, which would be some type of flash or RAM memory. At 8-bits of resolution and 10M samples per second, I would need at least 600MB of storage space for 60 seconds of video. And of course, there needs to be some type of microcontroller or microprocessor to handle all of the passing of data back and forth. Reading the stored data and spitting it back out at a consistent rate so that the signal looks like a proper NTSC signal seems like it would be a challenge.

At first, I poked around to see if there was any way to use a microcontroller for this solution, but due to the high capture rate this seems like an impractical route to pursue. Even the high end PICs max out around 40MIPS, which isn't near enough to capture the data and write it to memory while also performing the reads from memory and spitting it back out again; all in a very time-sensitive manner. Capturing at 10M samples per second would only allow me 4 instructions to perform all of the above.  :o

So I am curious to see if anyone has any input on a good route to take to solve this problem. Most of my experience has been with PICs and not a whole lot beyond that. I don't expect this to be a simple or quick task. And I know I could just go out and buy an inexpensive device to do this, but that defeats the whole purpose for me... learning new stuff!

I have seen some mention of FPGAs being a good tool for this task. I have had a VERY small amount of exposure to FPGAs and I don't have any FPGA dev tools or hardware, so I'd need to buy something (preferably capable, but not crazy expensive). I have done projects that read/write to/from SD Cards (FAT), but have never interfaced directly to flash/ram, so that would be something totally new for me as well.

Alright, enough rambling. I think you get the idea of what I'm trying to do. Any feedback would be greatly appreciated.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: T4P on July 05, 2012, 02:39:49 am
FPGA
OR
Cortex-M4F (EG: STM32F417IGT6)
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: tineras on July 05, 2012, 03:29:28 am
FPGA
OR
Cortex-M4F (EG: STM32F417IGT6)

I will continue to look around at various FPGAs as well as the Cortex part you mentioned. While I do appreciate your response, I am hoping to have a little more dialog about this problem. So if anyone has any insights or sees potential pitfalls, please chime in.

-Thanks
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: SeanB on July 05, 2012, 04:55:53 am
Why did the TIVO die? Most of the time all it needs is a new hard drive and it will work again.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: Raff on July 05, 2012, 05:12:12 am
You should be able to pick up an older series 1 TiVo for next to nothing. only downside is that the series 1 uses IDE hard disks and they are hard to find new, but there are plenty of scapped computers around which should supply a drive, anything 40Gb or above should do. TiVo software is available too, check out www.oztivo.com (http://www.oztivo.com) for a guide.

Regards,
Raff
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: amyk on July 05, 2012, 06:49:42 am
If you want to capture the raw NTSC signal, 8 bits of resolution is not going to be enough to reconstruct a decent output signal. It would be better to digitise the frames into something like 640x480 @30FPS, which is around 27MB/s with 24-bit colour. 1.5GB will be enough to store this uncompressed; 2GB of DDR3 is cheap and has much more than enough bandwidth for this application when hooked up to an FPGA. The FPGA doesn't need to do more than stream the data to/from the RAM (using a circular buffer) and refresh it occasionally.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: jahonen on July 05, 2012, 07:58:21 am
I have done some video stuff in the past and I suggest that you use ADC and DAC crafted for the purpose (video decoder and encoder), for example ADV7401 and ADV7340 and many others from ADI and other manufacturers. I have actually worked with ADV7403 but that is not probably best hobbyist choice due to NDA stuff required.

http://www.analog.com/en/audiovideo-products/video-decoders/adv7401/products/product.html (http://www.analog.com/en/audiovideo-products/video-decoders/adv7401/products/product.html)

http://www.analog.com/en/audiovideo-products/video-encoders/adv7340/products/product.html (http://www.analog.com/en/audiovideo-products/video-encoders/adv7340/products/product.html)

Those will take care for most housekeeping tasks, like line locked clock generation, sync separation, black level locking, color decoding and reduce amount of your analog stuff you would otherwise need (for example biasing the video signal so that ADC dynamic range is not used for digitizing the sync pulses so that only active black-to-white is used in the ADC). Same for encoder side, video encoder takes care of burst generation, sync insertion etc.

Regards,
Janne
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: deephaven on July 05, 2012, 08:03:24 am
Get a cheap (~$25) USB video capture unit and record the video on a PC.

Doing it yourself would be interesting but would need quite a lot of effort. NTSC decoder, FPGA interfaced to SDRAM, NTSC encoder. Or, instead of lots of SDRAM, a microcontroller interfaced to bulk storage like an SD card but you would probably need some external logic like an FPGA to deal with the fast stuff.

It is possible to digitise NTSC directly without decoding, but there are issues. NTSC bandwidth is 4.2MHz. The 3.58 MHz subcarrier is within that bandwidth with room for it's sidebands.

Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: tineras on July 10, 2012, 10:05:26 pm
I have an Altera EPM7128SLC84-15 CPLD development board which has a 4MHz oscillator, but is capable of running at 100MHz if I replace the oscillator.

I've been looking around and various parts in my free time based on some of the discussion here (decoders, encoders, memory, fpga, etc.). The common decoders seem to have output clocks at about 27MHz (ex. http://datasheets.maxim-ic.com/en/ds/MAX9526.pdf (http://datasheets.maxim-ic.com/en/ds/MAX9526.pdf)). This seems awfully high to consider using the CPLD mentioned above at 100MHz. And I have to decode, write, read, encode.

I am guessing that this is not possible on this device. Will I need to bite the bullet and order an fpga and fpga dev kit? And what kind of minimum clock rate should I shoot for?

Thanks for being patient. Trying to wrap my head around all this in my limited ::) free time.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: deephaven on July 11, 2012, 11:40:36 am
I have an Altera EPM7128SLC84-15 CPLD development board which has a 4MHz oscillator, but is capable of running at 100MHz if I replace the oscillator.

I've been looking around and various parts in my free time based on some of the discussion here (decoders, encoders, memory, fpga, etc.). The common decoders seem to have output clocks at about 27MHz (ex. http://datasheets.maxim-ic.com/en/ds/MAX9526.pdf (http://datasheets.maxim-ic.com/en/ds/MAX9526.pdf)). This seems awfully high to consider using the CPLD mentioned above at 100MHz. And I have to decode, write, read, encode.

I am guessing that this is not possible on this device. Will I need to bite the bullet and order an fpga and fpga dev kit? And what kind of minimum clock rate should I shoot for?

Thanks for being patient. Trying to wrap my head around all this in my limited ::) free time.

The output format of that decoder chip is CCIR BT656 which is a standard upgraded from the original 601 standard. Do a web search to get the spec. As you have discovered, it uses a 27 MHz clock rate and can be 8 or 10 bit wide data. The h and v syncs are embedded within the video data as specific codes. I would recommend getting something like the cheapest Cyclone3 chip. This will be plenty fast enough and has a lot of on-chip resources. You will need a small micro to manage the thing and also talk to the decoder and encoder via I2C.

This is a big project, especially if it's for a one off, but you sure would learn plenty doing it.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: tineras on July 11, 2012, 03:17:52 pm

The output format of that decoder chip is CCIR BT656 which is a standard upgraded from the original 601 standard. Do a web search to get the spec. As you have discovered, it uses a 27 MHz clock rate and can be 8 or 10 bit wide data. The h and v syncs are embedded within the video data as specific codes. I would recommend getting something like the cheapest Cyclone3 chip. This will be plenty fast enough and has a lot of on-chip resources. You will need a small micro to manage the thing and also talk to the decoder and encoder via I2C.

This is a big project, especially if it's for a one off, but you sure would learn plenty doing it.

Thanks for the input. I didn't realize how big this project was until I started doing research, but I want to see it through even if it takes a while costs a bit of $$$. I will check out some Cyclone dev kits and start ordering parts for testing.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: deephaven on July 11, 2012, 03:55:51 pm

The output format of that decoder chip is CCIR BT656 which is a standard upgraded from the original 601 standard. Do a web search to get the spec. As you have discovered, it uses a 27 MHz clock rate and can be 8 or 10 bit wide data. The h and v syncs are embedded within the video data as specific codes. I would recommend getting something like the cheapest Cyclone3 chip. This will be plenty fast enough and has a lot of on-chip resources. You will need a small micro to manage the thing and also talk to the decoder and encoder via I2C.

This is a big project, especially if it's for a one off, but you sure would learn plenty doing it.

Thanks for the input. I didn't realize how big this project was until I started doing research, but I want to see it through even if it takes a while costs a bit of $$$. I will check out some Cyclone dev kits and start ordering parts for testing.

While you're researching, make sure you decide how you're going to store the digitised video, calculate how much storage you need for the delay you want. The output of the decoder you mentioned is uncompressed component video which will take up a lot more space than the mpeg (and other) files you'll see on the web. Also the data rate for uncompressed video is correspondingly higher. DDRAM will handle the rate easily, but you'd need an awful lot of it. So please do some calculations before embarking down a particular path.

Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: tineras on July 11, 2012, 05:02:35 pm

While you're researching, make sure you decide how you're going to store the digitised video, calculate how much storage you need for the delay you want. The output of the decoder you mentioned is uncompressed component video which will take up a lot more space than the mpeg (and other) files you'll see on the web. Also the data rate for uncompressed video is correspondingly higher. DDRAM will handle the rate easily, but you'd need an awful lot of it. So please do some calculations before embarking down a particular path.

I was thinking that 1 minute of delay would be sufficient. As a rough example, if I captured 8-bits at 27Mhz (27MB/s), then I would need 1,620MB available to store that data to store 60 seconds of video data. That is pretty significant and perhaps wasteful. I'll keep digging to see what my options are.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: SeanB on July 11, 2012, 05:30:29 pm
4G of DDR2 ram is cheap enough to use as memory. Simple to buy as plain PC memory. That should store around 2 minutes of video uncompressed
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: T4P on July 11, 2012, 05:46:48 pm
DDR2's getting pricey now since it's mostly discontinued (See The 'RAM CURVE')
And 4G is on the border of DDR2 anyway, it's hard to get all 4gigs on 1 DDR2 at least at a sane price

Maybe time to look at DDR3?
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: tineras on July 12, 2012, 12:35:11 am
Are there any good alternative Cyclone III dev boards that will suit my needs like the following:

http://goo.gl/FZaOf (http://goo.gl/FZaOf) ($50)
http://goo.gl/zG27c (http://goo.gl/zG27c) ($110)

Or should I just order the Altera Cyclone III Starter Board (http://www.altera.com/products/devkits/altera/kit-cyc3-starter.html (http://www.altera.com/products/devkits/altera/kit-cyc3-starter.html))? I don't want to spend $200 just for the heck of it if I don't need to. I do want something reliable/trustworthy.

I also noticed this the Altera DE0 (http://goo.gl/QBrNM (http://goo.gl/QBrNM)) which seems a little more reasonable at $119.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: joelby on July 12, 2012, 07:13:35 am
If you're not already experienced with FPGAs, I would recommend sticking with name-brand development boards rather than eBay ones. They tend to come with better manuals, reference designs, and community support, while the Chinese clones will give you just a (hopefully correct) schematic and nothing else.

You can't just hook up gigabytes of DDR memory to an FPGA easily - these are high performance, high speed devices and there are rather strict requirements about FPGA pinouts and PCB layout that you need to follow, so you will want to get a board that includes memory on-board. Don't expect to be able to just solder a DIMM up to a 0.1" expansion header with hook-up wire and have it work at all.

The Cyclone III starter has only 256 Mb (32 MB) of SDRAM, which isn't anywhere near your target. You may need to look for a development board that supports DIMM modules. These tend to only be supported by higher-end FPGAs and boards. I'm not aware of any boards under $300 with a DIMM slot.

Doing this with a computer and a USB capture thing will be relatively simple. The FPGA route will be rather expensive and difficult, though it would certainly be an interesting project!
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: T4P on July 12, 2012, 04:33:23 pm
Using a cheap PC is certainly the easy way out and you can still use the PC at the end of the day
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: tineras on July 12, 2012, 09:14:47 pm
If you're not already experienced with FPGAs
...
expensive and difficult, though it would certainly be an interesting project!

More excellent input. Thank you. :D I did some reading last night and it seems like Altera has gone to great lengths to educate the user on how to interface with various types of memory. I am really starting to appreciate the scope of this task and have made a rough schedule for myself that allows 6-8 months for me to complete it. I think that's a fair time frame given my schedule outside of work.

Quote
Using a cheap PC is certainly the easy way out and you can still use the PC at the end of the day

That is certainly an option, but the entire point of this project is for me to learn, learn, learn and then learn some more. This is a much higher priority than providing a replacement solution for my gym. I'm even anticipating that they will have fixed/replaced their Tivo well before I complete this.
Title: Re: Suggestions for how to capture and delay an NTSC signal
Post by: T4P on July 13, 2012, 12:31:34 am

Quote
Using a cheap PC is certainly the easy way out and you can still use the PC at the end of the day

That is certainly an option, but the entire point of this project is for me to learn, learn, learn and then learn some more. This is a much higher priority than providing a replacement solution for my gym. I'm even anticipating that they will have fixed/replaced their Tivo well before I complete this.

Certainly yes