Hello ! Dans un context de computer vision, j'ai deux webcam en 1080p branchées à un raspberry pi (stereovision) connecté à mon réseau local.

L'objectif est de récupérer l'image en 1080 avec autant de fps que possible afin de traiter l'image.

J'ai codé un flux avec des sockets TCP sauf qu'évidemment, en chronométrant, j'ai 1 image en 720p envoyée toutes les ~1.5s en moyenne. J'ai réfléchi à faire la même chose avec UDP sauf que la taille de 65k/paquet est compliqué pour la gestion du découpage des images.

Je pensais donc m'orienter vers FFMPEG pour arrêter de m'embêter, le problème c'est que même si ça a l'air super utilisé, absolument RIEN de ce que j'ai pu tester ne fonctionne. Le manuel/doc ne m'ont pas aidé car j'ai pas 1 mais 2 webcams à récupérer et je dois m'assurer qu'il y ait le moins de latence possible entre les deux caméras.

Si vous avez des ressources ou une solution je suis preneur !

Question complique.

Une image 1080p non compresser c'est 1920*1080*3 ~= 6MB. Un flux a 60 fps fait 350MB/s. Ca ne peut donc pas tenir sur un reseau gigabit. Au plus, tu peux faire transiter 20fps@1080pRAW sur un reseau gigabit.

Donc clairement il faut de la compression pour que ca soit faisable a un fps semi decent. La question devient a quelle vitesse ton raspi peut encode un flux video a la volee. Et la deuxieme question est comment communiquer ce flux video sur le reseau.

La premiere option que je vois est de regarder quels format le raspi peut accelerer materiellement. Fait des test avec ffmpeg que tu redirige vers /dev/null pour tester purement l'encodage. Apres benchmark ce que raspi peut envoyer sur le reseau et tune l'encodage pour controller ca.

Deux notes: personne ne fait de la CV serieuse sur une image a 1080p@60fps a travers le reseau.
1/ Soit les gens downscalent significativement la qualite de l'image, soit ils diminue significativement le frame rate.
2/ En pratique ce qui est classique est d'appliquer tout le preprocessing qui va bien directement a la source de la video et de n'envoyer sur le reseau que les features/images qui sont utiles. Les djeunz ils appellent ca "edge computing".

Merci pour ta réponse !

Effectivement 1080p60fps c'est impossible ! Mes cams sont de toute façon limitées à 30fps ahah

Et oui c'est une super question vis à vis de l'encodage. Je n'ai jamais travaillé sur de la vidéo auparavant du coup je suis un noob total. Pour le moment ce que j'avais en tête c'était de streamer les deux vidéos dans un format 1080p sur mon pc fixe pour avoir assez de pixel pour trouver des patterns dans un but de stereovision, reconstruction 3D, estimation de distance par triangulation etc.. puis appliquer des réseaux style U-net et YOLO dans l'idéal pour segmenter, identifier et estimer la distance d'objets détectés.

Je veux vraiment partir sur ffmpeg mais je sais vraiment pas du tout par où commencer, j'ai lu la doc mais j'arrive pas à avancer, rien de ce que je test avec ne fonctionne, ou alors la commande se lance mais sur mon fixe je ne reçois rien. Si tu as un cours/forum ou quoi à conseiller je suis plus que preneur !

Je ne connais personne qui fasse ca a partir de webcam et flux reseau compresse.

Les gens que je connais qui font ca, ont des camera pro connecte directement a une machine. La latence reseau peut causer une desync des flux videos, la compression va causer des artefacts, ... Les webcam ont toujours des capteurs un peu pourri qui font que la reconstruction est difficile.

Je ne suis pas un pro de ffmpeg, mais je peux regarder un peu.

ffmpeg ça fait tellement de truc, ils ont leur doc
https://trac.ffmpeg.org/wiki/StreamingGuide

ouais ca m'a l'air pas mal pour commencer.

