Difference between revisions of "OpenHDCapture"

From OpenCircuits
Jump to navigation Jump to search
(Project Start)
 
Line 1: Line 1:
 
== Description ==
 
== Description ==
This project will capture High Definition Video 1280x720 at 30fps, and hopefully be capable of 60fps and maybe even 1080p.  I intend to use a cheap Spartan Xilinx FPGA, A HiSpeed USB PHY like the USB3318, and an Analog Devices Video A/D chip similar to an ad9883.  I will nail down exact chip numbers later.  The target platform driver will be written for linux.  This project is more a proof of concept and for fun than to be practical.  But I will take any advice and help that I can get.  Entire BOM should be less than $40 but we'll see.
+
This project will capture High Definition Video 1280x720 at 30fps, and hopefully be capable of 60fps and maybe even 1080p.  I intend to use a cheap FPGA, A HiSpeed USB PHY, and an Analog Devices Video A/D chip.  I will nail down exact chip numbers later.  The target platform driver and example code will be written for linux.  This project is more a proof of concept and more for fun and excercise rather than to be practical.  But I will take any advice and help that I can get and who knows what we might create here.  Entire BOM should be less than $40 but we'll see.
  
  
 
== Current Status ==
 
== Current Status ==
I am in the planning/brainstorming stages, although I have been researching this for at least the last 6 months.  I have a working Forward/ReverseDCT algorithm in matlab that can compress an image.  I have also done much research on putting a DCT in hardware.  Currently the DCT will be broken down into 2 stages, and all multiplies/adds will be done using a bit-wise pipeline.
+
I am in the planning/brainstorming stages, although I have been researching this for at least the last 6-8 months.   
[http://en.wikipedia.org/wiki/YUV YUV422] 720p data comes in at roughly (1280*720*60*16) = 885 MegaBits per sec.
+
 
 +
I have a working Forward/Reverse DCT algorithm in matlab that can compress an image 5:1 with little loss in quality.  I have also done much research on putting a DCT in hardware.  Currently the DCT will be broken down into 2 stages, and all multiplies/adds will likely be done using a very parallel bit-wide pipeline to keep clock speeds high.
 +
 
 +
'''Data Bandwidth Issues'''
 +
[http://en.wikipedia.org/wiki/YUV YUV422] 720p data comes in at roughly 1280*720*30*16 = 443 MegaBits/s.  HiSpeed USB is 480Mbits/s which, after taxes, is probably not enough.  Note that 720p60 is twice that.  Either way using the DCT and some Huffman coding along with other simple compression techniques we can squeeze the data down a little without hurting quality too bad.  My goal is to get it down to 150Mbits/s
 +
 
 +
 
 +
== Improvements ==
 +
Yes video data is highly redundant, but the only way to utilize this redundancy is by adding much more complexity and hardware/memory.  For example, if you just want to compare two frames to encode the difference, you must know what the last compressed frame was.  In hardware that means storing the previous compressed frame, decompressing that block, and then comparing the data.  This adds almost twice the complexity and hardware, and makes the memory requirements much larger than exist on cheap FPGA's.  Any help here would be appreciated though.
 +
 
 +
== License ==
 +
All files for this project are licensed under the GNU GPL V3
 +
 
 +
 
 +
== Hardware (Under constant review)==
 +
* Spartan Xilinx FPGA
 +
* HiSpeed USB PHY like the USB3318
 +
* Analog Devices Video A/D chip similar to an ad9883
 +
 
 +
 
 +
== Software ==
 +
An example program will be written using the SDL library.  Linux Drivers will likely use libusb unless I have to go lower level. I am newb to Linux kernel drivers but I ain't scared ;)

Revision as of 13:31, 11 February 2010

Description

This project will capture High Definition Video 1280x720 at 30fps, and hopefully be capable of 60fps and maybe even 1080p. I intend to use a cheap FPGA, A HiSpeed USB PHY, and an Analog Devices Video A/D chip. I will nail down exact chip numbers later. The target platform driver and example code will be written for linux. This project is more a proof of concept and more for fun and excercise rather than to be practical. But I will take any advice and help that I can get and who knows what we might create here. Entire BOM should be less than $40 but we'll see.


Current Status

I am in the planning/brainstorming stages, although I have been researching this for at least the last 6-8 months.

I have a working Forward/Reverse DCT algorithm in matlab that can compress an image 5:1 with little loss in quality. I have also done much research on putting a DCT in hardware. Currently the DCT will be broken down into 2 stages, and all multiplies/adds will likely be done using a very parallel bit-wide pipeline to keep clock speeds high.

Data Bandwidth Issues YUV422 720p data comes in at roughly 1280*720*30*16 = 443 MegaBits/s. HiSpeed USB is 480Mbits/s which, after taxes, is probably not enough. Note that 720p60 is twice that. Either way using the DCT and some Huffman coding along with other simple compression techniques we can squeeze the data down a little without hurting quality too bad. My goal is to get it down to 150Mbits/s


Improvements

Yes video data is highly redundant, but the only way to utilize this redundancy is by adding much more complexity and hardware/memory. For example, if you just want to compare two frames to encode the difference, you must know what the last compressed frame was. In hardware that means storing the previous compressed frame, decompressing that block, and then comparing the data. This adds almost twice the complexity and hardware, and makes the memory requirements much larger than exist on cheap FPGA's. Any help here would be appreciated though.

License

All files for this project are licensed under the GNU GPL V3


Hardware (Under constant review)

  • Spartan Xilinx FPGA
  • HiSpeed USB PHY like the USB3318
  • Analog Devices Video A/D chip similar to an ad9883


Software

An example program will be written using the SDL library. Linux Drivers will likely use libusb unless I have to go lower level. I am newb to Linux kernel drivers but I ain't scared ;)