On 31/10/2015 09:20, Antonin GIRAUD-PERNETTE - Clic' Ordi wrote:
Bonjour à toute la liste.
Salut Antonin,
J’ai un petit projet visant a capturer le signal
d’un écran et d’une webcam afin de le diffuser en réseau vers
une « régie » qui récupèrerait les 10 flux (5 cam + 5 écrans).
Je m’intéresse dans ce mail à l’élément le plus
problématique (pour moi), la partie encodage et diffusion de
chaque poste « éméteur » via le réseau local.
Comme quoi les grands esprits se rencontrent...
Nous souhaitons utiliser la technique que tu décris pour la
captation vidéo lors de l'événement des JM2L
(http://jm2l.linux-azur.org/) et avons donc mis en place une
architecture similaire.
Tout d’abord un petit schéma pour illustrer ma
pensée (schéma général, pas de tâchons soft choisies pour le
moment):
Problème, cette carte d’acquisition HDMI n’a pas
atteint son but via kickstarter, existe t’il des alternative?
Nous avons de notre coté une chaîne fonctionnelle et sommes quasi
dans la même configuration que toi à l'exception près que nous
n'utilisons pas la carte d’acquisition HDMI que tu proposes. (donc
un seul flux vidéo par Rasp)
Par contre, de notre coté nous véhiculons une partie audio capturé à
partir d'une carte son externe USB connecté sur chacune de nos rasp.
Le but étant d’avoir le moins de latence possible (
1 seconde c’est déjà trop :/ ) Est-ce que le raspberry 2 pourra
supporter 2 flux 720P ? (voire même 1080 + 720) ou connaissez
vous une board avec un module d’acquisition HDMI et caméra qui
soit plus appropriée?
À ma connaissance, et suite à mes tests pour la mise en place d'une
architecture similaire, les raspberry (à partir de la B de base) est
capable de générer du 720P, du 1080P voir plus sans trop de souci.
C'est difficile de te répondre sur la partie HDMI sans avoir ton kit
sous la main, mais au vu de l'utilisation CPU/Réseau de la rasp dans
mes tests, je pense effectivement qu'elle serait capable de diffuser
les deux flux.
La partie compliqué dans cette architecture, c'est que les flux sont
envoyé quasi immédiatement mais c'est un flux vidéo brut en h264
natif.
Lors de mes tests la meilleure latence que j'ai réussi à avoir pour
la lecture de ce flux brut, sur l'équivalent de ta régie, c'est aux
alentours de 500ms.
Pour résumer la technique, la lecture du flux brut sur la régie met
un certains temps à reconnaître le type de flux vidéo à décoder (et
environ 1 à 2 secondes pour l'initialiser).
J'ai donc atteint 500ms en lançant le décodage du flux coté régie
via un ffplay (histoire d'initialiser le 'décodage'), puis arrêté la
diffusion du flux coté rasp pour vider le buffer...
Puis relancé l'aquisition du flux coté rasp, la latence obtenue est
alors effectivement aux alentours de 500ms au final.
En gros, on lance le lecteur de flux sur la régie, on "pause" puis
"play" l'émission histoire de manger les secondes perdues...
Je pense qu'on doit pouvoir éviter ça avec l'utilisation de
"gstreamer", mais la mise en place de la ligne de commande des deux
coté se complique...
La problématique pour les soucis de latence :
Les capacités de la rasp étant relativement limités, nous devons de
notre coté post-traiter le flux brut sur l'équivalent de ton "PC
régie" pour le ré-encoder en live afin de permettre l'affichage dans
une balise vidéo HTML5.
Cette partie encodage du flux brut, additionné à la partie
initialisation du flux, nous donne une latence aujourd'hui aux
alentours de 4 à 5 secondes.
La technique du pause/play ne nous permet pas de rattraper
suffisamment le temps, et nous n'arrivons pas à descendre en dessous
de 2 secondes une fois affiché dans une page web.
Effectivement le ré-encodage du flux prend trop de temps dans notre
archi.
J’ai commencé à regarder du coté de Netcat qui me
semble pas mal, mais je n’arrive à avoir aucune info sur une
éventuelle latence, tout le monde parle de la limitation de la
bande passante, mais en réseau local Gigabit avec un routeur
cisco et un peu de QoS est-ce que cela deviendrait acceptable?
Coté rasp nous utilisons "picam" qui nous donne entière
satisfaction, et qui s'occupe de mettre un conteneur ts autour de
notre audio et vidéo, vi c'est mieux d'avoir la synchro audio/vidéo
;)
je te le conseille, et c'est par ici : https://github.com/iizukanao/picam
Par contre nous avons pris le parti de diffuser le flux en
udp, car on arrive sur un réseau dont on ne connaît pas à
l'avance les capacités..
(et aussi pour jouer avec le fameux pause/play): picam
--tcpout udp://<régie>:<port>
Pas besoin de sécurisation des flux, ils seront
sur un réseau offline
J’ai testé avec VLC et SRTP sans priorisation des
paquets réseaux, mais ave un seul flux : trop de latence,
(charge processeur et mémoire du PC émetteur et récepteur <
10%)
Coté régie nous
utilisons ffplay pour lire le flux brut ... ffplay
udp://localhost:<port>
Bref si vous avez des idées, observations, si vous
connaissez un logiciel génial et simple pour récupérer un flux
et le diffuser via le réseau, ça serait top.
Pour la petite
histoire, nous utilisons ffmpeg puis ffserver pour l'encodage
du flux brut vers un conteneur webm.
La sortie du webm est utilisé sur une page web qui rassemble
l'ensemble des flux, avec une latence relativement constante
(d'environ 5 seconde au bout de la chaîne, sans le pause/play).
Alors, nous avons mis en place un petit
site web en python, embarqué sur les rasp pour piloter/orchestrer
tout ça (et s'annoncer sur le réseau via zeroconf par exemple pour
les retrouver facilement (cas de l'ip fournie par DHCP))
Mais ça c'est une autre histoire ^^ ...
Merci de m’avoir lu jusqu’ici et bonne journée à
toutes et à tous.
Tiens moi au courant de tes découvertes éventuelles !
@ tout bientôt
_______________________________________________
Linux06 mailing list
Linux06@lists.linux-azur.org
https://lists.linux-azur.org/mailman/listinfo/linux06
--
tr4ck3ur