DSP - Lectura CCD

Hola!

Me gustaría transmitir vídeo RGB de 8bits a 30fps y a una resolución de alta definición (1920x1080), haciendo un barrido del CCD desde un DSP, utilizando conversores A/D.

¿Podría comentarme alguien cuál debería ser la velocidad de los A/D para garantizar este comportamiento?

Haciendo el cálculo de 1920 x 1080 x 3 canales x 30 frames obtendría los píxeles y, ese valor multiplicado por 8bits, no tengo claro si una velocidad de 1.5Gb/s sería la adecuada para los conversores.

Gracias!!!
 
Última edición:
¿ Porque no usar un IC que ya tenga integrado el manejo de las cámaras ?

El siguiente es un ejemplo (el primero que encontré en una búsqueda de 5 segundos), tiene integrada la interfaz para conectarse a un sensor sumado a un CPU para que lo programes como mas se adecúe a tus necesidades.
 

Adjuntos

  • ASC884x,885x_Br.pdf
    479.6 KB · Visitas: 5
En crudo, sin conversión de ningún tipo, tenés que pensar en USB3 o Ethernet Gigabit.

Tenés alternativas como trabajar con una región de colores YUV (I420) para reducir a la mitad la información, pero seguís necesitando una compresión tipo H264, lo que implica un procesamiento bastante pesado.

Si trabajás en crudo, para USB3 te recomiendo usar un Cypress CYUSB301X, te resuelve exactamente lo que necesitás con ejemplos además del driver del lado de PC. El problema es que es un integrado BGA y que recomienda usar 8 capas en PCB.
 
Hola!!

tengo una duda, ya que estoy manejando un DSP para un trabajo, para transmitir vídeo en alta definición, utilizando el estándar de compresión H.265.
Lo que me genera más dudas es el tipo de aritmética que me va a venir mejor utilizar, es decir, formato de coma flotante o formato de coma fija.

¿Me podría alguien ayudar?

Gracias!!!
 
Pues así desde la absoluta ignorancia ¿Que valores pueden tomar las señales RGB?
¿Admiten negativos, admiten decimales?
Creo que "unsigned long int"
 
Última edición:
Claro que no.
"Desde mi absoluta ignorancia" indicaba eso exactamente.

La cuestión es si los números que manejas admiten decimales y negativos o solo enteros positivos y hasta que valor admiten.

En función de eso, el tipo que más se le aproxime por encima. Cuanto menos desperdicies mejor irá.

De nuevo "desde mi absoluta ignorancia".

Lo digo porque he visto definir como "double" números enteros que iban de 0 a 23 porque "así funciona" y efectivamente funciona, pero gastando de más.
 
Para trabajar en la conversión H265, supongo que usas alguna SDK, ¿es así?. Todo dependerá de eso.

En cuanto al RGB tradicional, es de 24 bits (entero de 32 bits) o 3 bytes de 8bits. Pero todo dependerá de como requiera los datos la SDK que vayas a usar. En H264 se que antes tenés que pasar de RGB a YUV i420 que son 12bits (si, se reduce a la mitad).
 
Atrás
Arriba