Le 03 février 2021 à 22:01:58 godrik a écrit :
Je ne connais personne qui fasse ca a partir de webcam et flux réseau compresse.

Pas le choix, pour faire de la reconstruction 3D il faut que je puisse bouger tout le bordel et physiquement, avec des câbles d'1m ça peut être compliqué ahah

Les gens que je connais qui font ca, ont des camera pro connecte directement a une machine. La latence reseau peut causer une desync des flux videos, la compression va causer des artefacts, ... Les webcam ont toujours des capteurs un peu pourri qui font que la reconstruction est difficile.

Je ne suis pas un pro de ffmpeg, mais je peux regarder un peu.

Yes idem, mais vu que c'est un projet amateur, j'ai pas voulu investir dans plus de matos.

Le 03 février 2021 à 22:02:08 boucif a écrit :
ffmpeg ça fait tellement de truc, ils ont leur doc
https://trac.ffmpeg.org/wiki/StreamingGuide

Cimer je vais retester des ptites commandes

j'ai finalement réussi à faire fonctionner ffmpeg mais maintenant le problème est d'avoir une bonne synchronisation des deux images.

J'ai d'abord utilisé la commande -map 0 udp://@addr:12345 -map 1 udp://@addr:12346 et ça marche le problème c'est qu'il y a ~2 secondes de décalage ENTRE les caméras. Le ping ne me pose aucun problème, les fps sont bons et la compression de l'image dépend de pas mal de choses mais n'est en soit pas trop problématique. C'est surtout le décalage le pb.

Et idem lorsque j'ai "concaténé" sans utiliser -filter_complex que je n'arrive pas à utiliser. Pour le coup le delta entre ce qui est présent sur la doc et ce qu'on trouve sur les forums est gigantesque. La doc est littéralement complètement vide. (concernant filter_complexe et la syntaxe filtergraph) https://ffmpeg.org/ffmpeg-filters.html

ça me bute de galérer à ce point sur de la transmission vidéo, sur twitch les streamers arrivent broadcast une vidéo dont la qualité est pas trop deg même si décalage, je ne comprends pas comment ça peut être à ce point une galère sur un réseau local.

Parce qu'ils utilisent du matos dédié et pas un raspberry
https://www.ldlc-pro.com/pieces/carte-d-acquisition-video/c5422/

T'as pas un autre rapberry sous le coude, histoire que chaque webcam à son propre traitement

Le 04 février 2021 à 15:04:29 boucif a écrit :
Parce qu'ils utilisent du matos dédié et pas un raspberry
https://www.ldlc-pro.com/pieces/carte-d-acquisition-video/c5422/

T'as pas un autre rapberry sous le coude, histoire que chaque webcam à son propre traitement

Ce que je veux dire c'est que certe le raspi est limitant en terme de capacité. Mais l'affichage direct sur le raspi est très correct même en 1080p il m'affiche du 30fps (affichage via openCV je parle). C'est la difficulté de la diffusion qui pose réellement problème et que je trouve assez déconcertante

Tu compresse ton flux avant de l'envoyer sur le réseau ?

Le 04 février 2021 à 11:07:51 serieusement321 a écrit :

Le 03 février 2021 à 22:01:58 godrik a écrit :
Je ne connais personne qui fasse ca a partir de webcam et flux réseau compresse.

Pas le choix, pour faire de la reconstruction 3D il faut que je puisse bouger tout le bordel et physiquement, avec des câbles d'1m ça peut être compliqué ahah

wait. Tu essaye de faire ca sur un reseau wifi?

Le 04 février 2021 à 15:13:18 serieusement321 a écrit :

Le 04 février 2021 à 15:04:29 boucif a écrit :
Parce qu'ils utilisent du matos dédié et pas un raspberry
https://www.ldlc-pro.com/pieces/carte-d-acquisition-video/c5422/

T'as pas un autre rapberry sous le coude, histoire que chaque webcam à son propre traitement

