Codificador de video MIPS bajo

Estoy buscando un codificador de video de baja compresión y MIPS bajo. Esto es para una compresión de calidad tipo VGA de 10 fps. ¿Cuáles son mis opciones? Necesito poder hacer esta compresión usando una CPU ARM M4 de 150MHz con soporte de punto flotante. (STM32F4) ..

Mi idea es sacar estos datos comprimidos de la CPU con un bus paralelo, no se realizará ningún procesamiento en los datos. Tasa de compresión sabia, tanto como sea posible, solo quiero ver los límites. Esto es para una aplicación de CCTV de bajo costo, me gusta ver lo que puedo lograr con una CPU de 5 USD y mucha banda de transmisión con un codificador de 30 USD con baja transmisión de datos bw.

10 fps, VGA generará datos de aproximadamente 25Mbit / seg. Esta es una tasa de datos bastante alta para todo lo que existe. Si puedo reducir esto a 5Mbit / seg, creo que puedo construir un sistema de CCTV de muy bajo costo. Una vez que obtengo los datos en la base, puedo volver a codificar los datos, por lo tanto, no importa cuál sea el mecanismo de compresión, siempre que no sea muy con pérdidas.

El video monocromático es lo que se necesita en este momento sobre el color.

Actualizar

• Esta CPU tiene 120MHz asignados a esta tarea.
• La interfaz de memoria es de 16 bits, por lo tanto, la escritura / lectura de la memoria externa es más lenta en comparación con la memoria interna.
• La memoria interna es de 120 KB y tiene acceso rápido de 32 bits. En ambos casos, se accede a la memoria a través del bus AHB, que deberíamos suponer 60MHz como frecuencia de reloj.
• Se espera el siguiente flujo de datos:
  1. Cámara -> DMA -> Memoria externa (sin participación de la CPU)
  2. Memoria externa -> CPU -> Compresión -> Memoria interna
  3. Memoria interna -> DMA -> Bus de datos -> Dispositivo externo

La CPU solo leerá una porción de compresión de datos y escribirá en su memoria interna (los datos comprimidos), luego comenzará una transferencia DMA.

1. Clasifique si necesita MIPS bajo o complejidad baja en general
Permítaseme un poco de libertad para dividir este problema en dos partes.

1. Codificación de baja complejidad, que permite menores recursos (especialmente en la memoria) para hacer que la codificación responda rápidamente en el sistema dado.
2. Bajo explícito en computación (MIPS). - que solo se refiere a los mínimos ciclos de CPU posibles.

Hay un tercer criterio, en el que las personas hablan de "baja latencia", para aplicaciones como la videoconferencia donde los recursos computacionales pueden no ser motivo de preocupación, pero el retraso general introducido por el código

Es importante tener en cuenta que en los sistemas de menor complejidad: el acceso a la memoria (velocidad y ancho del bus de memoria) y, a veces, IO son, en general, extremadamente más lentos, por lo que la clase de algoritmos MPEG sufre aunque el algoritmo computacional podría ser simple.

Antes de emitir un juicio sobre el requisito del códec, debe intentar hacer un presupuesto en términos de:

a. Ciclos de CPU por segundo.
si. Máxima memoria a través de put.
C. Latencia IO

2. Debe personalizar MPEG en lugar de reinventar.
En general, la clase de códecs MPEG le ofrece mecanismos muy flexibles para hacerlo. En ese sentido, no tiene que reinventar el códec tanto como preferiría personalizar MPEG 2 o MPEG 4 para realizar su trabajo.

En primer lugar, digamos qué elementos hacen posible la compresión y organícelos en el orden de complejidad:

1. Estimación de movimiento y compensación de movimiento. 1.a. Predicción directa (tramas P) 1.b. Predicción doble (cuadros B) 1.c. vectores de movimiento de alta resolución
2. Intra codificación - DCT (+ IDCT)
3. Qunatización - y selección del modo codificador
4. VLC: codificación de longitud variable. (CABAC en H.264)
5. Predicción coeficiente [En mpeg2 solo predicción DC- MPEG4 tiene más]

En la clase de algoritmos MPEG, la codificación basada en DCT y VLC se vuelven bastante obligatorios sin mucha elección, pero el resto de todos los mecanismos son muy esenciales.

