transmissão de vídeo de e para várias fontes

Question

Eu queria ter algumas idéias como alguns de vocês abordariam esse problema. Eu tenho um robô, que está executando o Linux e usa uma webcam (com um driver V4L2) como um de seus sensores. Eu escrevi um painel de controle com GTKMM. O servidor e o cliente estão gravados em C ++. O servidor é o robô, o cliente é o "painel de controle". A análise da imagem está acontecendo no robô, e eu gostaria de transmitir o vídeo da câmera para o painel de controle por dois motivos: a) para diversão b) para sobrepor resultados de análise de imagem

Então, minha pergunta é: quais são algumas boas maneiras de transmitir vídeo da webcam para o painel de controle, além de dar prioridade ao código do robô para processá -lo? Não estou interessado em escrever meu próprio esquema de compactação de vídeo e colocá -lo na porta de rede existente, uma nova porta de rede (dedicada aos dados de vídeo) seria melhor, eu acho. A segunda parte do problema é como faço para exibir vídeo no GTKMM? Os dados do vídeo chegam de maneira assíncrona e não tenho controle sobre Main () no GTKMM, então acho que isso seria complicado.

Estou aberto a usar coisas como VLC, GStreamer ou qualquer outra biblioteca de compressão geral que eu não conheço.

obrigado!

EDIT: O robô possui um processador de 1 GHz, executando uma versão como desktop do Linux, mas não x11.

Answer 1

O GStreamer resolve quase tudo isso para você, com muito pouco esforço, e também se integra bem ao sistema de eventos Glib. O GStreamer inclui plugins de origem V4L, widgets de saída GTK+, vários filtros para redimensionar / codificar / decodificar o vídeo e o melhor de tudo, o afundamento da rede e as fontes para mover os dados entre as máquinas.

Para o protótipo, você pode usar a ferramenta 'GST-launch' para montar pipelines de vídeo e testá-los, então é simplesmente para criar pipelines programaticamente em seu código. Pesquise 'GSTREAMER Network Streaming' para ver exemplos de pessoas fazendo isso com webcams e similares.

Answer 2

Não tenho certeza sobre as tecnologias reais usadas, mas isso pode acabar sendo uma enorme sincronização ***** se você quiser evitar molduras caídas. Eu estava transmitindo um vídeo para um arquivo e uma rede ao mesmo tempo. O que acabei fazendo foi usar um grande tampão circular com três ponteiros: uma escrita e duas leituras. Havia três tópicos de controle (e alguns threads de codificação adicionais): uma escrita para o buffer que faria uma pausa se atingisse um ponto no buffer não lido por ambos os outros, e dois tópicos do leitor que liam do buffer e escreviam para o arquivo/rede (e pausará se eles ficaram à frente do produtor). Como tudo foi escrito e lido como quadros, a sobrecarga de sincronização pode ser mantida no mínimo.

Meu produtor era um transcodificador (de outra fonte de arquivo), mas, no seu caso, você pode querer que a câmera produza quadros inteiros em qualquer formato que normalmente faça e faça apenas a transcodificação (com algo como FFMPEG) para o servidor, enquanto o robô processa a imagem.

Seu problema é um pouco mais complexo, já que o robô precisa de feedback em tempo real, não pode fazer uma pausa e aguardar o atraso do servidor de streaming. Portanto, você pode querer colocar os quadros para o sistema de controle o mais rápido possível e buffer um pouco em um tampão circular separadamente para streaming para o "Painel de Controle". Certos codecs manipulam quadros caídos melhor do que outros; portanto, se a rede ficar atrás, você poderá começar a substituir os quadros no final do buffer (tomando cuidado, eles não estão sendo lidos).

Answer 3

Quando você diz 'uma nova porta de vídeo' e comece a falar sobre VLC/GStreaming, acho difícil descobrir o que você deseja. Obviamente, esses pacotes de software ajudarão no streaming e compactação por meio de vários protocolos, mas claramente você precisará de uma 'porta de rede' não uma 'porta de vídeo' para enviar o fluxo.

Se o que você realmente quer dizer, está enviando saída de exibição por meio de vídeo/TV sem fio, que é outra questão, no entanto, você precisará de conselhos de especialistas em hardware, em vez de especialistas em software.

Se movendo. Eu fiz bastante streaming sobre os protocolos MMS/UDP e o VLC lida muito bem com isso (como servidor e cliente). No entanto, ele foi projetado para desktops e pode não ser tão leve quanto você deseja. Algo como GStreamer, Mencoder ou FFMPEG na mão vai ser melhor, eu acho. Que tipo de CPU o robô tem? Você precisará de um pouco de grunhido se estiver planejando compressão em tempo real.

No lado do cliente, acho que você encontrará vários widgets para lidar com o vídeo no GTK. Eu examinaria isso antes de me preocupar com os detalhes da interface.