Ce que je veux dire c'est que certe le raspi est limitant en terme de capacité. Mais l'affichage direct sur le raspi est très correct même en 1080p il m'affiche du 30fps (affichage via openCV je parle). C'est la difficulté de la diffusion qui pose réellement problème et que je trouve assez déconcertante

La compression ca coute du CPU alors que l'affichage directe non. Encore une fois, decoupe le probleme en deux, la compression et l'evoie sur le reseau. Ca te permettra de voir ou sont tes bottlenecks.

Le 04 février 2021 à 16:44:32 godrik a écrit :

Le 04 février 2021 à 11:07:51 serieusement321 a écrit :

Le 03 février 2021 à 22:01:58 godrik a écrit :
Je ne connais personne qui fasse ca a partir de webcam et flux réseau compresse.

Pas le choix, pour faire de la reconstruction 3D il faut que je puisse bouger tout le bordel et physiquement, avec des câbles d'1m ça peut être compliqué ahah

wait. Tu essaye de faire ca sur un reseau wifi?

Oui

Le 04 février 2021 à 16:46:02 godrik a écrit :

Le 04 février 2021 à 15:13:18 serieusement321 a écrit :

Le 04 février 2021 à 15:04:29 boucif a écrit :
Parce qu'ils utilisent du matos dédié et pas un raspberry
https://www.ldlc-pro.com/pieces/carte-d-acquisition-video/c5422/

T'as pas un autre rapberry sous le coude, histoire que chaque webcam à son propre traitement

Ce que je veux dire c'est que certe le raspi est limitant en terme de capacité. Mais l'affichage direct sur le raspi est très correct même en 1080p il m'affiche du 30fps (affichage via openCV je parle). C'est la difficulté de la diffusion qui pose réellement problème et que je trouve assez déconcertante

La compression ca coute du CPU alors que l'affichage directe non. Encore une fois, decoupe le probleme en deux, la compression et l'evoie sur le reseau. Ca te permettra de voir ou sont tes bottlenecks.

Mais pour que l'envoie sur le réseau se fasse correctement je suis sensé compresser d'abord non ? J'ai jamais bossé vraiment là dessus encore, pour l'instant je me contente de diffuser mes images entières par TCP 'bloquant', càd qu'il n'envoie pas à chaque frame mais dès qu'une frame est envoyée, c'est pour ça que je cherchais à faire autrement et UDP c'est peu galère

Le 04 février 2021 à 15:36:16 boucif a écrit :
Tu compresse ton flux avant de l'envoyer sur le réseau ?

Avec TCP le flux n'est pas compressé du tout et ça marche mieux que ffmpeg. Attention, je suis pas un pro de ffmpeg donc il y a moyen de mieux l'utiliser que ce que j'ai fait.

ffmpeg a des modes de compression de stream avec frame drop.
Un truc comme ca a l'airpas mal, mais tu as quand meme de la latence d'en gros une seconde meme en local:

ffmpeg -i /dev/video0 -c:v libx264 -preset veryfast -x264opts keyint=15 -tune zerolatency -muxpreload 0 -muxdelay 0 -f mpegts "tcp://127.0.0.1:2000"

Mais si tu utlises un reseau wifi, j'imagine que tu te fous completement la latence et la variabilite du frame rate

Le 04 février 2021 à 17:35:27 godrik a écrit :
ffmpeg a des modes de compression de stream avec frame drop.
Un truc comme ca a l'airpas mal, mais tu as quand meme de la latence d'en gros une seconde meme en local:

ffmpeg -i /dev/video0 -c:v libx264 -preset veryfast -x264opts keyint=15 -tune zerolatency -muxpreload 0 -muxdelay 0 -f mpegts "tcp://127.0.0.1:2000"

Mais si tu utlises un reseau wifi, j'imagine que tu te fous completement la latence et la variabilite du frame rate

J'essaye ça dès que possible !