Por ejemplo, la estimación de movimiento y la compensación de movimiento es uno de los elementos que más consumen MIPS. Si no tiene recursos para hacer esto, simplemente puede codificar todos los cuadros como cuadros I (lo que lo hace muy parecido a MJPEG), pero el decodificador MPEG estándar puede decodificar esto). Si puede permitirse un poco más de recursos (puede hacer una compensación de movimiento trivial usando la diferencia de cuadro), en lugar de enviar cada cuadro como Intra, puede restar cada blcok de su bloque de cuadro anterior; Si la diferencia es mayor que la señal original, envíela como Intra.

Por supuesto, todo esto significaría que perderá la eficiencia prometida por el codificador anterior, ¡pero creo que está dispuesto a renunciar a eso!

EDITAR:
Puede ver los siguientes códecs como buenos puntos de referencia:

1. MSSG: http://www.mpeg.org/MPEG/video/mssg-free-mpeg-software.html
   Bueno para comprender, pero podría ser el más lento del mundo.

2. FFMPEG: http://ffmpeg.org/ Probablemente el más rápido del mundo. Es bueno comenzar como un cuadro negro, pero no intente cambiar el código desde adentro. Podría darle buenas opciones para controlar cosas cuando usa la API de la biblioteca. Ya está portado en muchas plataformas, pero hacerlo en una nueva podría ser una tarea.

3. FAME: http://fame.sourceforge.net/ Esto se inició originalmente con el mismo propósito que usted describió. Sin embargo, estoy un poco fuera de contacto con esto, pero puedes probar esto.

4. Xvid: http://www.xvid.org/ Esto es MPEG-4. Este es uno de los mejores equilibrios entre código limpio y velocidad razonable. Debería ser más fácil trabajar con él si termina viviendo dentro del codificador.

5. JPEG: http://www.ijg.org/ Esto es JPEG. Esta es una de las mejores bibliotecas para portarla a través de plataformas. Además, JPEG es inherentemente más simple que algunos aspectos de MPEG, por lo que es posible que deba probar esto primero. La mayoría de las cámaras del mundo probablemente hayan usado esta biblioteca tal como está, ¡en lugar de crear algo propio!

Puede ser que estoy equivocado al usar MPEG! Pero ese es un tipo de riesgo que vale la pena correr.

Probablemente la mejor medida para verificar si eso funcionará o no es, solo intente tomar un DCT 8x8 estándar con cuantización en su imagen; optimizar solo esto. Si puede acercarse a su requisito de tiempo real, entonces creo que es bueno hacerlo con todos los fotogramas JPEG o todos los códecs MPEG I cuadros. Si estás lejos del objetivo, entonces no vale la pena.

Su primer problema es la memoria, incluso la versión más grande de ese procesador no tiene tanta SRAM interna (en términos de video, ¡es un procesador incrustado impresionante en comparación con muchos!): Un marco VGA es 300kB, frente a los 100ishkB en el procesador . Eso significa que tendrá que procesarlo a medida que ingresa, digamos en trozos de 8 o 16 líneas, lo que lo convierte en un problema mucho más "difícil en tiempo real" ya que los plazos tienen menos holgura.

No está claro cómo capturará datos, pero supongo que tendrá algún tipo de DMA desde el ADC o algún puerto digital, de lo contrario, pasará la mitad de su tiempo barajando datos.

Con el objetivo de reducir las relaciones de compresión, es posible que solo desee ver la codificación de los deltas entre píxeles a lo largo de una línea o un cuadrado de 3x3 y luego codificarlos aritméticamente.

Consulte también Compresión de imagen simple, sin transmisión, sin pérdida : aunque estaba pidiendo una compresión explícitamente sin pérdida, puede haber algunas ideas para usted allí.

Como punto de datos, uno de mis colegas implementó una compresión JPG mono de 8 bits 320x240 en un micro de 60 bits de 32 bits con unidad de coma flotante y un pequeño caché. Utilizó un código de referencia (es decir, optimizado para facilitar la lectura, no para el rendimiento) y obtuvo 5 fps con bastante facilidad. Las relaciones de compresión fueron del orden de 10x IIRC. La captura de imágenes se realizó mediante un bus de hardware externo que domina los datos en la RAM externa del micro.