Codificador de vídeo MIPS baixo

Estou procurando um codificador de vídeo com baixa MIPS e baixa compressão. Isto é para uma compressão de qualidade do tipo VGA de 10 qps. Quais são as minhas opções? Eu preciso ser capaz de fazer essa compactação usando uma CPU ARM M4 de 150 MHz com suporte a ponto flutuante. (STM32F4) ..

Minha idéia é empurrar esses dados compactados para fora da CPU com um barramento paralelo, não haverá processamento nos dados. Taxa de compressão sábia, tanto quanto possível, eu só quero ver os limites. Isto é para uma aplicação de CFTV de baixo custo, eu gosto de ver o que posso obter com uma CPU de 5USD e muita banda de transmissão com um codificador de 30USD com transmissão de dados baixa bw.

10fps, o VGA gerará aproximadamente 25Mbit / s de dados. Esta é uma taxa de dados bastante alta para qualquer coisa lá fora. Se eu puder reduzir isso para 5Mbit / s, acho que posso construir um sistema de CFTV de custo muito baixo. Depois de obter os dados na base, posso recodificá-los, portanto, não importa qual é o mecanismo de compactação, desde que não seja muito prejudicial.

O vídeo monocromático é o que é necessário no momento sobre a cor.

Atualizar

• Esta CPU possui 120MHz alocados para esta tarefa.
• A interface da memória é de 16 bits; portanto, a gravação / leitura da memória externa é mais lenta em comparação com a memória interna.
• A memória interna é de 120KByte e possui acesso rápido de 32 bits. Nos dois casos, a memória é acessada via barramento AHB, que devemos assumir 60MHz como a frequência do relógio.
• O fluxo de dados a seguir é esperado:
  1. Câmera -> DMA -> Memória externa (sem envolvimento da CPU)
  2. Memória Externa -> CPU -> Compressão -> Memória Interna
  3. Memória interna -> DMA -> Barramento de Dados -> Dispositivo Externo

A CPU lê apenas um pedaço de compactação de dados e grava em sua memória interna (os dados compactados) e depois inicia uma transferência de DMA.

1. Classifique se você precisa de MIPS baixo ou de baixa complexidade geral.
Deixe-me ter uma pequena liberdade para dividir esse problema em duas partes.

1. Codificação de baixa complexidade - que permite que recursos mais baixos (especialmente na memória) tornem a codificação de resposta rápida no sistema especificado.
2. Baixo explícito na computação (MIPS). - que diz respeito apenas ao mínimo possível de ciclos de CPU.

Há um terceiro critério - onde as pessoas falam sobre "Baixa latência" - para aplicativos como videoconferência, onde os recursos computacionais podem não ser motivo de preocupação - mas o atraso geral introduzido pelos codificados

O que é importante observar que em sistemas de menor complexidade - o acesso à memória (velocidade e largura do barramento de memória) e, às vezes, as E / S são geralmente extremamente mais lentas, razão pela qual a classe de algoritmos MPEG sofre, mesmo que o algoritmo computacional possa ser simples.

Antes de julgar o requisito do codec, tente fazer um orçamento em termos de -

uma. Ciclos de CPU por segundo.
b. Memória máxima através da colocação.
c. Latência de IO

2. Você deve personalizar o MPEG em vez de reinventar.
Em geral - a classe de codecs MPEG oferece mecanismos muito flexíveis para fazer isso. Nesse sentido, você não precisa reinventar o codec tanto quanto prefere personalizar o MPEG 2 ou MPEG 4 para realizar seu trabalho.

Primeiro, vamos dizer o que todos os elementos tornam possível a compactação e organizá-los na ordem da complexidade:

1. Estimativa de movimento e compensação de movimento. 1.a. Previsão de avanço (quadros P) 1.b. Previsão dupla (quadros B) 1.c. vetores de movimento de alta resolução
2. Intra codificação - DCT (+ IDCT)
3. Qunatization - e seleção do modo de codificador
4. VLC - codificação de comprimento variável. (CABAC no H.264)
5. Previsão coeficiente [No mpeg2 apenas a previsão DC - MPEG4 tem mais]

