Bonjour à toute la liste.
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.
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):
Si vous avez bien compris, j’aimerais utiliser 5 raspberry avec caméra (https://www.raspberrypi.org/products/camera-module/ https://www.raspberrypi.org/products/camera-module/) + carte d’acquisition HDMI (http://www.geeky-gadgets.com/raspberry-pi-hdmi-input-allows-hd-recording-vid... http://www.geeky-gadgets.com/raspberry-pi-hdmi-input-allows-hd-recording-video-14-03-2014/) Afin d’effectuer l’entrée des deux signaux sur les raspberry et des les envoyer via ethernet (via srtp par exemple) Problème, cette carte d’acquisition HDMI n’a pas atteint son but via kickstarter, existe t’il des alternative?
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?
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?
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%)
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.
Merci de m’avoir lu jusqu’ici et bonne journée à toutes et à tous.
Regardes du côté du orangepi plus à la place du raspi (meilleur en vidéo et moins cher)
JPB
Sent from my Cyanogen phone
Le 31 oct. 2015 9:20 AM, Antonin GIRAUD-PERNETTE - Clic' Ordi antoningp@clic-ordi.com a écrit :
Bonjour à toute la liste.
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.
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):
Si vous avez bien compris, j’aimerais utiliser 5 raspberry avec caméra (https://www.raspberrypi.org/products/camera-module/) + carte d’acquisition HDMI (http://www.geeky-gadgets.com/raspberry-pi-hdmi-input-allows-hd-recording-vid...) Afin d’effectuer l’entrée des deux signaux sur les raspberry et des les envoyer via ethernet (via srtp par exemple)
Problème, cette carte d’acquisition HDMI n’a pas atteint son but via kickstarter, existe t’il des alternative?
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?
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?
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%)
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.
Merci de m’avoir lu jusqu’ici et bonne journée à toutes et à tous.
Le 31/10/2015 09:20, Antonin GIRAUD-PERNETTE - Clic' Ordi a écrit :
Bonjour à toute la liste.
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.
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):
Si vous avez bien compris, j’aimerais utiliser 5 raspberry avec caméra (https://www.raspberrypi.org/products/camera-module/) + carte d’acquisition HDMI (http://www.geeky-gadgets.com/raspberry-pi-hdmi-input-allows-hd-recording-vid...) Afin d’effectuer l’entrée des deux signaux sur les raspberry et des les envoyer via ethernet (via srtp par exemple) Problème, cette carte d’acquisition HDMI n’a pas atteint son but via kickstarter, existe t’il des alternative?
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?
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?
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%)
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.
Merci de m’avoir lu jusqu’ici et bonne journée à toutes et à tous.
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06
Regardes plûtot du côté de l'orange pi plus à la place des raspis ( moins cher et plus performant en vidéo,giga eth etc...).
JPB
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):
Si vous avez bien compris, j’aimerais utiliser 5 raspberry avec caméra (https://www.raspberrypi.org/products/camera-module/) + carte d’acquisition HDMI (http://www.geeky-gadgets.com/raspberry-pi-hdmi-input-allows-hd-recording-vid...) Afin d’effectuer l’entrée des deux signaux sur les raspberry et des les envoyer via ethernet (via srtp par exemple) 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
Bon, me revoici un peu reparti sur le sujet, mais je n'ai pas beaucoup pu avancer (mes 2 ordinateurs de travail, qui a dit qu'il fallait plus qu'une seule roue de secours?, m'ont lâchés samedi)
pour la partie flux, je pense utiliser Gstreamer, bien documenté, a l'air robuste et souple ex->http://blog.nicolargo.com/2013/05/streaming-depuis-la-raspberry-camera.html
Pour la partie aquisition hdmi, c'est un peu plus compliqué, le module que j'ai trouvé est un kickstarter qui a été avorté :/
Connaissez vous des cartes d'aquisition vidéo USB (1080p@30fps) qui soient compatibles avec linux? comme par exemple une avermedia?
J'aimerais être sur de trouver la bonne solution matérielle déjà, avant de commander ce qu'il faut pour pouvoir commencer à bidouiller concrètement :)
Merci encore à tous pour vos réponses
Antonin
Le 31/10/2015 12:10, tr4ck3ur a écrit :
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):
Si vous avez bien compris, j’aimerais utiliser 5 raspberry avec caméra (https://www.raspberrypi.org/products/camera-module/) + carte d’acquisition HDMI (http://www.geeky-gadgets.com/raspberry-pi-hdmi-input-allows-hd-recording-vid...) Afin d’effectuer l’entrée des deux signaux sur les raspberry et des les envoyer via ethernet (via srtp par exemple) 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
Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06
Le 31/10/2015 12:10, tr4ck3ur a écrit :
À 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.
Ça serait tellement bien si tu nous faisais une présentation aux JM2L avec de jolis schémas :) Cordialement
-
Antonin GIRAUD-PERNETTE - Clic' Ordi -
Antonin GP - Clic' Ordi
-
Guy Passail -
Jean-Pierre Benoit -
jpb
-
tr4ck3ur