Ce logiciel trouve ses début lors d'un événement où nous avons concu et animé une escape game avec des amis et nous avions un besoin de monitoring video très réactif afin d'aider les joueuses.

Le besoin:

• Avoir des cameras très légères et facilement déployable dans une ou plusieurs pièces
• Pouvoir consulter les flux vidéos rapidement et de facon accessible (sans installation de binaire sur le système)
• Le flux doit être le plus faible latence possible

Je suis donc partie sur le WebRTC:

Car cela solutionne à la fois la latence et l'accessibilité car compatible avec les naviguateurs actuels

La négociation WebRTC se fait souvent au travers d'un "signaling server", l'architecture se décrit donc comme ceci:
Clients <-> Signaling server <-> Cameras
Puis, une fois la négociation faite, voici l'échange des flux:
Clients <-> Cameras
(Ici j'ignore le fait qu'il puisse y avoir de la surcharge réseau)

La première version était en:

• Client: html+css+js
• Server: python
• Camera: C

J'utilise GStreamer pour la gestion du flux video et la négociation WebRTC, cela pourra changer à l'avenir en utilisant Gstreamer + Webrtc-rs ou même ffmpeg + Webrtc-rs

J'ai depuis refondu tout ca et maintenant tout est en Rust

Il reste cependant un soucis de fonctionnement qui empeche le flux de passer alors que la négociation s'effectue bien.

Dépots git:

• Client
• Server
• Camera

Réimplémentation

Ok, je suis revenue la dessus.
J'ai repris à zéro pour me baser sur le fonctionnement du WHIP

J'ai une première version qui est propre et fonctionne bien. (le versionnage git est vraiment pas propre ceci dit) J'ai utilisé actix_web pour la partie server http
J'ai utilisé webrtc-rs pour la partie Webrtc
J'ai utilisé simple-whip-client + la camera virtuelle d'OBS pour tester le serveur car le module WHIP d'OBS est lent

Je comprend mieux le fonctionnement de Webrtc, notament la négociation SDP et ICE via les serveurs STUN.

Pour le côté web c'est encore un vestige de mon ancienne implémentation donc ca demande à être plus propre.

Ca ma permis d'apprendre à faire un Dockerfile (j'avais réussi à esquiver ca jusque là, assez surprenant)
J'ai tout mis ca en ligne (dépot github et dépot docker hub)

Il existe déjà un module gstreamer whip "whipsink" (dépot des plugins)

Réorientation du projet

Redéfinition du but d'Omniroom afin de supporter de multiples sources comme multiples tracks webrtc.
Le but étant de pouvoir faire du multistream synchronisé.
Cela nécessiterait plusieurs encodeurs en parrallèle

L'un des usages qui m'intéressent est de pouvoir laisser à l'utilisateur le choix de l'organisation des flux vidéos sur ses écrans (exemple: vue-webcam et vue-jeu sur des écrans séparés)
Un autre usage qui m'intéresse est la possibilité de mettre des filtres sur un seul flux vidéo et diffuser sur différentes plateformes en même temps avec et sans filtre mais je pense que cela n'a pas sa place dans ce projet-ci.

Projets existants:

• GstPipelineStudio et GstPipelineStudio: développement arrêté
• Pipeviz: développement arrêté

Dans un monde parfait un plugin OBS serait vraiment pratique, mais je pense que l'architecture dont il y a besoin est trop loin de l'implémentation d'OBS (avis grossier sans réele connaissance interne d'OBS)

A termes il serait interressant de pouvoir multiplexer côté serveur plusieurs producers dans une seule connexion webrtc sur plusieurs tracks pour un consumer. (note: a voir comment gerer les drops de frame: si un producer galère est-ce que ca impacte un autre ?)
Mais j'aimerais qu'un producer puisse aussi organiser ses tracks comme il le souhaite.

Donc pour avoir l'ensemble des features il sera nécessaire d'utiliser producer, signaling server et consumer ensemble mais je veux qu'une utilisation simple puisse toujours être faite sur d'autres outils WHIP, donc garder la négociation "standardisée". WHIP WHEP (aussi disponibles sur Github WHIP WHEP)

J'ai pu découvrir récemment le protocole WHIP qui vise a standardiser la négociation webrtc.
Une implémentation en go est dispo et s'appelle Broadcast-box

Après avoir pas mal joué avec cette implémentation c'est cool mais 2 features sont manquantes:

• Le STUN, plutot que d'avoir à donner en dur l'IP qui sera utilisée pour les candidats ICE
• Les PATCH pour la négociation des candidats ICE à postériori, car pour l'instant il faut obligatoirement que les candidats se trouvent dans l'offre SDP de départ. Ce qui réduit la modularité d'architecture, car un SDP déjà fourni de candidats ICE ne peut se faire que dans le cas d'une négociation provenant d'une URL identique à celle du serveur WHIP. (Ne fonctionne pas dans le cas d'une page locale ou d'une extension par exemple) (ou alors j'ai pas trouvé)

Je vais voir pour implémenter ca et soumettre une PR à Broadcast-box Afin de pouvoir ensuite dev une extension Firefox pour indiquer si un stream est actuellement dispo via WHIP

Il y a de fortes chances que je finisse par implémenter le WHIP dans Omniroom plutot que mon protocole maison