Na classe de algoritmos MPEG, a codificação baseada em DCT e o VLC se tornam praticamente obrigatórios sem muitas opções - mas o restante de todos os mecanismos é essencial

Por exemplo, a estimativa de movimento e a compensação de movimento são um dos elementos que mais consomem MIPS. Se você não tiver recursos para fazer isso - você pode simplesmente codificar todos os quadros como eu (o que o torna muito parecido com MJPEG - mas o decodificador MPEG padrão pode decodificar isso). Se você puder pagar um pouco mais de recursos - poderá fazer uma compensação de movimento trivial usando a diferença de quadros - em vez de enviar todos os quadros como Intra, poderá subtrair todos os blocos do bloco de quadros anterior; se a diferença for maior que o sinal original, envie-o como Intra.

Claro - tudo isso significaria que você perderá alguma eficiência prometida pelo codificador acima - mas acho que você está disposto a desistir disso!

EDIT:
você pode olhar para os seguintes codecs como bons pontos de referência:

1. MSSG: http://www.mpeg.org/MPEG/video/mssg-free-mpeg-software.html
   Bom para entender, mas pode ser o mais lento do mundo.

2. FFMPEG: http://ffmpeg.org/ Provavelmente o mais rápido do mundo. É bom começar como caixa preta, mas não tente alterar o código por dentro. Pode dar boas opções para controlar as coisas quando você usa a API da biblioteca. Ele já é portado em muitas plataformas - mas fazê-lo em uma nova pode ser uma tarefa.

3. FAME: http://fame.sourceforge.net/ Isso foi originalmente iniciado com o mesmo objetivo que você descreveu. No entanto, estou um pouco sem contato com isso - mas você pode tentar isso.

4. Xvid: http://www.xvid.org/ Este é o MPEG-4. Esse é um dos melhores equilíbrios entre código limpo e velocidade razoável. Deve ser mais fácil trabalhar com você se você ficar dentro do codificador.

5. JPEG: http://www.ijg.org/ Este é o JPEG. Essa é uma das melhores bibliotecas para portá-la entre plataformas. Além disso, o JPEG é inerentemente mais simples do que alguns aspectos do MPEG; portanto, você deve tentar isso primeiro. A maioria das câmeras no mundo provavelmente usou essa biblioteca como está - em vez de criar algo próprio!

Pode ser que eu esteja errado ao usar MPEG! Mas esse é um tipo de risco que vale a pena correr.

Provavelmente, a melhor medida para verificar se isso funcionará ou não é - tente fazer um DCT 8x8 padrão com quantização na sua imagem; otimizar exatamente isso. Se você é capaz de atingir quase o requisito em tempo real, acho que é bom fazer com todos os quadros All JPEG ou com todos os codecs MPEG. Se você está fora do alvo - então não vale a pena.

Seu primeiro problema é a memória - mesmo a versão maior desse processador não possui muita SRAM interna (em termos de vídeo - é um processador embutido em comparação a muitos!) - um quadro VGA é de 300kB, contra os 100ishkB no processador . Isso significa que você terá que processá-lo como ele é apresentado - digamos, em blocos de 8 ou 16 linhas, o que o torna muito mais um problema "em tempo real", pois os prazos têm menos folga.

Não está claro como você estará capturando dados, mas presumo que você tenha algum tipo de DMA no ADC ou em alguma porta digital; caso contrário, você estará gastando metade do seu tempo embaralhando dados!

Com o objetivo de proporções de compactação baixas, convém apenas codificar os deltas entre os pixels ao longo de uma linha ou um quadrado 3x3 e depois codificá-los aritméticos.

Veja também Compactação de imagem simples, sem streaming e sem perdas - embora eu estivesse pedindo uma compressão sem perdas explicitamente, pode haver algumas idéias para você lá.

Como ponto de dados, um dos meus colegas implementou uma compactação JPG mono de 320 x 240 de 8 bits em um micro de 60 MHz de 32 bits com unidade de ponto flutuante e um pequeno cache. Ele usou algum código de referência (ou seja, otimizado para facilitar a leitura, não o desempenho) e obteve 5 fps com bastante facilidade. As taxas de compressão foram da ordem de 10x IIRC. A captura da imagem foi feita pelo barramento de hardware externo, dominando os dados na RAM externa do micro.