Blog-note de Sasha
Réimplémentation et réorientation Omniroom.
Posted on

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:

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)